From: news.dead.person.stones@darjeeling.plus.com
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/n
-shellapi-commandlinetoargvw
> https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-com
and-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 applying quoting rules as docuemented for CommandLineToArgvW to 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.)
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!)
>
> Microsoft certainly has reverse conversion implemented, e.g. here:
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/refere
ce/spawnv-wspawnv
>
> But I am not aware of command line serialization part available as a
> library call in isolation from process creation part.
>
> I binged around and googled around, but all I was able to find was the
> name of the function that performs the work:
> __acrt_pack_wide_command_line_and_environment
>
> I was not able to find the source code of the function.
>
> [O.T.]
> I am sure that 15, 10 or even 5 years ago Google would give me link to
> the source in a second. Or, may be, 5 years ago Google already
> wouldn't, but Bing still would.
> But today both search engines are hopelessly crippled with AI and do not
> appear to actually search the web. Instead, the try to guess the
> answer I likely want to hear.
> [/O.T.]
I hear you on that! Also [O.T.] I used to have access to most of Windows
source code as part of
some Windows source code sharing program, so could have found answers to this
sort of question with
minimal effort. (My employer met the criteria based on number of Windows
servers/desktops deployed.
There were various hoops you had to jump through with contracts being
regularly (re)signed by
company board level directors and the likes. Wonder if they still do that...
Anyway I'm long
retired now.)
Mike.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
