From: nospam@needed.invalid   
      
   On Wed, 12/31/2025 1:42 PM, bart wrote:   
      
   > So is that a Yes or No?   
   >   
   > My C compiler calls __getmainargs() in msvcrt.dll to get argc/argv.   
   >   
   > __getmainargs() is also imported by programs compiled with Tiny C, and also   
   with gcc 14.x from winlibs.com. (I assume it is actually called for the same   
   purpose.)   
   >   
   > The specs for __getmainargs() say that the returned argc value is always >=   
   1.   
   >   
   > (I doubt whether msvcrt.dll, which is present because so many programs rely   
   on it, is what is used by MSVC-compiled appls, but you'd have to look inside   
   such an app to check. EXEs inside \windows\system tend to import DLLs with   
   names like "api-ms-win...   
   ".)   
   >   
   > In any case, it is easy enough to do a check on argc's value in your   
   applications. (And on Windows, if it is 0 and you really need the path, you   
   can get it with GetModuleFileNameA().)   
      
   The answer says "with MSVC". And your usage of msvcrt.dll likely applies   
   to that statement.   
      
   If you wrote your own version of a runtime msvcrt.dll then the answer could be   
   no or maybe.   
      
   I think if you're sufficiently clever, you can break that. But for   
   the most part, lots of regular/lazy programming efforts will be guaranteeing   
   a good result. I've used the argv[0] to determine the role of a program   
   (encoder or decoder mode), and I'm just a very bad hobby programmer.   
      
   Windows is pretty careless with metadata. In twenty years of watching Windows,   
   I watched a program lose its name, and also one which had no parent. I thought   
   when a program lost a parent that System() would own it. But when I checked,   
   not even System was the parent. The parent was nothing. And Windows seemingly   
   does not kill items malformed in that way. (The root cause may have been a RAM   
   error, but I cannot be sure.)   
      
   If you look in Task Manager in W10/W11, you cannot see Memory Compressor.   
   If you use    tasklist /V   in a Terminal, then you can see it. That is just so   
   you can contrast that with the behavior of Task Manager. And if you use   
   Sysinternals (bought by Microsoft) Process Explorer utility, if you check   
   Properties on Memory Compressor (even as administrator), no metadata is visible   
   and the status says  something about a necessary device is not responding.   
   As if someone launched that in a particular way so it would be orphaned on   
   purpose.   
      
   But this is Windows for you. That's how you do things there.   
      
      Paul   
      
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)