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.
`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\`.
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?
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.
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.
> 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.
> 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.
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.
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\`.
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?
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.
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.
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.