libdpkg: m_fork and friends
I've already started this thread on debian-win32, however I've moved it
here as my questions are about proposed solutions to os-specific issues.
I've started trying to port dpkg natively to Windows (as opposed to
One area that may cause problems is that Windows doesn't have fork
functionality, so implementing m_fork() will be challenging.
From what I've seen so far, the only time m_fork gets used in the dpkg
source is as part of the process of spawning a child to do some work,
and writing Win32 child-spawning code should be pretty simple.
It was suggested on debian-win32 that I could use GLib for the process
spawning. This would simplify code, as there are functions to spawn
synchronously or asynchronously, and using single-string or vector-based
arguments, as well as automatically creating pipes for
stdin/stdout/stderr. On the down side, it does mean introducing a new
dependency to dpkg.
Either GLib or Win32-specific code will can solve the process spawning
issue, and this is all well and good as long as no other packages are
using the m_fork (and possibly m_pipe/m_dup2) code. So my questions are:
- Are other packages supposed to use m_fork, m_pipe, etc?
- If not, do we know of/care about packages that do use it?
- If so, would breaking API compatability to allow a Win32 port be a
Please note that my last question is badly phrased... it would _only_ be
the Win32 port that would have a changed API, specifically the functions
that can't be (easily) implemented (m_fork, possibly m_pipe/m_dup2)
would be #ifdef'd out, or moved to a separate file that autotools links
in on non-Win32 platforms.