5 ms·

This seems similar to the way command like arguments work on windows. On Linux, the system call für spawning a process uses a string array for them. On window

by nikeee 4y ago

This seems similar to the way command like arguments work on windows. On Linux, the system call für spawning a process uses a string array for them. On windows, it's a single string. The string needs to be parsed by the application, making escape sequences in command line arguments implementation defined by the compiler/runtime/etc. https://nullprogram.com/blog/2022/02/18/ https://nullprogram.com/blog/2022/02/18/ Some examples are here: https://daviddeley.com/autohotkey/parameters/parameters.htm#WINNOSTANDARD https://daviddeley.com/autohotkey/parameters/parameters.htm#...

chasil 4y ago
In theory, a POSIX layer in Windows will implement the exec() family of system calls. The Windows (NT) kernel was built to conform to POSIX, although this functionality was removed, then reimplemented and expanded. 'Broad software compatibility was initially achieved with support for several API "personalities", including Windows API, POSIX, and OS/2 APIs – the latter two were phased out starting with Windows XP.' https://en.m.wikipedia.org/wiki/Windows_NT#Major_features https://en.m.wikipedia.org/wiki/Windows_NT#Major_features
- yellowapple 4y ago
  IIRC, WSL1 was another such "personality". Disappointing that WSL2 dropped that in favor of what's basically a glorified VM; maybe that's just easier to do than maintaining a (presumably clean-room, given the need to comply with the GPLv2 if any actual Linux code was ever used) reimplementation of the Linux userspace ABI?
wahern 4y ago
> This seems similar to the way command like arguments work on windows. The previous poster overstates things. Environment variables passed to the process by the kernel[1] are NUL-delimited, including a double-NUL (or zero-length pair) to terminate the list of name=value pairs. Neither is there any syntactical ambiguity, as within each NUL-terminated pair the first '=' character delimits the variable name from the value, regardless of whether there are subsequent '=' characters. So there's no real parsing of the name=value content, only locating each NUL character in turn as a C array is built up by the entry code. The only limitation is that neither names nor values can contain the NUL character, and names cannot contain a '=' character. The process startup code uses the exact same logic for constructing argv as it does for constructing environ/envp as they're both passed by the kernel in the same manner, including the same NUL-delimited structure. In fact, they're written as one long, serial sequence to the stack, above or beneath (depending on stack direction) the initial stack frame setup for the entry point. And usually argv and environ/envp arrays simply hold pointers directly to this memory region, at least initially. On Linux /proc/$$/environ reads out this region, so it won't necessarily reflect a process' actual environment variables once a process starts changing them. [1] For both Linux and, at least historically, the BSDs.
- zokier 4y ago
  The point I was trying to get across is that environment doesn't need to be list of name=value pairs, it's just list of strings and you can put anything in there.

by nikeee 4y ago

chasil 4y ago

In theory, a POSIX layer in Windows will implement the exec() family of system calls. The Windows (NT) kernel was built to conform to POSIX, although this functionality was removed, then reimplemented and expanded. 'Broad software compatibility was initially achieved with support for several API "personalities", including Windows API, POSIX, and OS/2 APIs – the latter two were phased out starting with Windows XP.' https://en.m.wikipedia.org/wiki/Windows_NT#Major_features https://en.m.wikipedia.org/wiki/Windows_NT#Major_features

yellowapple 4y ago
IIRC, WSL1 was another such "personality". Disappointing that WSL2 dropped that in favor of what's basically a glorified VM; maybe that's just easier to do than maintaining a (presumably clean-room, given the need to comply with the GPLv2 if any actual Linux code was ever used) reimplementation of the Linux userspace ABI?

wahern 4y ago

> This seems similar to the way command like arguments work on windows. The previous poster overstates things. Environment variables passed to the process by the kernel[1] are NUL-delimited, including a double-NUL (or zero-length pair) to terminate the list of name=value pairs. Neither is there any syntactical ambiguity, as within each NUL-terminated pair the first '=' character delimits the variable name from the value, regardless of whether there are subsequent '=' characters. So there's no real parsing of the name=value content, only locating each NUL character in turn as a C array is built up by the entry code. The only limitation is that neither names nor values can contain the NUL character, and names cannot contain a '=' character. The process startup code uses the exact same logic for constructing argv as it does for constructing environ/envp as they're both passed by the kernel in the same manner, including the same NUL-delimited structure. In fact, they're written as one long, serial sequence to the stack, above or beneath (depending on stack direction) the initial stack frame setup for the entry point. And usually argv and environ/envp arrays simply hold pointers directly to this memory region, at least initially. On Linux /proc/$$/environ reads out this region, so it won't necessarily reflect a process' actual environment variables once a process starts changing them. [1] For both Linux and, at least historically, the BSDs.

zokier 4y ago
The point I was trying to get across is that environment doesn't need to be list of name=value pairs, it's just list of strings and you can put anything in there.