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.
Same with $PATH and other environment variables. You learn this the hard way with cron. I use full pathnames for everything in a cron script because it's too much work to reason about how the cron environment differs from my normal working environment or even a root shell's normal environment.
I think I could be ok with it, as long as I can query it. Preferable if I have a way to directly interact with it that isn't just moving things around; though honestly this is no different than many physical machines. Consider, what does the accelerator pedal do in a car that is not in gear? And consider that changing gears is done on a completely separate input mechanism.
(Really, people don't engage more with physical machines to consider programming. We insist that everything has to be distilled down to symbolic functions. Preferably limited inputs and a single output. If only life was so accommodating.)
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.
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.
>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".
I remember that NT4 did not have "current directory" context for each process. But but apparently[1] windows 2000 had it already. So what you write above is per process and not per logged in user right?
Asking, because I remember that Citrix which did Terminal Server 4.0 for NT4 had to license windows source code to be enable to make changes for their product at least somehow working with NT4. Up till that time Winddows did not keep current directory per process or at least user, but it was a global state.
So if you changed with "cd" current directory it changed for all processes which was a big issue for Citrox as they did look a way to make Windows a server class system, where each user had distinct environments with distinct default directories etc.
For me as I heard that then I did not understand what was Microsoft thinking letting still with NT such misfeatures remain shipped product and especially when they had real talent Dave Cutler been working on it.
I haven't been using windows besides using Visio a separate local VM since turn of century. So is Windows been since 2000 etc. a real multitasking multiuser system or does it still suffer such handicaps it had at least before?
[1] Microsoft licensed Citrix made changes and RDP protocol they had developed, then brought Server 2000 with terminal server product to compete with Citrix Terminal Server.
`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.
It was certainly weird for me coming from RISC OS. In that case, even though each drive has its own namespace (like with DOS/Windows), there's not just one "current directory" per session - there is in fact only one "current directory" per drive over the entire OS! As such, changing the current directory in one place would affect all relative path accesses using that drive, even in other programs.
It was common practice when writing RISC OS programs (and recommended by Acorn) to store your application's directory path into a system variable, and then use that to refer to all the ancillary files you needed.
Top level engineers and other VIPs are people too. And it is often surprising how "low" they can get.
We may imagine the CEO of a large company in his throne room, only reachable through his servant and only for matters of utmost importance, billion dollar contracts and all that. And sure, there is that, but not just that.
You may occasionally find out that the guy who a replaced a defective Ethernet cable on the intern's computer was that CEO. Or the lead developer of a AAA game patiently explaining some basic functionality to a random gamer. A CTO may pick up a random support call. So Raymond Chen debugging an "obvious" problem in a .bat script, not at all surprising to me.
It has already happened to me that on a support call where I expect some underpaid grunt, find that the guy is really good, patient and friendly, only to end up discovering that I just talked to the one who built the whole thing. Makes my day when it happens.
It think that if I was some kind of VIP top level whatever, I would cherish these moments. Simple things, genuine human contact, away from the big responsibilities tied to my position. And even from a professional perspective, getting a feel for what happens down there is important.
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.
I'm sorry but why would that bother you? Is my experience not valid any longer?
My point was: it is not at all surprising that a lvl 70 was poking through active support tickets because many of us did the same thing. I retired at Chen's level btw.
I don't know how Chen discovered this issue of course but it could have been exactly how I described it.
> I'm sorry but why would that bother you? Is my experience not valid any longer?
What? Huh? I have no idea what you think I meant but it's not what I meant.
I'm making a simple point: His backlog is not the reason he's talking about a ticket like this in 2026.
Either he took this ticket this year-ish, or he wrote this year-ish about something that happened long before. It is not the case that he wrote this post years and years ago and it was sitting in the backlog for that long.
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.
I'm sorry, but that is kind of hilarious. I was lucky that I rarely had to deal with people like that. Most of the time is was low-level C folks who had found a real bug in one of the tools, compilers, etc.
> 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.
Yup. And since applications load DLLs from their working directory by default, and opening a document sets the working directory... you'd better make sure you never open a document from an untrusted folder.
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".
The Process Environment Block (PEB) should provide this info.
Process Explorer (Sysinternals) and System Informer both provide access to this info. There are powershell commands that will allow you to inspect it too.
If I were to guess, it's because the program has an extension associating with an interpreter application, and that association is handled by the Windows Shell framework's app/document launching API (like ShellExecuteEx, if I dimly recall), which is used by Explorer for running programs, but not by batch files.
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.
(Really, people don't engage more with physical machines to consider programming. We insist that everything has to be distilled down to symbolic functions. Preferably limited inputs and a single output. If only life was so accommodating.)
And you think adding to it will improve things?
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.
Why is it horrible? It's just basic and well-documented system behavior.
(navigate to one directory)
src=$PWD
(navigate to another directory)
dst=$PWD
(navigate wherever you like)
You can now do: ffmpeg -i "$src/scene1.mp4" "$dst/output-scene.mp4"
If you avoid spaces and other special characters in directory and file names, then you can skip the quotes.
This is conveniently not limited to a system wide partitioning scheme.
It allow you to pretend a directory is a drive, and thus gives you multiple current directories on a drive.
This won't actually work because multiple current directories are a fiction of cmd.exe
I remember that NT4 did not have "current directory" context for each process. But but apparently[1] windows 2000 had it already. So what you write above is per process and not per logged in user right?
Asking, because I remember that Citrix which did Terminal Server 4.0 for NT4 had to license windows source code to be enable to make changes for their product at least somehow working with NT4. Up till that time Winddows did not keep current directory per process or at least user, but it was a global state.
So if you changed with "cd" current directory it changed for all processes which was a big issue for Citrox as they did look a way to make Windows a server class system, where each user had distinct environments with distinct default directories etc.
For me as I heard that then I did not understand what was Microsoft thinking letting still with NT such misfeatures remain shipped product and especially when they had real talent Dave Cutler been working on it.
I haven't been using windows besides using Visio a separate local VM since turn of century. So is Windows been since 2000 etc. a real multitasking multiuser system or does it still suffer such handicaps it had at least before?
[1] Microsoft licensed Citrix made changes and RDP protocol they had developed, then brought Server 2000 with terminal server product to compete with Citrix Terminal Server.
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.
It was common practice when writing RISC OS programs (and recommended by Acorn) to store your application's directory path into a system variable, and then use that to refer to all the ancillary files you needed.
Whether or not the gun fires comes down to what you're most accustomed to
We may imagine the CEO of a large company in his throne room, only reachable through his servant and only for matters of utmost importance, billion dollar contracts and all that. And sure, there is that, but not just that.
You may occasionally find out that the guy who a replaced a defective Ethernet cable on the intern's computer was that CEO. Or the lead developer of a AAA game patiently explaining some basic functionality to a random gamer. A CTO may pick up a random support call. So Raymond Chen debugging an "obvious" problem in a .bat script, not at all surprising to me.
It has already happened to me that on a support call where I expect some underpaid grunt, find that the guy is really good, patient and friendly, only to end up discovering that I just talked to the one who built the whole thing. Makes my day when it happens.
It think that if I was some kind of VIP top level whatever, I would cherish these moments. Simple things, genuine human contact, away from the big responsibilities tied to my position. And even from a professional perspective, getting a feel for what happens down there is important.
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
That’s a rare privilege!
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'm sorry but why would that bother you? Is my experience not valid any longer?
My point was: it is not at all surprising that a lvl 70 was poking through active support tickets because many of us did the same thing. I retired at Chen's level btw.
I don't know how Chen discovered this issue of course but it could have been exactly how I described it.
What? Huh? I have no idea what you think I meant but it's not what I meant.
I'm making a simple point: His backlog is not the reason he's talking about a ticket like this in 2026.
Either he took this ticket this year-ish, or he wrote this year-ish about something that happened long before. It is not the case that he wrote this post years and years ago and it was sitting in the backlog for that long.
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
Process Explorer (Sysinternals) and System Informer both provide access to this info. There are powershell commands that will allow you to inspect it too.
Am I close?