With drive letters, a neat functionality in DOS/Windows command prompts (don't ask me about Powershell) is that each letter can have its own "current directory".
So if you have ffmpeg.exe in C:\Program Files\FFMpeg\bin, and you have some source files in D:\SourceVideos, and you want to process them in ffmpeg and output them to E:\Output you can do:
C: (to navigate to the C: drive)
cd "C:\Program Files\FFMpeg\bin"
E: (to navigate to the E:\ drive)
cd D:\SourceVideos (you remain in E:\, but the "current directory" for D: has been changed).
cd Output (to enter E:\Output)
You can now do C:ffmpeg.exe -i D:scene1.mp4 output-scene1.mp4
and Windows accesses the files in the "current" directory on each drive letter.
Every time you rely on the current working directory, that's invisible state then. Even without multiple single-letter directories each maintaining their own state.
In most shells, the prompt is configurable. So you have yours configured to display the current path, as most do. It would be trivial to change it to display the current path for all namespaces across which this state is managed.
But a lot of times, you also need to think about executing programs from within a script, where you don't have this prompt. Thus, it's invisible state.
I didn't say that; I think pointing out the difficulty and danger in maintaining more invisible state than one already does is a perfectly valid criticism. But that wasn't the argument being made, at least not how I read it.
`cd` does not travel to an "absolute path". It changes the working directory for the specified drive. Your prompt will still show you the old path (at A:), because you've not changed the folder for the current working drive, which yes, is kind of an insane concept.
If you want to actually change the working directory and drive at the same time (which is the "absolute path" idea you have), you do `cd /d D:\whatever\`.
Yeah I understood how it actually works, I'm just saying it's a potential huge footgun for someone writing a script coming from unix derivates.
At least if I had to write one, I saw cd is available and seemingly working as expected, and wrote a cd to an arbitrary target I would not expect it to behave that way at all - my expectation would be that either the next command always runs in the cd'd path, or at least that cd errors on a path in a different drive.
The post doesn’t mention a year. Early Microsoft Windows was very badly documented and the docs were difficult to search, so it wouldn't surprise me that it took senior level support to know that fact.
i envy the folks who can actually make sense of msdn docs. they were tedious and overwhelming decades before ai made that the premiere style this year.
some parts are better than others, but god is it a quest to find anything in there.
> Or rather, maybe, how bad are the initial support levels that couldn't figure out basic functionality like this and it was escalated to Chen?
On something like Unix, I suspect this would be easy to figure out since programs typically dump diagnostic information to the terminal. On Windows, this would likely be thing learned through prior experience (especially since it would depend upon the program being launched).
Senior people like Raymond Chen (or at least the good ones) often get to where they are by doing some amount of work that's "below them" or outside their scope in order to keep their understanding of the full stack up to date.
It wouldn't surprise me if he's periodically snooping the lowest level support queues from time to time to understand what kinds of issues customers face, where the pain points are, etc, etc.
I was an engineer on the Visual Studio team. Many of the issues I worked on were things I found interesting. I wouldn't be surprised if Chen was browsing through open tickets, found this one, and grabbed it.
There's probably a dozen posts at least for getting applications to find their dependencies because of one behavior or another. COM servers, .Net. Trying to get running apps to use an updated PATH or other environment variable.
He's telling stories from the past either way. The blog backlog isn't very important.
In an interview he said the backlog has varied from 3 to 18 months. Pretty negligible in terms of his career advancement. This isn't something he wrote ages ago.
Right... but my point was that even distinguished engineers at MS (lvl 70+) go "ticket diving" from time to time. It was somewhat contentious because juniors complained that all the "fun" tickets were taken by seniors.
I was working on some Windows Media DRM stuff and would get pinged with the really loopy support emails, most of the time not to have me fix them, just more of a heads-up. One said "WHY THE FUCK ARE YOU ON MY PC EVERY MORNING GET THE FUCK OFF MY COMPUTER". I actually started to reply to this chap to see if I could get some sense, but a VP was nearby and saw my screen. They picked up my keyboard, wrote "FUCK OFF" and hit send.
> Explorer sets the current directory of the program to the directory containing the thing that you double-clicked
I found the linked article to informative and confirming my suspicion: "The thing that you clicked" doesn't have to be the executable - it could also be a document with the executable registered as launch handler, in which case the current directory will be the directory of the document.
Would be interesting to know how links and items in shell namespaces are handled.
Well, there is no concept of "the current directory" in the UI of explorer.exe the way there is in CMD.EXE or Bash. You can have multiple directories open and none of them are privileged over the others.
I think of cultures of command line programs: the node ecosystem very much has the idea that a program "lives" in a a certain directory and you're always going to work with that program in that directory. This is convenient in a lot of ways but... say you are writing a data analysis program and you want to put it on your $PATH and then cd to the place where your data lives and do your work there?
> Well, there is no concept of "the current directory" in the UI of explorer.exe the way there is in CMD.EXE or Bash. You can have multiple directories open and none of them are privileged over the others.
Wouldn't you just have multiple explorer.exe windows open, each with a different folder open? Wouldn't that be similar to having multiple cmd.exe or Bash processes open, each with a different current directory?
I am using my own combination file browser/terminal. I landed somewhat arbitrarily at the each tab has its own CWD (PathBuf field), ie how terminals do it. Not the only right answer, but has not been a blocker, and simplifies some things knowing there is [for that tab] a single CWD which can be used to manage bookmarks, assess if the we're in* a git repo, rust project etc.
This approach may present limitations later; will change A/R. But simple = good for now!
Yep, the first version of DOS wanted to be "like CP/M but on 8086 with a 640k address space" so it had drive letters and the second version wanted to be "like Unix but single user and with a funny memory model" so it had nested directories!
This just shows the command line was badly designed to begin with.
If CLI programs received already-opened file handles instead of pathname strings, most programs would have no need to have the concept of a "current directory" at all. It could be something purely internal to the command-line shell.
It would also be more fitting for a capability-based OS instead of one where every program has an ambient permission to access anything in the whole file system.
So am I, as a terminal user, supposed to track file handles now?
CLI programs might be used by an actual human, not necessarily called by a script.
UNIX/Linux already has a compromise here with stdin/stdout/stderr, the convention that those are fds 0, 1, and 2, and stream redirection in shells. You can already redirect raw fds in bash on linux, that's exactly what "something > something.stdout.txt 2> something.stderr.txt" does.
A related issue is when you set up automation, and it turns out the automation script runs as a different user with different authorizations from the user who tested the script. It's just one of those little annoyances that appears when you try to go from "works on my machine" to "works".
So if you have ffmpeg.exe in C:\Program Files\FFMpeg\bin, and you have some source files in D:\SourceVideos, and you want to process them in ffmpeg and output them to E:\Output you can do:
C: (to navigate to the C: drive)
cd "C:\Program Files\FFMpeg\bin"
E: (to navigate to the E:\ drive)
cd D:\SourceVideos (you remain in E:\, but the "current directory" for D: has been changed).
cd Output (to enter E:\Output)
You can now do C:ffmpeg.exe -i D:scene1.mp4 output-scene1.mp4
and Windows accesses the files in the "current" directory on each drive letter.
But a lot of times, you also need to think about executing programs from within a script, where you don't have this prompt. Thus, it's invisible state.
And you think adding to it will improve things?
Why is it horrible? It's just basic and well-documented system behavior.
What a footgun.
If you want to actually change the working directory and drive at the same time (which is the "absolute path" idea you have), you do `cd /d D:\whatever\`.
At least if I had to write one, I saw cd is available and seemingly working as expected, and wrote a cd to an arbitrary target I would not expect it to behave that way at all - my expectation would be that either the next command always runs in the cd'd path, or at least that cd errors on a path in a different drive.
Whether or not the gun fires comes down to what you're most accustomed to
Or rather, maybe, how bad are the initial support levels that couldn't figure out basic functionality like this and it was escalated to Chen?
Or maybe he was on a project working directly with the client already, so this was just part of whatever he was working on.
some parts are better than others, but god is it a quest to find anything in there.
On something like Unix, I suspect this would be easy to figure out since programs typically dump diagnostic information to the terminal. On Windows, this would likely be thing learned through prior experience (especially since it would depend upon the program being launched).
It wouldn't surprise me if he's periodically snooping the lowest level support queues from time to time to understand what kinds of issues customers face, where the pain points are, etc, etc.
It's like Patreon, accessible to staff first
I'd be very, very surprised if MS had Raymond motherfuckin' Chen looking at support queues in 2026.
In an interview he said the backlog has varied from 3 to 18 months. Pretty negligible in terms of his career advancement. This isn't something he wrote ages ago.
I found the linked article to informative and confirming my suspicion: "The thing that you clicked" doesn't have to be the executable - it could also be a document with the executable registered as launch handler, in which case the current directory will be the directory of the document.
Would be interesting to know how links and items in shell namespaces are handled.
I think of cultures of command line programs: the node ecosystem very much has the idea that a program "lives" in a a certain directory and you're always going to work with that program in that directory. This is convenient in a lot of ways but... say you are writing a data analysis program and you want to put it on your $PATH and then cd to the place where your data lives and do your work there?
Wouldn't you just have multiple explorer.exe windows open, each with a different folder open? Wouldn't that be similar to having multiple cmd.exe or Bash processes open, each with a different current directory?
This approach may present limitations later; will change A/R. But simple = good for now!
That's a purer form of current directory than cmd, which has one per drive.
If CLI programs received already-opened file handles instead of pathname strings, most programs would have no need to have the concept of a "current directory" at all. It could be something purely internal to the command-line shell.
It would also be more fitting for a capability-based OS instead of one where every program has an ambient permission to access anything in the whole file system.
CLI programs might be used by an actual human, not necessarily called by a script.
UNIX/Linux already has a compromise here with stdin/stdout/stderr, the convention that those are fds 0, 1, and 2, and stream redirection in shells. You can already redirect raw fds in bash on linux, that's exactly what "something > something.stdout.txt 2> something.stderr.txt" does.
DOS provides the same