Page MenuHome GnuPG

Windows 64-bit: functions which use pid_t
Testing, WishlistPublic


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.

Revisions and Commits

Event Timeline

APIs which need revise (where we use pid_t):


  • gnupg_spawn_process
  • gnupg_spawn_process_fd
  • gnupg_wait_process
  • gnupg_wait_processes
  • gnupg_release_process
  • gnupg_kill_process


  • assuan_waitpid
  • assuan_socket_connect
  • assuan_get_pid

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.

werner triaged this task as Wishlist priority.Jul 31 2019, 12:39 PM

Lacking another category for such things, I dropped the priority.

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.

gniibe changed the task status from Open to Testing.Aug 4 2023, 2:40 AM

In libassuan 3.0, we distinguish the integer identifier for process and the HANDLE (by T6487).
This was problem was solved.