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.
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?
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.
> 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).
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 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.
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.
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.
> 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.
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?
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 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.