From: already5chosen@yahoo.com
On Sat, 3 Jan 2026 04:08:40 +0000
Mike Terry wrote:
> On 02/01/2026 12:32, Michael S wrote:
> > On Thu, 1 Jan 2026 23:50:00 -0000 (UTC)
> > Lawrence D’Oliveiro wrote:
> >
> >> On Thu, 1 Jan 2026 21:53:20 +0200, Michael S wrote:
> >>
> >>> On Thu, 1 Jan 2026 19:02:49 -0000 (UTC)
> >>> Lawrence D’Oliveiro wrote:
> >>>
> >>>> All those are at the sending end. But what would C code see at
> >>>> the receiving end?
> >>>
> >>> The first three cases look very simple.
> >>
> >> Is there some spec in Windows which describes how that works?
> >
> > There is a spec that describes how that works in Microsoft's
> > implementation. That implementation is available free of charge to
> > other Windows compilers.
> > If vendor of Windows 'C' compiler decided to implement different
> > algorithm then nobody can stop him.
> >
> > Through the years you were told so, by different people, and shown
> > the spec may be 100 times. But being the trolll you are, you
> > continue to ask.
> >
> > Still, for the benefit of more sincere readers and also for myself,
> > in order to have both pieces in one place:
> > https://learn.microsoft.com/en-us/windows/win32/api/shellapi
nf-shellapi-commandlinetoargvw
> > https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-c
mmand-line-arguments
> >
>
> In the long distant past I investigated how MSVC converts a
> command-line to its argc/argv input. There was an internal routine in
> the CRT startup code that did pretty much what we would expect, and I
> reversed engineered that for my code (or did I just copy the code?
> surely the former!). The MSVC code did not call CommandLineToArgvW
> in those days, but reading the description of that api it all sounds
> very familiar - the state flags for controlling "quoted/unquoted"
> text, even vs odd numbers of backslashes and all that.
>
> I didn't find it difficult to create command-line strings to call C
> programs, given what I wanted those programs to see as argv[n] with
> n>0. I think it was just a case of quoting all arguments, then
> n>applying quoting rules as docuemented for CommandLineToArgvW to
> n>handle nested quotes/backslashes.
>
> But I can see a sticky problem - the MSVC parsing for argv[0] was
> completely separate from thr main loop handling other arguments. The
> logic was considerably simplified, assuming that argv[0] was the path
> for the module being invoked. Since that is expected to be a valid
> file system path, the logic did not handle nested quotes etc.. I
> think the logic was just:
>
> - if 1st char is a DQUOTE, copy chars for argv[0] up to next DQUOTE
> or null terminator. (enclosing DQUOTE chars are not included)
> - else copy chars for argv[0] up to next whitespace or null
> terminator. (all chars are included, I think including DQUOTE should
> it occur)
>
> Given this, it would not be possible to create certain argv[0]
> strings containing quotes etc., and I understand that the likes of
> execve() allow that possibility. So I don't know what should happen
> for this case. E.g. I don't see there is a command-line that gives
> argv[0] the string "\" ". This was never a problem for me in
> practice.
>
> There would always be at least an argv[0] with this logic, so MSVC
> ensures argc>0 and argv[0] != NULL. (Of course, MSVC is not
> "Windows". Various posters in this thread seem to be asking "what
> does /Windows/ do regarding argc/argv?" as though the OS is
> responsible for setting them.)
>
> >
> > More interesting and meaningful question is how to do the reverse.
> > I.e. how to convert an argv[] array into flat form in a way that
> > guarantees that CommandLineToArgvW() parses it back into original
> > form? Is it even possible in general case or there exist limitations
> > (ignoring, for sake of brevity, 2*15-1 size limit)?
>
> Yes, programmers need this if they need to create a process to invoke
> some utility program which will see particular argv parameters.
> Users are used to typing in command-lines as a string, e.g. at a
> console, so I suppose they don't normally need to think about the
> argv[] parsing; they can just build the required command-line and use
> that. (But it's a problem in the general case.)
>
I hoped that Microsoft's implementation of _spawnv() at least
makes an effort at reverse transformation. But test shows that it
does not. _spawnl() appears to do something very dumb - just concatenate
all argv[] strings inserting one space character between parts.
So, it has troubles not just with double quotes but even with spaces
within arguments.
> The argc/argv problem seemed easy enough in practice if we only need
> to handle the "real" arguments argv[n] with n>0. (Involving CMD.EXE
> introduced much worse complications, as you might imagine. But
> generally I always thought that MS wasn't really interested in
> /documenting/ how programmers should do things like this, in the same
> way they never bothered explaining exactly how CMD processing worked.
> Probably because it was forever changing!... Put another way, for
> many years they were really more focussed on admins clicking buttons
> in some GUI!)
>
To be fair, powershell exists for many more years than WinNt family was
existing before emergence of powershell.
The problem with it, at least IMHO, is a second system syndrome.
command.com and to significant extent cmd.exe as well, seen as
programming language was too weak and too primitive. With Powershell
they went too far in the opposite direction - its rather powerfull, as
programming language, but nott as simple at simple tasks as one expects
from OS shell.
So, considering that fewer and fewer people with programmer's attitude
are employed as admins, it's no wonder that most of them are incapable
to write powershell scripts by themselves. At best, they can cat&past.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
