[skissane]

> Another Windows oddity: each drive letter has its own current directory

For NT-based Windows: only in cmd.exe, and other apps which choose to support the same convention. The NT/Win32 API only supports a single per-process directory

There is actually space in NT data structures to store per-drive current directory, but no released version has ever used it. I think they planned to implement the idea in NT itself (or NT’s implementation of Win32), but then settled on just having a single current directory per-process, and faking the old behaviour in cmd.exe using environment variables

By contrast, Windows 1.x/2.x/3.x/9x/Me retained the old DOS behaviour of per-drive current directories, so Win32 does actually have them if you mean the Win32s or 9x/Me implementations of Win32.

Separately, both Linux and macOS support per-thread current directories separate from the per-process current directory, although by default all threads use the process-wide current directory. Last I checked, the macOS implementation was a bit more sophisticated, in that on Linux once the link between process and thread current directory was severed, it was gone for the lifetime of the thread; by contrast, macOS has an API to re-establish it.

[momoraul]

Ah, fair. On modern Windows it's really cmd.exe faking it with env vars, not the API. Didn't know NT reserved space for per-drive CWDs and then never used it.

[skissane]

> Didn't know NT reserved space for per-drive CWDs and then never used it.

RTL_USER_PROCESS_PARAMETERS has a field “RTL_DRIVE_LETTER_CURDIR CurrentDirectores[32]” (note the misspelling). And then RTL_DRIVE_LETTER_CURDIR is defined as:

    typedef struct _RTL_DRIVE_LETTER_CURDIR
    {
         WORD Flags;
         WORD Length;
         ULONG TimeStamp;
         STRING DosPath;
    } RTL_DRIVE_LETTER_CURDIR, *PRTL_DRIVE_LETTER_CURDIR;

But, AFAIK, Microsoft has never shipped anything that uses it. My own impression is this was the original design for handling compatibility with the DOS current directory behaviour, but they ended up deciding on doing it in cmd.exe instead. And of course, NTVDM and 16-bit Windows app support, but I think that just used the 16-bit DOS code and its associated data structures.

https://www.geoffchappell.com/studies/windows/km/ntoskrnl/in...