From: already5chosen@yahoo.com   
      
   On Wed, 31 Dec 2025 15:00:24 -0800   
   Keith Thompson  wrote:   
      
   > Michael S  writes:   
   > > On Tue, 30 Dec 2025 19:35:12 -0800   
   > > Keith Thompson  wrote:   
   > [...]   
   > >> For more information, see   
   > >> .   
   > >   
   > > If you are interested in behavior on non-POSIX systems, primarily   
   > > Windows, but possibly others as well (e.g. VMS) then using exec()   
   > > in caller sounds like a bad idea. It just not how these systems   
   > > work and not how people write programs on them.   
   > > Even when exec() *appears* to works in some environments (like   
   > > msys2) it likely emulated by spawn() followed by exit().   
   > >   
   > > I'd implement caller with spawn(). I suppose that even on POSIX it   
   > > is more idiomatic.   
   >   
   > If I were going to look into the behavior on Windows, I'd probably   
   > want to use Windows native features.  (I tried my test on Cygwin,   
   > and the callee wasn't invoked.)   
   >   
      
   That's likely because under Windows callee is named callee.exe.   
   I didn't try on cygwin, but that was the reason of failure under msys2.   
   Also, I am not sure if slash in the name is allowed. May be, backslash   
   is required.   
      
   > Apparently the Windows way to invoke a program is CreateProcessA().   
   > But it takes the command line as a single string.  There might not   
   > be a Windows-native way to exercise the kind of control over argc   
   > and argv provided by POSIX execve().   
   >   
      
   Yes, some tricky combinations easily possible under POSIX are hard to   
   achieve under Windows. The result could depend on exact implementation   
   of parsing of command line in C start up code. May be, some combinations   
   are even impossible, although right now I can not think out an   
   example.   
      
   But that was not my point. My point was that analog of exec() family   
   does not exist in Windows (or VMS). Even if it appears to exist that   
   just means that your environment somehow fooling you. The PID of child   
   is not the same as parent's.   
   So, if you want cross-platform test, it makes more sense to use spawn()   
   family. It does not look like your test will be any more complicated   
   with spawn() and as a free benefit you can print some info of   
   interest in the parent process after after spawn() call.   
      
   However I was wrong in my suggestion. I didn't realize that spawn   
   functions under Windows and their POSIX equivalents have different names   
   and different order of arguments.   
   So, I take my suggestion back.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)