From: news.dead.person.stones@darjeeling.plus.com   
      
   On 31/12/2025 23:00, 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.)   
   >   
   > 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().   
      
   On Windows there is a command-line provided to applications via    
   etCommandLine() api.  This is  a   
   single zero-terminated string.  There is no mention of the possibility of   
   GetCommandLine returning   
   NULL.   
      
   Windows (and in general non-*nix OS's) does not have a concept of processes   
   having a list of strings   
   as their basic start up mechanism.  [Windows processes have an environment   
   strings block, similar to   
   *nix and used in the same way, but the "command line" is just a string...]   
      
   Windows views parsing of the command-line string to be in the application   
   domain, I guess.  The MSVC   
   compiler provides console-mode applications with the usual (argc, argv) but   
   the MSVC application   
   start-up code does this rather than the OS.  For GUI-mode apps, MSVC provides   
   a different interface   
   to the user entry point.  (Of course, if the app wants the command-line it can   
   call the Windows api   
   to get it, and if it wants command-line tokens it can parse it itself, or call   
   CommandLineToArgv()   
   api which is part of the shell api and replicates MSVC startup behaviour...)   
      
      
   Mike.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)