> The cd command is also buggy: It doesn't work for directories located on CD/DVD drives (You can however still access content on CD/DVD using direct paths):

> cd d:\

That's not a bug, is it? `cd` requires the `/d` flag to switch drives, or you can just type the drive letter name.

https://superuser.com/questions/135214/using-cd-command-in-w...

Yeah, in DOS & Windows, each drive has its own working directory. "cd d:\" changes the working directory for D: but keeps the current drive as C:

# Change directory

C:\> cd WINDOWS

# Switch drive

C:\WINDOWS> D:

# Change directory again

D:\> cd DATA

# Switch drive again

D:\DATA> C:

# It remembered that we were in WINDOWS on C:

C:\WINDOWS>

# Change directory on D:

C:\WINDOWS> cd D:\POTATO

# That didn't change the directory for our shell

C:\WINDOWS>

# Switch over to D:

C:\WINDOWS> D:

# It did change the directory for D:, though

D:\POTATO>

> Yeah, in DOS & Windows, each drive has its own working directory.

On Windows, no, it doesn't, it's an illusion maintained by CMD using environment variables, for compatibility with DOS. Quoting Raymond Chen (https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14...):

"Win32 does not have the concept of a separate current directory for each drive, but the command processor wanted to preserve the old MS-DOS behavior because people were accustomed to it (and batch files relied upon it). The solution was to store this “per-drive current directory” in the environment, using a weird-o environment variable name so it wouldn’t conflict with normal environment variables."

I mean, functionally the parent comment is accurate. There is a working directory kept for each drive.

Just because in Windows it's done using environment variables doesn't mean that the net experience isn't "each drive has a working directory".

> I mean, functionally the parent comment is accurate.

Not really-this is something only cmd.exe does-not the Windows APIs, not any other Windows program (well, any other program could support the same undocumented environment variables as cmd.exe does, but very few do-I’m not aware of any).

If someone mistakenly thinks this is how Windows works, as opposed to only one small component of it, they are going to get confused at some point.

Where else but cmd.exe does the OS keeping track of the current working directory even apply?

A process is associated with a current working directory, which you can change[1].

[1]: https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...

Every process in the system has a current working directory, which is used to resolve all relative paths passed to (Win32) file system APIs. That is a single working directory per-process, not per-drive. In this regard, Windows’ behaviour is very similar to that of Unix-like systems (including Linux and macOS)

Does DOS have a per-process per-drive working directory? That would be the only time where they'd be comparable. I would expect the system for managing per-process and per-terminal CWDs to be completely separate and not interlinked.

> Does DOS have a per-process per-drive working directory?

In DOS, there is a system-wide current drive, and system-wide per-drive current directory. For a Windows DOS box (and 16-bit Windows apps), "system-wide" is per VM, maintained by the virtual machine manager (VMM in Windows 2.x/3.x/9x/Me, NTVDM for NT and successors)

In 32-bit/64-bit Windows, there is a single directory per-process. CMD.EXE provides an (incomplete) emulation of the old DOS model using environment variables; COMMAND.COM performed no equivalent function, it relied on the DOS kernel to track them on its behalf, essentially the same as any other DOS program did

> I would expect the system for managing per-process and per-terminal CWDs to be completely separate and not interlinked.

It isn't actually "per-terminal"; a Windows console in itself has no concept of current drive or directory, and can simultaneously host multiple processes each with different current directories. Consoles also have nothing to do with this "per-drive current directory" emulation performed by CMD.EXE, which is implemented using per-process environment variables

What is is on the back end makes no difference. If you want to access your DVD drive as a user, you have to access it via drive letter... Open windows explorer, add a USB drive, DVD drive, secondary hard drive... they come up by default with their own drive letter, and unless you mount the disk to a path locally, that's how users will see the drive. And if you mount it to an existing path, guess where it ends up? C:\mymounteddrive. Drive letters are critical to Windows still.

just use "pushd" instead of "cd" - as bonus you get directories saved to stack that you can "popd", much like unix.

I often start my .bat/.cmd files with

    @echo off
    pushd "%~dp0"

e.g. no matter from where, ensure that the current folder is the folder of the .bat/.cmd file

This thing is literally made for running, say, a very specialized application that does manufacturer-level hardware testing/validation, likely in an automated fashion, spitting the result out to the display, network, etc. Looking at this as an interactive shell/OS to be used directly is thinking about it the wrong way.