This entry is basically my memorandum so that I won't make mistake.
HANDLE for a process, as a type, cannot be represented by an int.
As long as the value of HANDLE is small (fits in 32-bit), it works.
In the long run, it's better to have API, with something like gpgrt_process_t,
where gpgrt_process_t can represent HANDLE as a type.
pid_t of getpid and process HANDLE is different thing.
| rE libgpg-error | |||
| rE660db9c9a90f w32: Fix handle_to_pid for MinGW-w64. | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T6508 Port GnuPG to 64-bit Windows | ||
| Testing | • gniibe | T4656 Windows 64-bit: functions which use pid_t | ||
| Resolved | • gniibe | T6236 libassuan: Support sendfd/recvfd (possibly by new API) on Windows | ||
| Testing | • gniibe | T6487 libassuan: Clear semantics for assuan_get_pid and improve use cases for process control |
APIs which need revise (where we use pid_t):
GnuPG:
libassuan:
Actually my not-written-down plan is to use a Windows like style for tracking a process. This will also resolve the pid rollover problem. It shall all go into gpgrt of course.
Original MinGW and MinGW-w64 handle differently.
For MinGW-w64 on 64-bit machine, pid_t is 64-bit integer.
For original MinGW on 64-bit machine, pid_t is 32-bit integer.
Now, we implemented fd passing on Windows in libassuan.
Note that the process identifier (represented by DWORD) and handle for a process (represented by HANDLE) are different things.
AFAIK, Microsoft stated that the value of a HANDLE will always fit into a DWORD; i.e. only the lower 32 bits are used even on a 64 bit Windows.
In libassuan 3.0, we distinguish the integer identifier for process and the HANDLE (by T6487).
This was problem was solved.