In this way, NT is similar to Unix in that many things are just files part of one global VFS layout (the object manager name space).
Paths that start with drive letters are called a "DOSPath" because they only exist for DOS compatibility. But unfortunately, even in kernel mode, different sub systems might still refer to a DOSPath.
Powershell also exposes various things as "drives", pretty sure you could create your own custom drive as well for your custom app. For example, by default there is the 'hklm:\' drive path:
It's baffling than after 30 years, Windows is still stuck in a weird directory naming structure inherited from the 80's that no longer make sense when nobody has floppy drives.
> Windows is still stuck in a weird directory naming structure inherited from the 80's that no longer make sense when nobody has floppy drives.
I think you could make this same statement about *nix, except it's 10 years _worse_ (1970s). I strongly prefer the fhs over whatever MS thinks it's doing, but let's not pretend that the fhs isn't a pile of cruft (/usr/bin vs /bin, /etc for config, /media vs /mnt, etc)
Streaming as defacto metaphor for file access goes back to tape drives. Random Access patterns make more sense with today’s media yet we’re all still fscanf-ing
Of course there are alternatives but the resource-as-stream metaphor is so ubiquitous in Unix, it’s hard to avoid.
Unix starts at root, which is how nature intended. It does not change characteristics based on media - you can mount a floppy at root if you want.
Why get upset over /media vs /mnt? You do you, I know I do.
For example The Step CA docs encourage using /etc/step-ca/ (https://smallstep.com/docs/step-ca/certificate-authority-ser...) for configuration for their product. Normally I would agree but as I am manually installing this thing myself and not following any of the usual docs, I've gone for /srv/step-ca.
I think we get enough direction from the ... "standards" ... for Unix file system layouts that any reasonably incompetent admin can find out which one is being mildly abused today and get a job done. On Windows ... good luck. I've been a sysadmin for both platforms for roughly 30 years and Windows is even odder than Unix.
Thinking of it in terms of namespaces might help; it's not that the drive is special, it's that there's a view that starts from / and one disk filesystem happens to be dropped there and others are dropped elsewhere; with something like initramfs there aren't any drives on /, just a chunk of ram, though you usually pivot to a physical one later (many linux-based embedded systems don't because your one "drive" is an SD card that can't handle real use, so you just keep the "skeleton" in memory and drop various bits of eMMC or SD or whatever into the tree as-convenient.)
The point is that any filesystem can be chosen as the OS’s root.
The root of all other filesystems - there could be multiple per drive - is where you tell the filesystem to be mounted, or in your automounter’s special directory, usually /run/media, where it makes a unique serial or device path.
I like being able to run games from early 2000s. Being able to write software that will still run longer after you're gone used to be a thing. But here we are with linux abandoning things like 'a.out'. Microsoft doesn't have the luxury to presume that it's users can recompile software, fork it, patch it,etc.. When your software doesn't work on the latest Windows, most people blame Microsoft not the software author.
Ok, I prefer to use software which is future compatible, like ZFS, which is 128-bit.
“The file system itself is 128 bit, allowing for 256 quadrillion zettabytes of storage. All metadata is allocated dynamically, so no need exists to preallocate inodes or otherwise limit the scalability of the file system when it is first created. All the algorithms have been written with scalability in mind. Directories can have up to 248 (256 trillion) entries, and no limit exists on the number of file systems or the number of files that can be contained within a file system.”
Someone did some back-of-the-napkin math and calculated that to populate every byte in a 128 bit storage pool, you'd need to use enough energy to literally boil the oceans. There was a blog post on oracle.com that went into more detail, but no link into Oracle survives more than 10 years.
> Directories can have up to 248 (256 trillion) entries
It took me a minute to figure out that this was supposed to be 2^48, but even then that's ~281 trillion. What a weird time for the tera/tibi binary prefix confusion to show up, when there aren't even any units being used.
I was playing with some asm code and generating a.out with nasm, got stuck on why it wouldn't load..turns out linux stopped supporting it. When they say "no one uses it" they mean packages and stuff, they don't care about private code you have lying around and other use cases. With a widely deployed platform like windows, they can't assume things like that. There are certainly very valid business application that go back decades. There are literally systems that have 20+ years up time out there.
I don’t like running games from the early 2000s outside of a sandbox of some description. If you disagree, it's because we don't have sandboxes which don't suck. Ideally, running old software in a sandbox on a modern OS should be borderline transparent — not like installing XP in a virtual machine.
While I understand the appeal of software longevity, and I think it's a noble and worthy pursuit, I also think there is an under-appreciated benefit in having unmaintained software less likely to function on modern operating systems. Especially right now, where the concept of serious personal computer security for normal consumers is arguably less than two decades old.
Inherited from the 80s? Microsoft effectively inherited drive letters via an 8086 semi-clone of CP/M called QDOS[0], it was the basis for PC-DOS and later MS-DOS. CP/M dates back to 1974.
But Gary Kildall didn't come up with the idea of drive letters in CP/M all on his own, he was likely influenced by TOPS-10[1] and CP/CMS[2], both from the late 60s.
I don't particularly like the Windows naming structure, but it made just as much sense with later removable-media-with-fixed-drives systems (like optical drives) as it did with floppy drives. It maybe makes less sense now that storage is either fixed media or detachable drives, rather than some being removable media in fixed drives, but the period after commonn removable media is a lot shorter than the period after common floppy drives.
(And mostly, I'm talking about using drive letters rather than something like what unix does. C being the first fixed media device, may seem more arbitrary now, but it was pretty arbitrary even in the floppy era.)
Tim Patterson certainly copied it from CP/M and may not have been aware of anything predating it, but according to Wikipedia drive letters have quite a long history: https://en.wikipedia.org/wiki/Drive_letter_assignment
Yeah, try explaining “drive C:” to a kid these days, and why it isn’t A: or B: …
Of course software developers are still stuck with 80 column conventions even though we have 16x9 4K displays now… Didn’t that come from punchcards ???
80 characters per line is an odd convention in the sense that it originated from a technical limitation, but is in fact a rule of thumb perfectly familiar to any typesetting professional from long before personal computing became widespread.
Remember newspapers? Laying the text out in columns[0] is not a random quirk or result of yet another technology limitation. It is the same reason a good blog layout sets a conservative maximum width for when it is read on a landscape oriented screen.
The reason is that when each line is shorter, the entire thing becomes easier to read. Indeed, even accounting for legibility hit caused by hyphenation.
Up to a point, of course. That point may differ depending on the medium and the nature of the material: newspapers, given they deal with solid plain text and have other layout concerns, limit a line to around 50 characters; a book may go up to 80 characters. Given a program is not a relaxed fireside reading, I would place it closer to the former, but there are also factors and conventions that could bring acceptable line length up. For example, indentation and syntax highlighting, or typical identifier length (I’m looking at you, CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter), or editor capability to wrap lines nicely[1].
Finally, since the actual technical limitation is gone, it is actually not such a big deal to violate the line length rule on occasion.
[0] Relatedly, codebases roughly following the 80 character line length limitation unlock more interesting columnar layouts in editors and multiplexers.
[1] Isn’t the auto-wrap capability in today’s editors good enough that restricting line length is pointless at the authoring stage? Not really, and (arguably) especially not in case of any language that relies on indentation. Not that it could not be good enough, but considering code becomes increasingly write-only it seems unlikely we will see editors with perfect, context-sensitive, auto-wrap any time soon.
of typography and not be overly wide, lest my saccadic
motion leads my immersion and comprehension astray.
However when I read code I do not want to scan downwards to complete the semantics of a given expression because that will also break my comprehension and so when a line of code is long I'd prefer for it to remain long unless there are actually multiple clauses
and other conditionally chained
semantic elements
that are more easily read alone
80 chars per line was invented when languages used shortened commands though. Nowadays 120 is more appropriate. Especially in Powershell. Not so much in bash where commands are short, 80 can stay alive there!
I’m very sure this is a myth. Like any good myth, it makes sense on the surface but holds zero water once you look close.
Code isn’t prose. Code doesn’t always go to the line length limit then wrap, and prose doesn’t need a new line after every sentence. (Don’t nitpick this; you know what I’m saying)
The rules about how code and prose are formatted are different, so how the human brain finds the readability of each is necessarily different.
No code readability studies specifically looking for optimal line length have been done, to my knowledge. It may turn out to be the same as prose, but I doubt it. I think it will be different depending on the language and the size of the keywords in the language and the size of the given codebase. Longer keywords and method/function names will naturally lead to longer comfortable line lengths.
Line length is more about concepts per line, or words per line, than it is characters per line.
The 80-column limit was originally a technical one only. It has remained because of backwards compatibility and tradition.
> Of course software developers are still stuck with 80 column conventions
Speak for yourself, all my projects use at least 100 if not 120 column lines (soft limit only).
Trying to keep lines at a readable length is still a valid goal though, even without the original technical limitations - although the bigger win there is to keep expression short, not to just wrap them into shorter lines.
It did, but 80 columns also pretty closely matches the 50ish em/70ish character paragraph width that’s usually recommended for readability. I myself wouldn’t go much higher than 100 columns with code.
While 80 characters is obviously quite short, my experience is that longer line lengths result in much less readable code. You have to try to be concise on shorter lines, with better phrasing.
It really wouldn't be much of a conversation. Historical conventions are a thing in general. Just think of the direction of electron flow.
> even though we have 16x9 4K displays now
Pretty much no normal person uses those at 100% scaling though, so unless you're thinking of the fellas who use a TV for a monitor, that doesn't actually help so much:
- 100% scaling: 6 panels of 80 columns fit, no px go to waste
- 125% scaling: 4 panels of 80 columns fit, 64 px go to waste (8 cols)
- 150% scaling: 4 panels of 80 columns fit, no px go to waste
- 175% scaling: 3 panels of 80 columns fit, 274 px go to waste (34 cols)
- 200% scaling: 3 panels of 80 columns fit, no px go to waste
This sounds good until you need any additional side panels. Think line numbers, scrollbars, breakpoint indicators, or worse: minimaps, and a directory browser. A minimap is usually 20 cols/panel, a directory browser is usually 40 cols. Scrollbar and bp-indicator together 2 cols/panel. Line numbers, probably safe to say, no more than 6 cols/panel.
With 2 panels, this works out to an entire additional panel in overhead, so out of 3 panels only 2 remain usable. That's the fate of the 175% and 200% options. So what is the "appropriate" scaling to use?
Well PPI-wise, if you're rocking a 32" model, then 150%. If a 27" model, then 175%. And of course, given a 22"-23"-24" unit, then 200%. People of course get sold on these for the "additional screen real estate" though, so they'll instead sacrifice seeing the entire screen at once and will put on their glasses. Maybe you prefer to drop down by 25% for each of these.
All of this is to say, it's not all that unreasonable. I personally feel a bit more comfortable with a 100 col margin, but I do definitely appreciate when various files nicely keep to the 80 col mark, they're a lot nicer to work with side-by-side.
I mean its a successful commercial project because it doesnt break things, at least not that often. You can run some really old software on windows. Its kind of taken for granted, but this is just not the norm is most industries.
As for baffling, I mean, I type in things like 'grep' everyday which is a goofy word. I'm not even going to go into all the legacy stuff linux presents and how linux, like windows, tries hard not to break userland software.
Didn't Microsoft drop 16 bit application support in Windows 10? I remember being saddened by my exe of Jezzball I've carried from machine to machine no longer working.
Microsoft has dropped 16-bit application support via builtin emulator (NTVDM) from 64-bit builds of Windows, whether it happens to be Windows 10 or earlier version of Windows, depends on user (in my case, it was Windows Vista). However, you can still run 16-bit apps on 64-bit builds of Windows via third party emulators, such as DOSBox and NTVDMx64.
It does, if you use an old enough version of windows that SUA is available :). I never managed to get fontconfig working so text overlapped its dialogue boxes and the like, but it was good enough to run what I needed.
Are you talking about CPU support? I installed a 32 bit program on basic linux mint just the other day. If I really need to load up a pentium 4 I can deal with it being an older kernel.
That's exactly what I mean, I wish Linux was more like NetBSD in its architecture support. It kind of sucks that it is open source but it acts like a corporate entity that calculates profitability of things. There is one very important reason to support things in open source: Because you committed to it, and you can. If there are practical reasons such as lack of willing maintainers (I refuse to believe out of all the devs that beg to have a serious role in kernel maintenance, none are willing to support i386 - if NetBSD has people, so too Linux), totally understandable.
You'd expect Microsoft to support things because it doesn't make money for them anymore or some other calculated cost reason, but Microsoft is supporting old things few people use even when it costs them performance/secure edges.
Well for now the kernel still supports it. And the main barrier going forward is some memory mapping stuff that anyone could fix.
Though personally, while I care a lot about using old software on new hardware, my desire to use new software on old hardware only goes so far back and 32 bit mainstream CPUs are out of that range.
I think eventually 32 bit hardware and software shouldn't be supported. But there are still plenty of both. We shouldn't get rid of good hardware because it's too old, that's wasteful. 16bit had serious limits but 32 bit is still valid for many applications and environments that don't need >3GB~ ram. For example, routers shouldn't use 64bit processors unless they're handling that much load, die size matter there, that's why they use Arm mostly, and that's why Arm has thumb mode (less instruction width = smaller die size). I'm sure the tiny amounts of money and energy saved by not having that much register/instruction width adds up when talking about billions of devices.
Open source isn't where I'd expect abandonware to happen.
> We shouldn't get rid of good hardware because it's too old, that's wasteful.
Depends on how much power it's wasting, when we're looking at 20 year old desktops/laptops.
> 32 bit is still valid for many applications and environments that don't need >3GB~ ram.
Well my understanding is that if you have 1GB of RAM or less you have nothing to worry about. The major unresolved issue with 32 bit is that it needs complicated memory mapping and can't have one big mapping of all of physical memory into the kernel address space. I'm not aware of a plan to remove the entire architecture.
It's annoying for that set of systems that fit into 32 bits but not 30 bits, but any new design over a gigabyte should be fine getting a slightly different core.
> For example, routers shouldn't use 64bit processors unless they're handling that much load, die size matter there
I don't think that's right, but correct me if I missed something. A basic 64 bit core is extremely tiny and almost the same size as a 32 bit core. If you're heavy enough to run Linux, 64 bit shouldn't be a burden.
Linux goal is only for code compatibility - which makes complete sense given the libre/open source origins. If the culture is one where you expect to have access to the source code for the software you depend on, why should the OS developers make the compromises needed to ensure you can still run a binary compiled decades ago?
Hmm. IME VB6 is actually a particular pain point, because MDAC (a hodgepodge of Microsoft database-access thingies) does not install even on Windows 10, and a line-of-business VB6 app is very likely to need that. And of course you can’t run apps from the 1980s on Windows 11 natively, because it can no longer run 16-bit apps, whether DOS or Windows ones. (All 32-bit Windows apps are definitionally not from the 1980s, seeing as the Tom Miller’s sailboat trip that gave us Win32 only happened in 1990. And it’s not the absence of V86 mode that’s the problem—Windows NT for Alpha could run DOS apps, using a fatter NTVDM with an included emulator. It’s purely Microsoft’s lack of desire to continue supporting that use case.)
As I’ve already said in my initial comment, this is not the whole story. (I acknowledge it is the official story, but I want to say the official story, at best, creatively omits some of the facts.)
NTVDM as it existed Windows NT (3.1 through 10) for i386 leveraged V86 mode. NTVDM on Windows NT (e.g. 4.0) for MIPS, PowerPC, and Alpha, on the other hand, already had[1] a 16-bit x86 emulator, which was merely ifdefed out of the i386 version (making the latter much leaner).
Is it fair of Microsoft to not care to resurrect that nearly decade-old code (as of Windows XP x64 when it first became relevant)? Yes. Is it also fair to say that they would not, in fact, need to write a complete emulator from scratch to preserve their commitment to backwards compatibility, because they had already done that? Also yes.
Yeah, I was surprised by the lack of search results when I was double-checking my post too, but apparently I wasn’t surprised enough, because I was wrong. I mixed up two pieces of Showstopper!: chapter 5 mentions the Win32 spec being initially written in two weeks by Lucovsky and Wood
> Lucovsky was more fastidious than Wood, but otherwise they had much in common: tremendous concentration, the ability to produce a lot of code fast, a distaste for excessive documentation and self-confidence bordering on megalomania. Within two weeks, they wrote an eighty-page paper describing proposed NT versions of hundreds of Windows APIs.
and chapter 6 mentions the NTFS spec being initially written in two weeks by Miller and one other person on Miller’s sailboat.
> Maritz decided that Miller could write a spec for NTFS, but he reserved the right to kill the file system before the actual coding of it began.
> Miller gathered some pens and pads, two weeks’ worth of provisions and prepared for a lengthy trip on his twenty-eight-foot sailboat. Miller felt that spec writing benefited from solitude, and the ocean offered plenty of it. [...] Rather than sail alone, Miller arranged with Perazzoli, who officially took care of the file team, to fly in a programmer Miller knew well. He lived in Switzerland.
> In August, Miller and his sidekick set sail for two weeks. The routine was easy: Work in the morning, talking and scratching out notes on a pad, then sail somewhere, then talk and scratch out more notes, then anchor by evening and relax.
(I’m still relatively confident that the Win32 spec was written in 1990; at the very least, Showstopper! mentions it being shown to a group of app writers on December 17 of that year.)
I had game partition mounted as subpath on a drive and it just not worked well with some apps.
Some apps (in this case Steam) don't run "what is is space in current path" (despise say GetDiskFreeSpaceExW accepting full path just fine), they cut it to the drive letter, which causes them to display space of the root drive, not the actual directory that they are using and in my case was mounted as different partition
In the 80s, running DOS 3.1 on an IBM Network, I was networking dual floppy PCs, and with testing, got through drive '!' '@' '#' '^' So I was able to use 26 floppies, 24 of them non local... It was all removed with the next release, 3.2, so I would make some bets about NT Networking and its NetBIOS roots.
I was inspired by the Dr Seuss, "On beyond Zebra."
It’s not baffling at all. They strongly value maintaining backwards compatibility guarantees.
For example, Windows 11 has no backwards compatibility guarantees for DOS but operating systems that they do have backwards compatibility guarantees for do.
Enterprises need Microsoft to maintain these for as long as possible.
It is AMAZING how much inertia software has that hardware doesn’t, given how difficult each are to create.
Things that go through the proper channels are usually compatible. Crysis was never the most stable of games and IIRC it used 3DNow, which is deprecated - but not by Windows.
As a counter-anecdata, last week I ran Galapagos: Mendel's Escape with zero compat patches or settings, that's a 1997 3D game just working.
> Things that go through the proper channels are usually compatible.
But that's a pretty low bar - previously Windows went to great lengths to preserve backwards compatibility even for programs that are out of spec.
If you just care about keeping things working if they were done "correctly" then the average Linux desktop can do that too - both for native Linux programs (glibc and a small list of other base system libraries have strong backwards compatibility) as well as for Windows programs via Wine.
On paper maybe. In practice there's currently at least one case that directly affects me where Wine-patched Windows software still works on Windows thanks to said patch... but doesn't work under Wine anymore.
It's baffling tha[t] after 59 years , Unix is still stuck in a weird directory naming structure inherited from the the late 60s that no longer make[s] sense when nobody has floppy drives.
> You can't access certificates in linux/bash as a file path for example, but you can in powershell/windows.
sure you can, /usr/share/ca-certificates
tho you do need to run 'update-ca-certificates' (in debian derivatives) to update some files, like hashed symlinks in /etc/ssl/certs
there is also of course /sys|/proc for system stuff, but yes, nowhere near as integrated as windows registry
ReactOS has a graphical NT OBJ browser (maybe as a CLSID) where you can just open an Explorer window and look up the whole registry hierarchy and a lot more.
After [copying over .dll and importing .reg files], you will already be able to open these shell locations with the following commands:
NT Object Namespace: explorer.exe shell:::{845b0fb2-66e0-416b-8f91-314e23f7c12d}
System Registry: explorer.exe shell:::{1c6d6e08-2332-4a7b-a94d-6432db2b5ae6}
If you want to add these folders in My Computer, just like in ReactOS, add these 2 CLSIDs to the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace
Seems ReactOS holds some goodies even for long time Windows users!
Yep. NTVDM DLL too; it will run DOS binaries and some other stuff too. Also it has proper solitaires and such which you can just reuse by extracting the EXE files from the CAB file lying in the ReactOS live CD.
You can access files that contain certificate information (on any OS), but you can't access individual certificates as their own object. In your output, you're listing files that may or may not contain valid certificate information.
The difference is similar to being able to do 'ls /usr/bin/ls' vs 'ls /proc/12345/...' , the first is a literal file listing, the second is a way to access/manipulate the ls process (supposedly pid 12345). In windows, certificates are not just files but parsed/processed/validated usage specific objects. The same applies on Linux but it is up to openssl, gnutls,etc... to make sense of that information. If openssl/gnutls had a VFS mount for their view of the certificates on the system (and GPG!!) that would be similar to cert:\ in powershell.
Linux lacks a lot of APIs other operating systems have and certificate management is one of them.
A Linux equivalent of listing certificates through the Windows virtual file system would be something like listing /proc/self/tls/certificates (which doesn't actually exist, of course, because Linux has decided that stuff like that is the user's problem to set up and not an OS API).
I _suspect_ they mean that certs imported into MMC in Windows can be accessed at magic paths, but...yeah linux can do that because it skips the step of making a magical holding area for certs.
there are magical holding areas in Linux as well, but that detail is up to TLS libraries like openssl at run-time, and hidden away from their clients. There are a myriad of ways to manage just ca certs, gnutls may not use openssl's paths, and each distro has its own idea of where the certs go. The ideal unix-y way (that windows/powershell gets) would be to mount a virtual volume for certificates where users and client apps alike can view/manipulate certificate information. If you've tried to get a internal certs working with different Linux distros/deployments you might be familiar with the headache (but a minor one I'll admit).
Not for certs specifically (that I know of) but Plan9 and it's derivaties are very hard on making everything VFS abstracted. Of course /proc , /sys and others are awesome, but there are still things that need their own FS view but are relegated to just 'files'. Like ~/.cache ~/.config and all the xdg standards. I get it, it's a standardized path and all, but what's being abstracted is here is not "data in a file" but "cache" and "configuration" (more specific), it should still be in a VFS path, but it shouldn't be a file that is exposed but an abstraction of "configuration settings" or "cache entries" backed by whatever thing you want (e.g.: redis, sqlite, s3,etc..). The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.
> The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.
In theory, this is what dbus is doing, but through APIs rather than arbitrary path-key-value triplets. You can run your secret manager of choice and as long as it responds to the DBUS API calls correctly, the calling application doesn't know who's managing the secrets for you. Same goes for sound, display config, and the Bluetooth API, although some are "branded" so they're not quite interchangeable as they might change on a whim.
Gnome's dconf system looks a lot like the Windows registry and thanks to the capability to add documentation directly to keys, it's also a lot easier to actually use if you're trying to configure a system.
This is nice! What I find hard to grapple with is, how do other concepts of the file system map to these providers, even more so to Alias, Environment, Function or Variable?
Like creating an item, deleting an item, copying an item, viewing contents and properties like permissions, size, visibility of an item?
For the Certificate provider specifically: When I think certificates and hierarchy, I think signing hierarchy of issueing certs. But this is not what is exposed here, just the structure of the OS cert store without context. and moving items has much more implications that inside a normal data folder. Thus I prefer certlm/certmgr.msc as they provide some more of it.
I've used this a few times to put games on exchangeable media. Installers don't like it if you pick an SD card as an install target, but they don't care if C:\Games\Whatever is actually an NTFS mount point that goes unpopulated as soon as I disconnect the memory card. This trick has the downside of confusing installers that try to check free space, though.
For permanently mounted drives, I'd pick symbolic links over mount points because this lets you do file system maintenance and such much easier on a per-drive level. You can still keep everything under C:\ and treat it like a weird / on Unix, but it you need to defragment your backup hard drive you won't need to beat the partition manager into submission to make the defragment button show up for your mounted path.
Don't have to use PowerShell either, it's been available for ages through Disk Management. Right-click on a partition -> Change Drive Letter and Path -> Add -> Mount in following empty NCTS folder.
NTFS mount points can be very handy for engineering around software that doesn't allow you to customize paths. I can choose VM disks with different performance or replication policies and stitch them together like I would on a *nix OS. It's very handy and only in rare occasions have I had applications "notice" it and balk.
Symlinks also work on NTFS, though mount points have the advantage of not having a canonical path that might be unintentionally resolved and persisted.
Only for NTFS (both source and dest) though, no exFAT shared drives under a folder mount or what have you. I think the same is actually true of ReFS for some reason.
When you create/format the partition in the GUI tools it'll actually ask if you want to assign a drive letter or mount as a path as well.
Many programs (Steam did, last time I checked) will look up the parent disk's free space when you do that and might refuse to install if that space is too small (even if target dir have enough)
It's even available in the regular UI, open "computer management" go to the disk section and many of the 'magic' things about drives in windows world are just UI toggles
Back when Windows 2000 was the new thing, I used to put "Program Files" on another disk with this. Starting programs became faster too, as things loaded both from the OS drive and the drive where the programs were installed.
Yeah only the DOS façade of Windows NT is well known. Under that skin lurks some pretty wild late-1980s concepts. One of the core things to understand is that a lot of the features are based on a reverse map of GUIDs to various actions, and resolution of these map entries pervades the UI. That's why you can put {hexspew} as the name of a shortcut on the Windows desktop and have it magically become a deep link to some feature that Windows doesn't otherwise let you create a shortcut to, and also why you can just add things to the control panel which doesn't seem like it would be an intentional feature. And these actions can be named symbols inside DLLs, so they can do literally anything the OS is capable of doing. This is also why Windows has always been ground zero for malware.
>so they can do literally anything the OS is capable of doing
Yea, over the years someone thought of something they wanted to do and then did it without a systematic consideration of what that level of power meant, especially as multi-user network connectivity and untrusted data became the norm.
As far as I can tell, the drive will still be accessible, it'll just require the character equivalent to € on the other code page as a drive letter.
As long as your code page doesn't have gaps, that should be doable. It'll definitely confuse the hell out of anyone who doesn't know about this setup, though!
I don't think it works that way, the actual drive letter is a UTF-16 Unicode path. The application must be able to provide an "ANSI" string that encodes to that UTF-16 value if it uses an "ANSI" function to open the file. It's not like 8-bit systems where they just want the same 8-bit value.
You would be limited to a fairly small subset of emojis, anyway: many (most?) of them are outside of the BMP so don’t fit into a single UTF-16 code unit, and some of the remaining ones are ordinary characters followed by an emoji style selector (U+FE0F), which doesn’t fit either.
With the right code pages, you should be able to find a few smiley faces.
For everything else, the best advice I can offer is that you can put your own autorun config file on the root of a drive to point the drive icon to a different resource. Though the path will stay boring, the GUI will show emoji everywhere, especially if you also enter emoji in the drive label.
> In other words, since RtlDosPathNameToNtPathName_U converts C:\foo to \??\C:\foo, then an object named C: will behave like a drive letter. To give an example of what I mean by that: in an alternate universe, RtlDosPathNameToNtPathName_U could convert the path FOO:\bar to \??\FOO:\bar and then FOO: could behave like a drive letter.
For some reason I remember that the original xbox 360 had "drive letters" which were entire strings. Unfortunately I no longer have access to the developer docs and now I wonder if my mind completely made this up. I think it was something like "Game:\foo" and "Hdd0:\foo".
> Drives with a drive-letter other than A-Z do not appear in File Explorer, and cannot be navigated to in File Explorer.
Reminds me of the old-school ALT + 255 trick on Win9x machines where adding this "illegal trailing character" made the directory inaccessible from the regular file explorer.
Up until recently, you could do the same thing in the Windows Registry to make it so normal Windows tools (e.g. Regedit) couldn't view/modify certain entries. I believe it was still an issue in the last five~ years.
For anyone curious there is a somewhat similar thing in Linux called Abstract Domain Sockets. These are Unix domain sockets where the first character is NUL ('\0')
I am working on a game where every player has system resources on a Linux computer. The basic idea is that some resources need to be shared or protected in some ways, such as files, but the core communication of the game client itself needs to be preserved without getting in the way of the real system environment.
I am using these abstract data sockets because they sidestep most other permissions in Linux. If you have the magic numbers to find the socket, you get access.
This all sounds like a wonderful way to write some truly annoying malware. I expect to see hidden mounts on SQL-escape-type-maliciously-named drives soon...
I understand your point; but I'm struggling to see how this could be weaponized. Keep in mind, that these Dos compatible drive letters need to map to a real NT path endpoint (e.g. a drive/volume); so it isn't clear how the malware could both have a difficult to scan Dos tree while also not exposing that same area elsewhere for trivial scanning.
Not sure if it is natively supported, but the malware can just decrypt a disk image to RAM and create a RAM disk mounted to +. Or it can maybe have a user space driver for a loop device, so the sectors of the drive are only decrypted on the fly.
It would likely break a lot of analysis tools and just generally make things very difficult.
They're still actively used to apply the Mark of the Web to indicate a file has been downloaded from an untrusted zone and should be handled with caution. I believe macOS also applies similar metadata.
There are a few other places where they also show up, but the MotW is the most prevalent one I've found. Most antivirus programs will warn you for unusual alternate data streams regardless of what they contain.
> drive letters are essentially just a convention borne out of the conversion of a Win32 path into a NT path
CMD also has the concept of a current drive, and of a per-drive current directory. (While “X:\” references the root directory of drive X, “X:” references whatever the current directory of drive X is. And the current directory, i.e. “.”, is the current directory of the current drive.) I wonder how those mesh with non-standard drive letters.
They work just fine, as the drive-specific CWD is stored in the environment as a normally-hidden =<drive-letter>: environment variable which has all the same WTF-16 and case-insensitive properties as drive letters:
C:\> cd /D λ:\
λ:\> cd bar
λ:\bar> cd /D C:\
C:\> echo %=Λ:%
λ:\bar
C:\> cd /D Λ:
λ:\bar>
That would only interact with the shell, as `%` is not actually part of the environment variable name, it's just a way to tell the shell you want it to get the value of an environment variable. The environment block itself is a NULL terminated list of NULL terminated WTF-16 strings of the format <key>=<value>, so `=` would be the more interesting thing to try.
And indeed, it looks like using `=` as a drive letter breaks things in an interesting way:
=:\> cd bar
Not enough memory resources are available to process this command.
=:\bar>
`cd` exits with error code 1, but the directory change still goes through.
With a program that dumps the NULL terminated <key>=<value> lines of the environment block, it looks like it does still modify the environment, but in an unexpected way:
Before `cd /D =:\`, I had a line that looked like this (i.e. the per-drive CWD for C:\ was C:\foo):
=C:=C:\foo
After `cd /D =:\`, that was unexpectedly modified to:
=C:==:\
Funnily enough, that line means that the "working directory" of the C drive is `=:\`, and that actually is acted upon:
=:\foo> cd /D C:
=:\>
---
You might also be interested to know that '= in the name of an environment variable' is a more general edge case that is handled inconsistently on more than just Windows: https://github.com/ziglang/zig/issues/23331
Anybody who's had to look through files on multi-disc arrays knows exactly how weird the drive letters can get. Mount the ISOs of thirty six 8.5GB DVDs because someone thought it was a good idea to split zip a single archive into 7.99GB segments and things get very tricky in cmd. If you weren't in the habit of using several layers of quotation marks to separate everything you'll form it very quickly because the operators can be the same symbols as the drive letters, as shown in the article with the "+" example.
In the Cygnal fork of the cygwin.dll, I hacked Cygwin's POSIX chdir() function, as well as the path resolution mechanism, to support the per-drive-letter name current directory concept.
A path like "f:myfile.txt" actually means f:\path\to\whatever\myfile.txt" where \path\to\whatever is the current working directory of the f drive.
This is one of the details which makes the replacement DLL more of a "native" run-time library, whose behavior is less surprising to Windows users of the applicaton based on it.
I don't know what it scans in the background by default, but it can custom scan mounted volumes with no visible mount points assigned at all, e.g., my EFI partition containing a copy of the EICAR test file[1]:
> The \?? part of the \??\C:\foo path is actually a special virtual folder within the Object Manager that combines the \GLOBAL?? folder and a per-user DosDevices folder together.
Oh, so that is how terminal servers are able to mount different network shares (e.g. the user's home directory always being H:\) for each user's session on the same drive letter.
I remember when A and B were commonly used drive letters. C was a luxury. D was outright bourgeois.
But for some reason, drive letters starting with C feel completely natural, too. Maybe it's because C is also the first note in the most widely known musical scale. We can totally afford to waste two drive letters at the start, right?
> I remember when A and B were commonly used drive letters. C was a luxury. D was outright bourgeois.
Our first home computer (1989 or 1990?) was a 386SX with a 40MB hard disk (so maybe we were bourgeois). My dad had to partition it into a 32MB C drive and an 8MB D drive, because the DOS version (3.3?) had a 32MB maximum filesystem size. It had two separate 5.25 inch floppy drives, a 1.2MB and a 360KB - although the 1.2MB drives could read 360KB disks, they couldn’t write them in a form readable by 360KB drives, or something like that. And later (circa 1991) we got a 3.5 inch floppy drive too, which became drive A, the 1.2MB became drive B, and the 360KB was relegated to drive E. The FDC that came with the computer (back then they were ISA cards, hadn’t been integrated with the motherboard yet) only supported two drives, so he had to buy a new one that supported four.
On systems with a single floppy, drives A: and B: were two logical drives mapped to the same physical drive. This enabled you to (tediously) copy files from one diskette to another.
While original IBM PCs indeed may not have had HDDs, it did become a standard for PC XT, as early as 1983. Only the cheapest version were without a HDD by the end of the 1980s.
My first PC, bought in late 1986, was a Leading Edge Model D, with two 360K floppy drives and no hard drive. I wrote a script to put COMMAND.COM and some other key files on a RAM disk on boot so I didn't have to keep the DOS floppy in the A: drive all the time. IIRC they had come out with a model that had a 20 MB hard drive but it was more than I could afford.
MIT, where I was at school then, had some IBM PC XTs with 10 MB hard drives, but most of their computer resources were time-sharing DEC VAX machines. You could go to one of several computer labs to get on a terminal, or even dial into them--I did the latter from my PC (the one above) using a 2400 baud modem, which was fast for the time.
Reminds me of a silly thing that happened when I was a freshman in high school, ca. 1992.
We had a dumb "computer literacy" class taught in an computer lab full of PS/2 Model 25s with no hard drives, and were each issued a bootable floppy disk containing both Microsoft Works and our assignment files (word processing documents, spreadsheets, etc.), which we turned in at the end of class for grading.
We started Works in the usual way, by typing "works" at the MS-DOS prompt.
One day, out of boredom, I added "PROMPT Password:" to AUTOEXEC.BAT on my disk, changing the DOS prompt from "A:\>" to "Password:" when booted from my disk.
Two days later, I got called into the dean's office, where the instructor demanded to know how I used my disk to "hack the network" — a network that, up until this point, I didn't even know existed, as the lab computers weren't connected to anything but power — and "lock me out of my computer", and threatened suspension unless and until I revealed the password.
After a few minutes trying to explain that no password existed to a "computer literacy" instructor who clearly had no idea what either AUTOEXEC.BAT or the DOS prompt was, nor why booting a networked computer from a potentially untrustworthy floppy disk was a terrible idea, I finally gave in.
It's just whatever happens to end up there? That's why D was typically the CD-ROM: A was the first floppy drive, B the (typically absent) second floppy drive, C the only hard disk, and then D was the next free letter.
On my laptop, D is the SD card slot. On my desktop, it's the 2nd SSD.
When recordable CDs were brand new, we set up a station at work with two hard drives (C: and D:) and the CD burner (E:). Naturally, the CDR burning software was hard-coded for D: but didn't mention that anywhere (including the error message). Took us a few hours to figure it out.
We used to set our machines so the CD-ROM was always drive L. This way we always had 'room' to add HDs so there was no gap in the alphabetical sequence. Drive D - data drive, E - swapfile, etc.
Test and external drives (being temporary) were assigned letters further down than L. Sticking reasonably rigidly to this nomenclature avoided stuff-up such as cloning an empty drive onto one with data on it (cloning was a frequent activity).
Incidentally, this rule applied to all machines, a laptop with HD would have C drive and L as the CD-ROM. Machines with multiple CD-ROMs would be assigned L, M and so on.
I always used J: (I didn’t expect to need to add that many hard drives).
I mainly did it so that CD installs wouldn’t lose their install drive since even Windows tracked it by the absolute path. Not as important with everything installed by download and Windows copying the install media to the hard drive anyway.
Between CD/DVD drives, writers, Zip Drives, and extra hard drives, it wasn't unusual for a workstation to naturally end up with G: or H:, before mapped network storage became common.
> A was the first floppy drive, B the (typically absent) second floppy drive
As another commenter mentioned, when you didn't have a second floppy drive, A: and B: mapped to two floppy disks in the same floppy drive, with DOS pausing and asking you to insert the other floppy disk when necessary. Which explains why, even on single-floppy computers, the hard disk was at C: and not B: (and since so much software ended up expecting it, the convention continued even on computers without any floppy disk drive).
On servers, D is commonly used to push data / vendor installations / other stuff you may want to backup separate from the OS off of the main OS drive C.
Depends on your setup. These days, I have a D drive for sharing data with the Linux install I never use. I used to have a D drive for user data (to keep them safe when reinstalling Windows) back in the 9x/XP days (and my CD drive was E).
I also use the drive letter assignment feature, so my external USB drive is always drive X.
D usually refers to the second internal storage device these days. Either a second SSD, a large HDD, or an extra partition in your system disk. If you don't have any of those, a USB stick might get the D drive temporarily.
Not while it's mounted. This is akin to complaining that on Linux if you unplug a flash drive and plug in a different one that second drive could "steal" /mnt/sdb1 or whatever.
Which can be trivially mapped to directories for aliasing. Just like Linux.
Windows NT and UNIX are much more similar than many people realize; Windows NT just has a giant pile of Dos/Win9x compatibility baked on top hiding how great the core kernel design actually is.
In the end, if you think about it, the Win32 subsystem running on top of NT OSes it's pretty much the same concept as Wine running on Unix. That's why Wine is not an emulator. And neither is XP emulating old Win32 stuff to run Win9x binaries.
> Only if you have an old-style kernel cmdline or fstab that references /dev/sd* instead of using the UUID=xyz or /dev/disk/by-id/xyz syntax.
Fixed that for you. It used to be normal to use the device path (/dev/hd* or /dev/sd*) to reference the filesystem partitions. Using the UUID or the by-id symlink instead is a novelty, introduced precisely to fix these device enumeration order issues.
> [ .. ] Inserting an USB drive before boot breaks booting.
Only if the machine's BIOS is configured to give bootable USB devices boot-order priority. So it's not about Linux -- in fact, the same thing would happen on a Windows machine.
Remember that in a properly configured Linux install, the boot partition is identified by UUID, not hardware identifier (in /etc/fstab). Consequently if you change a drive's hardware connection point, the system still boots.
I remember vividly when a user couldn't access his smb drive from Windows because both his printer and also the computer's case came with one of these multi-cardreaders with n slots and the drive letters collided. That's when I learned that smb drive letters don't even come from the "global" pool of drive letters, because, and this is obvious in hindsight, they are a per-user affair (credentials and all that).
Even Microsoft appears to agree with you, given that drive letters are symlinks. It's basically legacy, there's just no plan or reasonable path forward that will remove them.
I always tried to point people to DFS w/ the FQDN path. We added a shortcut to the user's desktop that pointed to their home folder on the DFS namespace.
You can fix the drive letter assignments at any time if they become a problem, or use a directory as a mount point if that's less troublesome. (Win-R, diskmgmt.msc)
If you go with the defaults, they might be. But if you manually define the letter for your external drive, it will keep it forever. (I have my external drive set to X. I’m not sure if Windows would respect that assignment if I had plugged in 19 other drives, but that is never going to happen.)
You can't work anymore only if you are incurious and unable to google a simple solution - assign a different drive letter with the disk management program.
I hope this article gets archived in a computer history, so people in the future can read how today's default operating system persisted in requiring its vict..., umm, users, to honor an archaic practice long past any imaginable justification, while free alternative operating systems don't have this handicap.
I regularly have this conversation with my end-user neighbor -- I explain that he has once again written his backup archive onto his original because he plugged in his Windows USB drives in the wrong sequence. His reply is, more or less, "Are computers still that backward?" "No," I reply, "Windows is still that backward."
The good news is that Linux is more sophisticated. The bad news is that Linux users must be more sophisticated as well. But this won't always be true.
Are Linux /dev device paths (originating from Unix) really much better? They're a pretty odd feature if you think about it. "Everything is a file", except only certain things can be files and at least by convention they only appear under /dev. Plan 9 takes the everything is a file concept to its logical conclusion and is much better designed.
Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
> Are Linux /dev device paths (originating from Unix) really much better?
Not better at all, which is why Linux uses partition UUIDs to identify specific storage partitions, regardless of hardware identifiers. This isn't automatic, the user must make it happen, which explains why Linux users need to know more than Windows users (and why Linux adoption is stalled).
> Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
Yes, true, another reason to use partition UUIDs.
> Plan 9 takes the everything is a file concept to its logical conclusion and is much better designed.
It's a shame that Plan 9 didn't get traction -- too far ahead of its time I guess.
I always saw it as two different mindsets for data storage.
One vision is "medium-centric". You might want paths to always be consistently relative to a specific floppy disc regardless of what drive it's in, or a specific Seagate Barracuda no matter which SATA socket it was wired to.
Conversely it might make more sense to think about things in a "slot-centric" manner. The left hand floppy is drive A no matter what's in it. The third SATA socket is /dev/sdc regardless of how many drives you connected and in what order.
Either works as long as it's consistent. Every so often my secondary SSD swaps between /dev/nvme0 and /dev/nvme1 and it's annoying.
> One vision is "medium-centric". You might want paths to always be consistently relative to a specific floppy disc regardless of what drive it's in, or a specific Seagate Barracuda no matter which SATA socket it was wired to.
> Conversely it might make more sense to think about things in a "slot-centric" manner. The left hand floppy is drive A no matter what's in it. The third SATA socket is /dev/sdc regardless of how many drives you connected and in what order.
A third way, which I believe is what most users actually want, is a "controller-centric" view, with the caveat that most "removable media" we have nowadays has its own built-in controller. The left hand floppy is drive A no matter what's in it, the top CD-ROM drive is drive D no matter what's in it, but the removable Seagate Expansion USB drive containing all your porn is drive X no matter which USB port you plugged it in, because the controller resides together with the media in the same portable plastic enclosure. That's also the case for SCSI, SATA, or even old-school IDE HDDs; you'd have to go back to pre-IDE drives to find one where the controller is separate from the media. With tape, CD/DVD/BD, and floppy, the controller is always separate from the media.
AmigaOS supported both. Each drive and in addition each medium had it's own name. If GAMEDISK was in floppy 0, you could reference it either as DF0: or as GAMEDISK:
You could even reference media that was not loaded at the time (e.g. GAMEDISK2:) and the OS would ask you to insert it into any drive. And there were "virtual" devices (assigns) that could point to a specific directory on a specific device, like LIBRARIES:
And the sad thing is that stuff directly in `/dev` isn't neither, it's just "first come first served" order, that is more or less guaranteed to be non-deterministic BS. One is supposed to use udev /dev/disk/by-path/ subtree if one really wants "slot-centric" connections.
Windows drive letters are also linked to some partition UUIDs, which is why you can move a partition to a different drive, or move drive to a different address (change SATA/m.2 port)
You can use mountvol command to see the mount-letter/GUID mapping.
VMS expects to be run as a cluster of machines with a single drive system. How that actually happens is “hidden” from user view, and what you see are “logicals”, which can be stacked on top of each other and otherwise manipulated by a user/process without affecting the underlying file system. The results can be insane in the hands of inexperienced folks. But that is where NT came from.
All true, all good points. Some day partitions and their unique UUIDs will be the sole valid identifiers. Then end users will have to be warned not to copy entire partitions including their (no longer unique) UUID. Sounds bizarre but I've had that exact conversation.
The NT paths are how the object manager refers to things. For example the registry hive HKEY_LOCAL_MACHINE is an alias for \Registry\Machine
https://learn.microsoft.com/en-us/windows-hardware/drivers/k...
In this way, NT is similar to Unix in that many things are just files part of one global VFS layout (the object manager name space).
Paths that start with drive letters are called a "DOSPath" because they only exist for DOS compatibility. But unfortunately, even in kernel mode, different sub systems might still refer to a DOSPath.
Powershell also exposes various things as "drives", pretty sure you could create your own custom drive as well for your custom app. For example, by default there is the 'hklm:\' drive path:
https://learn.microsoft.com/en-us/powershell/scripting/sampl...
Get-PSDrive/New-PSDrive
You can't access certificates in linux/bash as a file path for example, but you can in powershell/windows.
I highly recommend getting the NtObjectManager powershell module and exploring about:
https://github.com/googleprojectzero/sandbox-attacksurface-a...
ls NtObject:\
It's baffling than after 30 years, Windows is still stuck in a weird directory naming structure inherited from the 80's that no longer make sense when nobody has floppy drives.
> Windows is still stuck in a weird directory naming structure inherited from the 80's that no longer make sense when nobody has floppy drives.
I think you could make this same statement about *nix, except it's 10 years _worse_ (1970s). I strongly prefer the fhs over whatever MS thinks it's doing, but let's not pretend that the fhs isn't a pile of cruft (/usr/bin vs /bin, /etc for config, /media vs /mnt, etc)
All of those are optional restrictions, not mandatory. On Windows, it's (practically) mandatory.
Maybe some Windows wizards could get around the mandatory restrictions, but an average Linux user can get around the optional ones.
Drive letters are just /mnt, you can get around that, even with GUI.
So why a default Windows install still uses and shows C:?
Streaming as defacto metaphor for file access goes back to tape drives. Random Access patterns make more sense with today’s media yet we’re all still fscanf-ing
Of course there are alternatives but the resource-as-stream metaphor is so ubiquitous in Unix, it’s hard to avoid.
There is more pliability in the Linux ecosystem to change some of these things.
And anyway, there has to be a naming scheme; the naming scheme is abstracted from the storage scheme.
It's not the case that your /var and /usr are different drives; though it can be in a given installation.
Unix starts at root, which is how nature intended. It does not change characteristics based on media - you can mount a floppy at root if you want.
Why get upset over /media vs /mnt? You do you, I know I do.
For example The Step CA docs encourage using /etc/step-ca/ (https://smallstep.com/docs/step-ca/certificate-authority-ser...) for configuration for their product. Normally I would agree but as I am manually installing this thing myself and not following any of the usual docs, I've gone for /srv/step-ca.
I think we get enough direction from the ... "standards" ... for Unix file system layouts that any reasonably incompetent admin can find out which one is being mildly abused today and get a job done. On Windows ... good luck. I've been a sysadmin for both platforms for roughly 30 years and Windows is even odder than Unix.
> Unix starts at root, which is how nature intended. It does not change characteristics based on media - you can mount a floppy at root if you want.
Why is the root of one of my drives `/` while the roots of my other drives are subdirectories of that first drive?
Thinking of it in terms of namespaces might help; it's not that the drive is special, it's that there's a view that starts from / and one disk filesystem happens to be dropped there and others are dropped elsewhere; with something like initramfs there aren't any drives on /, just a chunk of ram, though you usually pivot to a physical one later (many linux-based embedded systems don't because your one "drive" is an SD card that can't handle real use, so you just keep the "skeleton" in memory and drop various bits of eMMC or SD or whatever into the tree as-convenient.)
I do get it, I just don't think that the UNIX way is necessarily more natural than the Windows way.
In multiple ways, / doesn't have to be one of your drives.
Only the root of the root filesystem is /
The point is that any filesystem can be chosen as the OS’s root.
The root of all other filesystems - there could be multiple per drive - is where you tell the filesystem to be mounted, or in your automounter’s special directory, usually /run/media, where it makes a unique serial or device path.
* clarity
Because you (or your distro) configured it like that. You don’t have to do it that way.
/usr/bin vs /bin distinction is not relevant as all major distros have gone usrmerge for years now so /bin == /usr/bin (usually /bin is a symlink)
I like being able to run games from early 2000s. Being able to write software that will still run longer after you're gone used to be a thing. But here we are with linux abandoning things like 'a.out'. Microsoft doesn't have the luxury to presume that it's users can recompile software, fork it, patch it,etc.. When your software doesn't work on the latest Windows, most people blame Microsoft not the software author.
Ok, I prefer to use software which is future compatible, like ZFS, which is 128-bit.
“The file system itself is 128 bit, allowing for 256 quadrillion zettabytes of storage. All metadata is allocated dynamically, so no need exists to preallocate inodes or otherwise limit the scalability of the file system when it is first created. All the algorithms have been written with scalability in mind. Directories can have up to 248 (256 trillion) entries, and no limit exists on the number of file systems or the number of files that can be contained within a file system.”
https://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6qth/inde...
Don’t want to hit the quadrillion zettabyte limit..
Someone did some back-of-the-napkin math and calculated that to populate every byte in a 128 bit storage pool, you'd need to use enough energy to literally boil the oceans. There was a blog post on oracle.com that went into more detail, but no link into Oracle survives more than 10 years.
> Directories can have up to 248 (256 trillion) entries
It took me a minute to figure out that this was supposed to be 2^48, but even then that's ~281 trillion. What a weird time for the tera/tibi binary prefix confusion to show up, when there aren't even any units being used.
Wait are you saying Linux broke user-space? I've completely missed this and would like to know more, may I be so bold as to request a link?
> > But here we are with linux abandoning things like 'a.out'.
> I've completely missed this and would like to know more, may I be so bold as to request a link?
"A way out for a.out" https://lwn.net/Articles/888741/
"Linux 6.1 Finishes Gutting Out The Old a.out Code" https://www.phoronix.com/news/Linux-6.1-Gutting-Out-a.out (with links to two earlier articles)
Thanks!
Linux does occasionally remove stuff that seem to have no users and there is no good reason to have a.out binaries since... the late '90s ?
I was playing with some asm code and generating a.out with nasm, got stuck on why it wouldn't load..turns out linux stopped supporting it. When they say "no one uses it" they mean packages and stuff, they don't care about private code you have lying around and other use cases. With a widely deployed platform like windows, they can't assume things like that. There are certainly very valid business application that go back decades. There are literally systems that have 20+ years up time out there.
FWIW, you should be able to hack up an a.out loader pretty easily with binfmt_misc.
If someone complained to them that they still need a.out they might've reconsidered. At least that's what's happened before with old architectures.
I don’t like running games from the early 2000s outside of a sandbox of some description. If you disagree, it's because we don't have sandboxes which don't suck. Ideally, running old software in a sandbox on a modern OS should be borderline transparent — not like installing XP in a virtual machine.
While I understand the appeal of software longevity, and I think it's a noble and worthy pursuit, I also think there is an under-appreciated benefit in having unmaintained software less likely to function on modern operating systems. Especially right now, where the concept of serious personal computer security for normal consumers is arguably less than two decades old.
Inherited from the 80s? Microsoft effectively inherited drive letters via an 8086 semi-clone of CP/M called QDOS[0], it was the basis for PC-DOS and later MS-DOS. CP/M dates back to 1974.
But Gary Kildall didn't come up with the idea of drive letters in CP/M all on his own, he was likely influenced by TOPS-10[1] and CP/CMS[2], both from the late 60s.
[0] https://en.wikipedia.org/wiki/86-DOS
[1] https://en.wikipedia.org/wiki/TOPS-10
[2] https://en.wikipedia.org/wiki/CP/CMS
I don't particularly like the Windows naming structure, but it made just as much sense with later removable-media-with-fixed-drives systems (like optical drives) as it did with floppy drives. It maybe makes less sense now that storage is either fixed media or detachable drives, rather than some being removable media in fixed drives, but the period after commonn removable media is a lot shorter than the period after common floppy drives.
(And mostly, I'm talking about using drive letters rather than something like what unix does. C being the first fixed media device, may seem more arbitrary now, but it was pretty arbitrary even in the floppy era.)
There's special place in hell for the inventor of drive names. IIRC, it's something that was nicked from CP/M.
Tim Patterson certainly copied it from CP/M and may not have been aware of anything predating it, but according to Wikipedia drive letters have quite a long history: https://en.wikipedia.org/wiki/Drive_letter_assignment
Wait 'til you hear about the PDP-11 emulator of a CPU it is running on.
Yeah, try explaining “drive C:” to a kid these days, and why it isn’t A: or B: …
Of course software developers are still stuck with 80 column conventions even though we have 16x9 4K displays now… Didn’t that come from punchcards ???
Come for punchcards, stay for legibility.
80 characters per line is an odd convention in the sense that it originated from a technical limitation, but is in fact a rule of thumb perfectly familiar to any typesetting professional from long before personal computing became widespread.
Remember newspapers? Laying the text out in columns[0] is not a random quirk or result of yet another technology limitation. It is the same reason a good blog layout sets a conservative maximum width for when it is read on a landscape oriented screen.
The reason is that when each line is shorter, the entire thing becomes easier to read. Indeed, even accounting for legibility hit caused by hyphenation.
Up to a point, of course. That point may differ depending on the medium and the nature of the material: newspapers, given they deal with solid plain text and have other layout concerns, limit a line to around 50 characters; a book may go up to 80 characters. Given a program is not a relaxed fireside reading, I would place it closer to the former, but there are also factors and conventions that could bring acceptable line length up. For example, indentation and syntax highlighting, or typical identifier length (I’m looking at you, CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter), or editor capability to wrap lines nicely[1].
Finally, since the actual technical limitation is gone, it is actually not such a big deal to violate the line length rule on occasion.
[0] Relatedly, codebases roughly following the 80 character line length limitation unlock more interesting columnar layouts in editors and multiplexers.
[1] Isn’t the auto-wrap capability in today’s editors good enough that restricting line length is pointless at the authoring stage? Not really, and (arguably) especially not in case of any language that relies on indentation. Not that it could not be good enough, but considering code becomes increasingly write-only it seems unlikely we will see editors with perfect, context-sensitive, auto-wrap any time soon.
When I read text I prefer it to use the lessons
of typography and not be overly wide, lest my saccadic
motion leads my immersion and comprehension astray.
oof this looks awful on mobile, with extra line breaks
I don't know any way to force line breaks on HN without extra line breaks ... do you?
80 chars per line was invented when languages used shortened commands though. Nowadays 120 is more appropriate. Especially in Powershell. Not so much in bash where commands are short, 80 can stay alive there!
I’m very sure this is a myth. Like any good myth, it makes sense on the surface but holds zero water once you look close.
Code isn’t prose. Code doesn’t always go to the line length limit then wrap, and prose doesn’t need a new line after every sentence. (Don’t nitpick this; you know what I’m saying)
The rules about how code and prose are formatted are different, so how the human brain finds the readability of each is necessarily different.
No code readability studies specifically looking for optimal line length have been done, to my knowledge. It may turn out to be the same as prose, but I doubt it. I think it will be different depending on the language and the size of the keywords in the language and the size of the given codebase. Longer keywords and method/function names will naturally lead to longer comfortable line lengths.
Line length is more about concepts per line, or words per line, than it is characters per line.
The 80-column limit was originally a technical one only. It has remained because of backwards compatibility and tradition.
> It is the same reason a good blog layout sets a conservative maximum width for when it is read on a landscape oriented screen.
Except 99.9% of times it's becomes 50 characters with 32pt font which occupies ~25% of the horizontal space on a 43".
"Good" my ass.
The 80 char max line width convention makes no sense with modern monitor resolutions and ultrawides being very common.
> Of course software developers are still stuck with 80 column conventions
Speak for yourself, all my projects use at least 100 if not 120 column lines (soft limit only).
Trying to keep lines at a readable length is still a valid goal though, even without the original technical limitations - although the bigger win there is to keep expression short, not to just wrap them into shorter lines.
It did, but 80 columns also pretty closely matches the 50ish em/70ish character paragraph width that’s usually recommended for readability. I myself wouldn’t go much higher than 100 columns with code.
While 80 characters is obviously quite short, my experience is that longer line lengths result in much less readable code. You have to try to be concise on shorter lines, with better phrasing.
You can make harddrives to A: and B: just fine.
This will generally work with everything using the Win32 C api.
You will however run into weird issues when using .Net, with sudden invalid paths etc.
It really wouldn't be much of a conversation. Historical conventions are a thing in general. Just think of the direction of electron flow.
> even though we have 16x9 4K displays now
Pretty much no normal person uses those at 100% scaling though, so unless you're thinking of the fellas who use a TV for a monitor, that doesn't actually help so much:
- 100% scaling: 6 panels of 80 columns fit, no px go to waste
- 125% scaling: 4 panels of 80 columns fit, 64 px go to waste (8 cols)
- 150% scaling: 4 panels of 80 columns fit, no px go to waste
- 175% scaling: 3 panels of 80 columns fit, 274 px go to waste (34 cols)
- 200% scaling: 3 panels of 80 columns fit, no px go to waste
This sounds good until you need any additional side panels. Think line numbers, scrollbars, breakpoint indicators, or worse: minimaps, and a directory browser. A minimap is usually 20 cols/panel, a directory browser is usually 40 cols. Scrollbar and bp-indicator together 2 cols/panel. Line numbers, probably safe to say, no more than 6 cols/panel.
With 2 panels, this works out to an entire additional panel in overhead, so out of 3 panels only 2 remain usable. That's the fate of the 175% and 200% options. So what is the "appropriate" scaling to use?
Well PPI-wise, if you're rocking a 32" model, then 150%. If a 27" model, then 175%. And of course, given a 22"-23"-24" unit, then 200%. People of course get sold on these for the "additional screen real estate" though, so they'll instead sacrifice seeing the entire screen at once and will put on their glasses. Maybe you prefer to drop down by 25% for each of these.
All of this is to say, it's not all that unreasonable. I personally feel a bit more comfortable with a 100 col margin, but I do definitely appreciate when various files nicely keep to the 80 col mark, they're a lot nicer to work with side-by-side.
The fact that modern interactive command shells are based on virtual teletype terminals is just absurd when you think about it
Try explaining files to a kid these days
I mean its a successful commercial project because it doesnt break things, at least not that often. You can run some really old software on windows. Its kind of taken for granted, but this is just not the norm is most industries.
As for baffling, I mean, I type in things like 'grep' everyday which is a goofy word. I'm not even going to go into all the legacy stuff linux presents and how linux, like windows, tries hard not to break userland software.
Windows can still run software from the 80's, backwards compatibility has always been a selling point for Windows, so I'd call that a win.
Didn't Microsoft drop 16 bit application support in Windows 10? I remember being saddened by my exe of Jezzball I've carried from machine to machine no longer working.
Microsoft has dropped 16-bit application support via builtin emulator (NTVDM) from 64-bit builds of Windows, whether it happens to be Windows 10 or earlier version of Windows, depends on user (in my case, it was Windows Vista). However, you can still run 16-bit apps on 64-bit builds of Windows via third party emulators, such as DOSBox and NTVDMx64.
> you can still run 16-bit apps on 64-bit builds of Windows via third party emulators, such as DOSBox and NTVDMx64.
Or Wine, which is less reliable but funnier.
Do you mean winevdm? https://github.com/otya128/winevdm
Wine itself doesn't run on Windows AFAIK.
Wine ran sort-of-fineish in WSL v1 and I'm pretty sure it'll run perfectly in WSL v2 (which is just a VM).
> Wine itself doesn't run on Windows AFAIK.
It does, if you use an old enough version of windows that SUA is available :). I never managed to get fontconfig working so text overlapped its dialogue boxes and the like, but it was good enough to run what I needed.
and Linux stopped supporting 32bit x86 I think around the same time? (just i386?)
Are you talking about CPU support? I installed a 32 bit program on basic linux mint just the other day. If I really need to load up a pentium 4 I can deal with it being an older kernel.
That's exactly what I mean, I wish Linux was more like NetBSD in its architecture support. It kind of sucks that it is open source but it acts like a corporate entity that calculates profitability of things. There is one very important reason to support things in open source: Because you committed to it, and you can. If there are practical reasons such as lack of willing maintainers (I refuse to believe out of all the devs that beg to have a serious role in kernel maintenance, none are willing to support i386 - if NetBSD has people, so too Linux), totally understandable.
You'd expect Microsoft to support things because it doesn't make money for them anymore or some other calculated cost reason, but Microsoft is supporting old things few people use even when it costs them performance/secure edges.
Well for now the kernel still supports it. And the main barrier going forward is some memory mapping stuff that anyone could fix.
Though personally, while I care a lot about using old software on new hardware, my desire to use new software on old hardware only goes so far back and 32 bit mainstream CPUs are out of that range.
I think eventually 32 bit hardware and software shouldn't be supported. But there are still plenty of both. We shouldn't get rid of good hardware because it's too old, that's wasteful. 16bit had serious limits but 32 bit is still valid for many applications and environments that don't need >3GB~ ram. For example, routers shouldn't use 64bit processors unless they're handling that much load, die size matter there, that's why they use Arm mostly, and that's why Arm has thumb mode (less instruction width = smaller die size). I'm sure the tiny amounts of money and energy saved by not having that much register/instruction width adds up when talking about billions of devices.
Open source isn't where I'd expect abandonware to happen.
> We shouldn't get rid of good hardware because it's too old, that's wasteful.
Depends on how much power it's wasting, when we're looking at 20 year old desktops/laptops.
> 32 bit is still valid for many applications and environments that don't need >3GB~ ram.
Well my understanding is that if you have 1GB of RAM or less you have nothing to worry about. The major unresolved issue with 32 bit is that it needs complicated memory mapping and can't have one big mapping of all of physical memory into the kernel address space. I'm not aware of a plan to remove the entire architecture.
It's annoying for that set of systems that fit into 32 bits but not 30 bits, but any new design over a gigabyte should be fine getting a slightly different core.
> For example, routers shouldn't use 64bit processors unless they're handling that much load, die size matter there
I don't think that's right, but correct me if I missed something. A basic 64 bit core is extremely tiny and almost the same size as a 32 bit core. If you're heavy enough to run Linux, 64 bit shouldn't be a burden.
It's very impressive indeed.
Linux goal is only for code compatibility - which makes complete sense given the libre/open source origins. If the culture is one where you expect to have access to the source code for the software you depend on, why should the OS developers make the compromises needed to ensure you can still run a binary compiled decades ago?
My original VB6 apps (mostly) still run on win11
Hmm. IME VB6 is actually a particular pain point, because MDAC (a hodgepodge of Microsoft database-access thingies) does not install even on Windows 10, and a line-of-business VB6 app is very likely to need that. And of course you can’t run apps from the 1980s on Windows 11 natively, because it can no longer run 16-bit apps, whether DOS or Windows ones. (All 32-bit Windows apps are definitionally not from the 1980s, seeing as the Tom Miller’s sailboat trip that gave us Win32 only happened in 1990. And it’s not the absence of V86 mode that’s the problem—Windows NT for Alpha could run DOS apps, using a fatter NTVDM with an included emulator. It’s purely Microsoft’s lack of desire to continue supporting that use case.)
> It’s purely Microsoft’s lack of desire to continue supporting that use case.
NTVDM leverages virtual 8086 mode which is unavailable while in long mode.
NTVDM would need to be rewritten. With alternatives like DOSBox, I can see why MSFT may not have wanted to dive into that level of backwards compat.
As I’ve already said in my initial comment, this is not the whole story. (I acknowledge it is the official story, but I want to say the official story, at best, creatively omits some of the facts.)
NTVDM as it existed Windows NT (3.1 through 10) for i386 leveraged V86 mode. NTVDM on Windows NT (e.g. 4.0) for MIPS, PowerPC, and Alpha, on the other hand, already had[1] a 16-bit x86 emulator, which was merely ifdefed out of the i386 version (making the latter much leaner).
Is it fair of Microsoft to not care to resurrect that nearly decade-old code (as of Windows XP x64 when it first became relevant)? Yes. Is it also fair to say that they would not, in fact, need to write a complete emulator from scratch to preserve their commitment to backwards compatibility, because they had already done that? Also yes.
[1] https://devblogs.microsoft.com/oldnewthing/20060525-04/?p=31...
ReactOS' NTVDM DLL wll work under XP-10 and it will run some DOS games too.
Wait, what's the story of the sailboat trip? My searches are coming up empty, but it sounds like a great story.
Yeah, I was surprised by the lack of search results when I was double-checking my post too, but apparently I wasn’t surprised enough, because I was wrong. I mixed up two pieces of Showstopper!: chapter 5 mentions the Win32 spec being initially written in two weeks by Lucovsky and Wood
> Lucovsky was more fastidious than Wood, but otherwise they had much in common: tremendous concentration, the ability to produce a lot of code fast, a distaste for excessive documentation and self-confidence bordering on megalomania. Within two weeks, they wrote an eighty-page paper describing proposed NT versions of hundreds of Windows APIs.
and chapter 6 mentions the NTFS spec being initially written in two weeks by Miller and one other person on Miller’s sailboat.
> Maritz decided that Miller could write a spec for NTFS, but he reserved the right to kill the file system before the actual coding of it began.
> Miller gathered some pens and pads, two weeks’ worth of provisions and prepared for a lengthy trip on his twenty-eight-foot sailboat. Miller felt that spec writing benefited from solitude, and the ocean offered plenty of it. [...] Rather than sail alone, Miller arranged with Perazzoli, who officially took care of the file team, to fly in a programmer Miller knew well. He lived in Switzerland.
> In August, Miller and his sidekick set sail for two weeks. The routine was easy: Work in the morning, talking and scratching out notes on a pad, then sail somewhere, then talk and scratch out more notes, then anchor by evening and relax.
(I’m still relatively confident that the Win32 spec was written in 1990; at the very least, Showstopper! mentions it being shown to a group of app writers on December 17 of that year.)
I had game partition mounted as subpath on a drive and it just not worked well with some apps.
Some apps (in this case Steam) don't run "what is is space in current path" (despise say GetDiskFreeSpaceExW accepting full path just fine), they cut it to the drive letter, which causes them to display space of the root drive, not the actual directory that they are using and in my case was mounted as different partition
In the 80s, running DOS 3.1 on an IBM Network, I was networking dual floppy PCs, and with testing, got through drive '!' '@' '#' '^' So I was able to use 26 floppies, 24 of them non local... It was all removed with the next release, 3.2, so I would make some bets about NT Networking and its NetBIOS roots.
I was inspired by the Dr Seuss, "On beyond Zebra."
It’s not baffling at all. They strongly value maintaining backwards compatibility guarantees.
For example, Windows 11 has no backwards compatibility guarantees for DOS but operating systems that they do have backwards compatibility guarantees for do.
Enterprises need Microsoft to maintain these for as long as possible.
It is AMAZING how much inertia software has that hardware doesn’t, given how difficult each are to create.
They've stopped caring as much about backwards compat.
Windows 10 no longer plays the first Crysis without binary patches for instance.
Things that go through the proper channels are usually compatible. Crysis was never the most stable of games and IIRC it used 3DNow, which is deprecated - but not by Windows.
As a counter-anecdata, last week I ran Galapagos: Mendel's Escape with zero compat patches or settings, that's a 1997 3D game just working.
> Things that go through the proper channels are usually compatible.
But that's a pretty low bar - previously Windows went to great lengths to preserve backwards compatibility even for programs that are out of spec.
If you just care about keeping things working if they were done "correctly" then the average Linux desktop can do that too - both for native Linux programs (glibc and a small list of other base system libraries have strong backwards compatibility) as well as for Windows programs via Wine.
On paper maybe. In practice there's currently at least one case that directly affects me where Wine-patched Windows software still works on Windows thanks to said patch... but doesn't work under Wine anymore.
The 3.5mm audio jack is 75 years old, but electrically-compatible with a nearly 150-year-old standard.
Victorian teletypes can be hooked to a serial port with a trivial adapter, at least enough to use CP/M and most single-case OS'es.
Also, some programming languages have a setting to export code compatible with just Baudot characters: http://t3x.org/nmhbasic/index.html
So, you could feed it from paper tape and maybe Morse too.
Yeah speakers haven’t changed enough to make the 3.5mm connector obsolete.
Many new devices use a 2.5mm audio jack instead of the 3.5mm audio jack.
It's baffling tha[t] after 59 years , Unix is still stuck in a weird directory naming structure inherited from the the late 60s that no longer make[s] sense when nobody has floppy drives.
Unix pre-dates floppy drives, at least on PDP-11.
Unix just barely predates the PDP-11 itself.
PnP PowerShell also includes a PSDrive provider [0] so you can browse SharePoint Online as a drive. These aren't limited to local sources.
[0] https://pnp.github.io/powershell/cmdlets/Connect-PnPOnline.h...
> You can't access certificates in linux/bash as a file path for example
Fuse and p9 exist... If anyone wants certs by id in the filesystem, it will exist.
> You can't access certificates in linux/bash as a file path for example, but you can in powershell/windows.
sure you can, /usr/share/ca-certificates tho you do need to run 'update-ca-certificates' (in debian derivatives) to update some files, like hashed symlinks in /etc/ssl/certs
there is also of course /sys|/proc for system stuff, but yes, nowhere near as integrated as windows registry
ReactOS has a graphical NT OBJ browser (maybe as a CLSID) where you can just open an Explorer window and look up the whole registry hierarchy and a lot more.
It works under Windows too.
Proof:
https://winclassic.net/thread/1852/reactos-registry-ntobject...
Awesome!
Seems ReactOS holds some goodies even for long time Windows users!Yep. NTVDM DLL too; it will run DOS binaries and some other stuff too. Also it has proper solitaires and such which you can just reuse by extracting the EXE files from the CAB file lying in the ReactOS live CD.
> You can't access certificates in linux/bash as a file path for example, but you can in powershell/windows.
I don't understand what you mean by this. I can access them "as a file" because they are in fact just files
You can access files that contain certificate information (on any OS), but you can't access individual certificates as their own object. In your output, you're listing files that may or may not contain valid certificate information.
The difference is similar to being able to do 'ls /usr/bin/ls' vs 'ls /proc/12345/...' , the first is a literal file listing, the second is a way to access/manipulate the ls process (supposedly pid 12345). In windows, certificates are not just files but parsed/processed/validated usage specific objects. The same applies on Linux but it is up to openssl, gnutls,etc... to make sense of that information. If openssl/gnutls had a VFS mount for their view of the certificates on the system (and GPG!!) that would be similar to cert:\ in powershell.
Linux lacks a lot of APIs other operating systems have and certificate management is one of them.
A Linux equivalent of listing certificates through the Windows virtual file system would be something like listing /proc/self/tls/certificates (which doesn't actually exist, of course, because Linux has decided that stuff like that is the user's problem to set up and not an OS API).
I _suspect_ they mean that certs imported into MMC in Windows can be accessed at magic paths, but...yeah linux can do that because it skips the step of making a magical holding area for certs.
there are magical holding areas in Linux as well, but that detail is up to TLS libraries like openssl at run-time, and hidden away from their clients. There are a myriad of ways to manage just ca certs, gnutls may not use openssl's paths, and each distro has its own idea of where the certs go. The ideal unix-y way (that windows/powershell gets) would be to mount a virtual volume for certificates where users and client apps alike can view/manipulate certificate information. If you've tried to get a internal certs working with different Linux distros/deployments you might be familiar with the headache (but a minor one I'll admit).
Not for certs specifically (that I know of) but Plan9 and it's derivaties are very hard on making everything VFS abstracted. Of course /proc , /sys and others are awesome, but there are still things that need their own FS view but are relegated to just 'files'. Like ~/.cache ~/.config and all the xdg standards. I get it, it's a standardized path and all, but what's being abstracted is here is not "data in a file" but "cache" and "configuration" (more specific), it should still be in a VFS path, but it shouldn't be a file that is exposed but an abstraction of "configuration settings" or "cache entries" backed by whatever thing you want (e.g.: redis, sqlite, s3,etc..). The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.
> The windows registry (configuration manager is the real name btw) does a good job of abstracting configurations, but obviously you can't pick and choose the back-end implementation like you potentially could in Linux.
In theory, this is what dbus is doing, but through APIs rather than arbitrary path-key-value triplets. You can run your secret manager of choice and as long as it responds to the DBUS API calls correctly, the calling application doesn't know who's managing the secrets for you. Same goes for sound, display config, and the Bluetooth API, although some are "branded" so they're not quite interchangeable as they might change on a whim.
Gnome's dconf system looks a lot like the Windows registry and thanks to the capability to add documentation directly to keys, it's also a lot easier to actually use if you're trying to configure a system.
No, he meant access like virtual pseudo filesystem - /proc, /sys etc
Do note the 'ls' usage:
Now do the same without a convoluted hodge-podge of one-liner involving grep, python and cutting exact text pieces with regex.I always love how linux fans do like to talk without any experience nor the will to get the said experience.
This is nice! What I find hard to grapple with is, how do other concepts of the file system map to these providers, even more so to Alias, Environment, Function or Variable? Like creating an item, deleting an item, copying an item, viewing contents and properties like permissions, size, visibility of an item?
For the Certificate provider specifically: When I think certificates and hierarchy, I think signing hierarchy of issueing certs. But this is not what is exposed here, just the structure of the OS cert store without context. and moving items has much more implications that inside a normal data folder. Thus I prefer certlm/certmgr.msc as they provide some more of it.
Sometimes It feels as they crammed too much into that idea, a forced concept. https://superuser.com/q/1065812/what-is-psprovider-in-powers...
Windows is not limited to accessing partitions through drive letters either, it's just the existing convention.
You can mount partitions under directories just like you can in Linux/Unix.
PowerShell has Add-PartitionAccessPath for this:
> mkdir C:\Disk
> Add-PartitionAccessPath -DiskNumber 1 -PartitionNumber 2 -AccessPath "C:\Disk"
> ls C:\Disk
It will persist through reboots too.
I've used this a few times to put games on exchangeable media. Installers don't like it if you pick an SD card as an install target, but they don't care if C:\Games\Whatever is actually an NTFS mount point that goes unpopulated as soon as I disconnect the memory card. This trick has the downside of confusing installers that try to check free space, though.
For permanently mounted drives, I'd pick symbolic links over mount points because this lets you do file system maintenance and such much easier on a per-drive level. You can still keep everything under C:\ and treat it like a weird / on Unix, but it you need to defragment your backup hard drive you won't need to beat the partition manager into submission to make the defragment button show up for your mounted path.
Don't have to use PowerShell either, it's been available for ages through Disk Management. Right-click on a partition -> Change Drive Letter and Path -> Add -> Mount in following empty NCTS folder.
NTFS mount points can be very handy for engineering around software that doesn't allow you to customize paths. I can choose VM disks with different performance or replication policies and stitch them together like I would on a *nix OS. It's very handy and only in rare occasions have I had applications "notice" it and balk.
Symlinks also work on NTFS, though mount points have the advantage of not having a canonical path that might be unintentionally resolved and persisted.
Only for NTFS (both source and dest) though, no exFAT shared drives under a folder mount or what have you. I think the same is actually true of ReFS for some reason.
When you create/format the partition in the GUI tools it'll actually ask if you want to assign a drive letter or mount as a path as well.
I just tried mounting a exFAT partition at "C:\exFAT" and it worked just fine.
Other way around. Try mounting E: in your exfat drive.
That's because some filesystems like NTFS expose necessary metadata for integration and some don't. FAT and exFAT do not.
RAW partitions can be mounted at a mount point (or drive letter).
Used to be able to use these with SQL Server.... 2000.
Many programs (Steam did, last time I checked) will look up the parent disk's free space when you do that and might refuse to install if that space is too small (even if target dir have enough)
What, excuse me, the fuck? I never knew one could do this. Thanks!
It's even available in the regular UI, open "computer management" go to the disk section and many of the 'magic' things about drives in windows world are just UI toggles
Back when Windows 2000 was the new thing, I used to put "Program Files" on another disk with this. Starting programs became faster too, as things loaded both from the OS drive and the drive where the programs were installed.
The cursedness of "€:\" is awesome. It's amazing how much more flexible the NT kernel is vs what's exposed to the user.
Yeah only the DOS façade of Windows NT is well known. Under that skin lurks some pretty wild late-1980s concepts. One of the core things to understand is that a lot of the features are based on a reverse map of GUIDs to various actions, and resolution of these map entries pervades the UI. That's why you can put {hexspew} as the name of a shortcut on the Windows desktop and have it magically become a deep link to some feature that Windows doesn't otherwise let you create a shortcut to, and also why you can just add things to the control panel which doesn't seem like it would be an intentional feature. And these actions can be named symbols inside DLLs, so they can do literally anything the OS is capable of doing. This is also why Windows has always been ground zero for malware.
Those GUIDs aren't related to NT kernel but Windows Explorer and its COM-based component system. They were introduced with Windows 95, IIRC.
>so they can do literally anything the OS is capable of doing
Yea, over the years someone thought of something they wanted to do and then did it without a systematic consideration of what that level of power meant, especially as multi-user network connectivity and untrusted data became the norm.
Those weren't a consideration when the NT OS/2 Design Workbook was being written.
That sounds fun. Do you have a link or and example “hexspew”
God mode shortcut: https://en.wikipedia.org/wiki/Windows_Master_Control_Panel_s...
Very cursed, and the drive letter won't even be accessible under certain codepages.
As far as I can tell, the drive will still be accessible, it'll just require the character equivalent to € on the other code page as a drive letter.
As long as your code page doesn't have gaps, that should be doable. It'll definitely confuse the hell out of anyone who doesn't know about this setup, though!
I don't think it works that way, the actual drive letter is a UTF-16 Unicode path. The application must be able to provide an "ANSI" string that encodes to that UTF-16 value if it uses an "ANSI" function to open the file. It's not like 8-bit systems where they just want the same 8-bit value.
It's not flexible enough until we can have a joy face emoji as the drive letter.
> Drives with a drive-letter other than A-Z do not appear in File Explorer, and cannot be navigated to in File Explorer.
Well there goes my plan to replace all my drive letters with emojis :(
You would be limited to a fairly small subset of emojis, anyway: many (most?) of them are outside of the BMP so don’t fit into a single UTF-16 code unit, and some of the remaining ones are ordinary characters followed by an emoji style selector (U+FE0F), which doesn’t fit either.
Whenever I get onto a computer that someone left unlocked, the first thing I check is their eggplant- and peach-labelled drives.
With the right code pages, you should be able to find a few smiley faces.
For everything else, the best advice I can offer is that you can put your own autorun config file on the root of a drive to point the drive icon to a different resource. Though the path will stay boring, the GUI will show emoji everywhere, especially if you also enter emoji in the drive label.
But your computer name can be emoji.
> In other words, since RtlDosPathNameToNtPathName_U converts C:\foo to \??\C:\foo, then an object named C: will behave like a drive letter. To give an example of what I mean by that: in an alternate universe, RtlDosPathNameToNtPathName_U could convert the path FOO:\bar to \??\FOO:\bar and then FOO: could behave like a drive letter.
For some reason I remember that the original xbox 360 had "drive letters" which were entire strings. Unfortunately I no longer have access to the developer docs and now I wonder if my mind completely made this up. I think it was something like "Game:\foo" and "Hdd0:\foo".
Your memory is intact :) Those were/are a thing.
The Xenia emulator handles them with symbolic links in its virtual-file-system: https://github.com/xenia-canary/xenia-canary/blob/70e44ab6ec...
From the article:
> Drives with a drive-letter other than A-Z do not appear in File Explorer, and cannot be navigated to in File Explorer.
Reminds me of the old-school ALT + 255 trick on Win9x machines where adding this "illegal trailing character" made the directory inaccessible from the regular file explorer.
Shhh… that’s how we hid the Duke Nukem installs on the boxen in the dorm computer lab.
Up until recently, you could do the same thing in the Windows Registry to make it so normal Windows tools (e.g. Regedit) couldn't view/modify certain entries. I believe it was still an issue in the last five~ years.
It's even worse now https://borncity.com/win/2023/03/11/windows-10-11-mock-folde...
For anyone curious there is a somewhat similar thing in Linux called Abstract Domain Sockets. These are Unix domain sockets where the first character is NUL ('\0')
I am working on a game where every player has system resources on a Linux computer. The basic idea is that some resources need to be shared or protected in some ways, such as files, but the core communication of the game client itself needs to be preserved without getting in the way of the real system environment.
I am using these abstract data sockets because they sidestep most other permissions in Linux. If you have the magic numbers to find the socket, you get access.
> If you have the magic numbers
or find it in /proc/net/unix
Correct. Doing this allows you to implement your own method of checking credentials when a process wants to talk to that socket, such as SO_PEERCRED.
This all sounds like a wonderful way to write some truly annoying malware. I expect to see hidden mounts on SQL-escape-type-maliciously-named drives soon...
I understand your point; but I'm struggling to see how this could be weaponized. Keep in mind, that these Dos compatible drive letters need to map to a real NT path endpoint (e.g. a drive/volume); so it isn't clear how the malware could both have a difficult to scan Dos tree while also not exposing that same area elsewhere for trivial scanning.
I'm betting there's some badly written AV software out there which will crash on non-standard drive letters, allowing at least a bit of mayhem.
Not sure if it is natively supported, but the malware can just decrypt a disk image to RAM and create a RAM disk mounted to +. Or it can maybe have a user space driver for a loop device, so the sectors of the drive are only decrypted on the fly.
It would likely break a lot of analysis tools and just generally make things very difficult.
The recovery partition might work if it exists.
Wait until your learn about Alternate Data Streams…
They had their use when running Services for Macintosh.
They're still actively used to apply the Mark of the Web to indicate a file has been downloaded from an untrusted zone and should be handled with caution. I believe macOS also applies similar metadata.
There are a few other places where they also show up, but the MotW is the most prevalent one I've found. Most antivirus programs will warn you for unusual alternate data streams regardless of what they contain.
macOS uses extended attributes (can be manipulated with xattr).
ADS was originally designed to support the HFS resource fork.
Decent writeup from CS with that evasion method described -
https://www.crowdstrike.com/en-us/blog/anatomy-of-alpha-spid...
> This all sounds like a wonderful way to write some truly annoying malware.
AFAIK you need admin priviledges to play with drives in Windows.
> drive letters are essentially just a convention borne out of the conversion of a Win32 path into a NT path
CMD also has the concept of a current drive, and of a per-drive current directory. (While “X:\” references the root directory of drive X, “X:” references whatever the current directory of drive X is. And the current directory, i.e. “.”, is the current directory of the current drive.) I wonder how those mesh with non-standard drive letters.
They work just fine, as the drive-specific CWD is stored in the environment as a normally-hidden =<drive-letter>: environment variable which has all the same WTF-16 and case-insensitive properties as drive letters:
Hm, what about using `%` itself?
That would only interact with the shell, as `%` is not actually part of the environment variable name, it's just a way to tell the shell you want it to get the value of an environment variable. The environment block itself is a NULL terminated list of NULL terminated WTF-16 strings of the format <key>=<value>, so `=` would be the more interesting thing to try.
And indeed, it looks like using `=` as a drive letter breaks things in an interesting way:
`cd` exits with error code 1, but the directory change still goes through.With a program that dumps the NULL terminated <key>=<value> lines of the environment block, it looks like it does still modify the environment, but in an unexpected way:
Before `cd /D =:\`, I had a line that looked like this (i.e. the per-drive CWD for C:\ was C:\foo):
After `cd /D =:\`, that was unexpectedly modified to: Funnily enough, that line means that the "working directory" of the C drive is `=:\`, and that actually is acted upon: ---You might also be interested to know that '= in the name of an environment variable' is a more general edge case that is handled inconsistently on more than just Windows: https://github.com/ziglang/zig/issues/23331
Anybody who's had to look through files on multi-disc arrays knows exactly how weird the drive letters can get. Mount the ISOs of thirty six 8.5GB DVDs because someone thought it was a good idea to split zip a single archive into 7.99GB segments and things get very tricky in cmd. If you weren't in the habit of using several layers of quotation marks to separate everything you'll form it very quickly because the operators can be the same symbols as the drive letters, as shown in the article with the "+" example.
In my first DOS, the drive letter after Z was AA. I created a series of small RAM drives to find out.
That may have been DOS 3.3, not later. IDK when it changed.
I remember Netware had some kind of drive letter mapping that went way past z:
Hmm. This seems like it could be abused rather hilariously (or not, depending on your perspective) by malware...
If the malware that exploits my machine also runs off the eggplant emoji drive, I'm becoming Amish.
When you mount a partition on eggplant in Linux, nobody bats an eye
When you do that on windows, everybody loses their mind.
I wonder what characters are not allowed in driver letters. Is it the same set that is not allowed in file/directory names?
In the Cygnal fork of the cygwin.dll, I hacked Cygwin's POSIX chdir() function, as well as the path resolution mechanism, to support the per-drive-letter name current directory concept.
A path like "f:myfile.txt" actually means f:\path\to\whatever\myfile.txt" where \path\to\whatever is the current working directory of the f drive.
This is one of the details which makes the replacement DLL more of a "native" run-time library, whose behavior is less surprising to Windows users of the applicaton based on it.
https://www.kylheku.com/cygnal/
This is an interesting reference about how drive letters are stored in the Windows Registry: http://www.goodells.net/multiboot/partsigs.shtml
I never tried, but I wonder if you could use direct registry editing to create some really strange drive letters.
> Non-ASCII drive letters are even case-insensitive like A-Z are
I wonder, does `subst I: .` create i: or ı: under the Turkish locale?
I miss the 'assign' feature on the Amiga.
For maximum fun run Win+R eudcedit and
Draw your drive letter today!
26 drives should be enough for anyone.
This is amazing and a security flaw waiting to be exploited
The real question is can Windows defender scan these drives?
I don't know what it scans in the background by default, but it can custom scan mounted volumes with no visible mount points assigned at all, e.g., my EFI partition containing a copy of the EICAR test file[1]:
[1] https://www.eicar.org/download-anti-malware-testfile/> The \?? part of the \??\C:\foo path is actually a special virtual folder within the Object Manager that combines the \GLOBAL?? folder and a per-user DosDevices folder together.
Oh, so that is how terminal servers are able to mount different network shares (e.g. the user's home directory always being H:\) for each user's session on the same drive letter.
I remember when A and B were commonly used drive letters. C was a luxury. D was outright bourgeois.
But for some reason, drive letters starting with C feel completely natural, too. Maybe it's because C is also the first note in the most widely known musical scale. We can totally afford to waste two drive letters at the start, right?
> I remember when A and B were commonly used drive letters. C was a luxury. D was outright bourgeois.
Our first home computer (1989 or 1990?) was a 386SX with a 40MB hard disk (so maybe we were bourgeois). My dad had to partition it into a 32MB C drive and an 8MB D drive, because the DOS version (3.3?) had a 32MB maximum filesystem size. It had two separate 5.25 inch floppy drives, a 1.2MB and a 360KB - although the 1.2MB drives could read 360KB disks, they couldn’t write them in a form readable by 360KB drives, or something like that. And later (circa 1991) we got a 3.5 inch floppy drive too, which became drive A, the 1.2MB became drive B, and the 360KB was relegated to drive E. The FDC that came with the computer (back then they were ISA cards, hadn’t been integrated with the motherboard yet) only supported two drives, so he had to buy a new one that supported four.
Oh bless you and your youngsterness. A and B, by convention, were reserved for floppy drives and C was typically the first hard drive.
On systems with a single floppy, drives A: and B: were two logical drives mapped to the same physical drive. This enabled you to (tediously) copy files from one diskette to another.
I don't recall this, and I do recall running something like "diskcopy A: A:" to do that operation.
phantom drive B is explicitly mentioned in https://en.wikipedia.org/wiki/Drive_letter_assignment#Order_...
the linked source checks out. diskcopy will also do this for you if you give it source = dest.
Hard drives were a luxury.
While original IBM PCs indeed may not have had HDDs, it did become a standard for PC XT, as early as 1983. Only the cheapest version were without a HDD by the end of the 1980s.
Many clones came without a HDD.
Sure, I can imagine that.
My first contact with PCs was in 1988 and they all had HDDs and were definitely not "IBM PC" but clones. That said, that's just my experience so YMMV.
My first PC, bought in late 1986, was a Leading Edge Model D, with two 360K floppy drives and no hard drive. I wrote a script to put COMMAND.COM and some other key files on a RAM disk on boot so I didn't have to keep the DOS floppy in the A: drive all the time. IIRC they had come out with a model that had a 20 MB hard drive but it was more than I could afford.
MIT, where I was at school then, had some IBM PC XTs with 10 MB hard drives, but most of their computer resources were time-sharing DEC VAX machines. You could go to one of several computer labs to get on a terminal, or even dial into them--I did the latter from my PC (the one above) using a 2400 baud modem, which was fast for the time.
Reminds me of a silly thing that happened when I was a freshman in high school, ca. 1992.
We had a dumb "computer literacy" class taught in an computer lab full of PS/2 Model 25s with no hard drives, and were each issued a bootable floppy disk containing both Microsoft Works and our assignment files (word processing documents, spreadsheets, etc.), which we turned in at the end of class for grading.
We started Works in the usual way, by typing "works" at the MS-DOS prompt.
One day, out of boredom, I added "PROMPT Password:" to AUTOEXEC.BAT on my disk, changing the DOS prompt from "A:\>" to "Password:" when booted from my disk.
Two days later, I got called into the dean's office, where the instructor demanded to know how I used my disk to "hack the network" — a network that, up until this point, I didn't even know existed, as the lab computers weren't connected to anything but power — and "lock me out of my computer", and threatened suspension unless and until I revealed the password.
After a few minutes trying to explain that no password existed to a "computer literacy" instructor who clearly had no idea what either AUTOEXEC.BAT or the DOS prompt was, nor why booting a networked computer from a potentially untrustworthy floppy disk was a terrible idea, I finally gave in.
"Fine. The password is works. Can I go now?"
By the end of the 1980s, a lot of years had passed, and you’d buy an AT instead of an XT.
[dead]
'We have D at home' :)
c:\> subst d: c:
D was typically a CD-ROM drive. So when CD-ROMs went the way of the dinosaurs, where did D go ? Is it always some kind of SYS drive nowadays ?
It's just whatever happens to end up there? That's why D was typically the CD-ROM: A was the first floppy drive, B the (typically absent) second floppy drive, C the only hard disk, and then D was the next free letter.
On my laptop, D is the SD card slot. On my desktop, it's the 2nd SSD.
When recordable CDs were brand new, we set up a station at work with two hard drives (C: and D:) and the CD burner (E:). Naturally, the CDR burning software was hard-coded for D: but didn't mention that anywhere (including the error message). Took us a few hours to figure it out.
"That's why D was typically the CD-ROM:"
We used to set our machines so the CD-ROM was always drive L. This way we always had 'room' to add HDs so there was no gap in the alphabetical sequence. Drive D - data drive, E - swapfile, etc.
Test and external drives (being temporary) were assigned letters further down than L. Sticking reasonably rigidly to this nomenclature avoided stuff-up such as cloning an empty drive onto one with data on it (cloning was a frequent activity).
Incidentally, this rule applied to all machines, a laptop with HD would have C drive and L as the CD-ROM. Machines with multiple CD-ROMs would be assigned L, M and so on.
I always used J: (I didn’t expect to need to add that many hard drives).
I mainly did it so that CD installs wouldn’t lose their install drive since even Windows tracked it by the absolute path. Not as important with everything installed by download and Windows copying the install media to the hard drive anyway.
Right, can't exactly remember why L was selected. I think we were thinking worst case scenario then adding some for good measure. :-)
After C:, it really is just allocated in order.
Between CD/DVD drives, writers, Zip Drives, and extra hard drives, it wasn't unusual for a workstation to naturally end up with G: or H:, before mapped network storage became common.
> A was the first floppy drive, B the (typically absent) second floppy drive
As another commenter mentioned, when you didn't have a second floppy drive, A: and B: mapped to two floppy disks in the same floppy drive, with DOS pausing and asking you to insert the other floppy disk when necessary. Which explains why, even on single-floppy computers, the hard disk was at C: and not B: (and since so much software ended up expecting it, the convention continued even on computers without any floppy disk drive).
C: is the boot partition with the DoubleSpace driver, D: is the compressed volume.
Stacker compressed volume ;)
DriveSpace, surely
On servers, D is commonly used to push data / vendor installations / other stuff you may want to backup separate from the OS off of the main OS drive C.
Depends on your setup. These days, I have a D drive for sharing data with the Linux install I never use. I used to have a D drive for user data (to keep them safe when reinstalling Windows) back in the 9x/XP days (and my CD drive was E).
I also use the drive letter assignment feature, so my external USB drive is always drive X.
D usually refers to the second internal storage device these days. Either a second SSD, a large HDD, or an extra partition in your system disk. If you don't have any of those, a USB stick might get the D drive temporarily.
Similar corner cases are the bedrock of security flaws.
If anyone adds this behaviour as a bet on a market about a future CVE or severity, can they add a link to the bet here?
This topic would make a good post on The Old New Thing.
What happens if you mount 0x0000?
Deep in the abyss, the dark lord stirs
Bill Gates will get a call
This was a cool article. Learned something new today.
I never knew Λ was the upper case version of λ.
Seems like a great way to hide a bunch of files from users for a malware payload
Now somebody will uses this to hide their malware, somehow...
Windows drive letters are ridiculous. Use an external drive for e.g. video editing, its letter can be stolen by another drive, you can’t work anymore.
Not while it's mounted. This is akin to complaining that on Linux if you unplug a flash drive and plug in a different one that second drive could "steal" /mnt/sdb1 or whatever.
People did complain about that, which is why on Linux today that mount would use the disk UUID or label instead.
So it’s fixed. What’s windows’ excuse? :-)
Windows also has uuids. E.g.:
Which can be trivially mapped to directories for aliasing. Just like Linux.
Windows NT and UNIX are much more similar than many people realize; Windows NT just has a giant pile of Dos/Win9x compatibility baked on top hiding how great the core kernel design actually is.
I think this article demonstrates that very well.
Yeah, NTFS is quite capable. I mostly blame the Windows UI for being a bit too dumbed down and not advertising the capabilities well.
In the end, if you think about it, the Win32 subsystem running on top of NT OSes it's pretty much the same concept as Wine running on Unix. That's why Wine is not an emulator. And neither is XP emulating old Win32 stuff to run Win9x binaries.
Linux is broken from this point of view. Inserting an USB drive before boot breaks booting .
Only if you have a broken kernel cmdline or fstab that references /dev/sd* instead of using the UUID=xyz or /dev/disk/by-id/xyz syntax.
> Only if you have an old-style kernel cmdline or fstab that references /dev/sd* instead of using the UUID=xyz or /dev/disk/by-id/xyz syntax.
Fixed that for you. It used to be normal to use the device path (/dev/hd* or /dev/sd*) to reference the filesystem partitions. Using the UUID or the by-id symlink instead is a novelty, introduced precisely to fix these device enumeration order issues.
Yes... things were certainly broken in the distant past
> [ .. ] Inserting an USB drive before boot breaks booting.
Only if the machine's BIOS is configured to give bootable USB devices boot-order priority. So it's not about Linux -- in fact, the same thing would happen on a Windows machine.
Remember that in a properly configured Linux install, the boot partition is identified by UUID, not hardware identifier (in /etc/fstab). Consequently if you change a drive's hardware connection point, the system still boots.
Certainly doesn't for me. Skill issue.
“Works on my machine” is rarely a helpful response. Doubling down with the “skill issue” insult makes it rude in addition to being unhelpful.
Two other people were able to concisely explain the problem instead of being rude and condescending.
I remember vividly when a user couldn't access his smb drive from Windows because both his printer and also the computer's case came with one of these multi-cardreaders with n slots and the drive letters collided. That's when I learned that smb drive letters don't even come from the "global" pool of drive letters, because, and this is obvious in hindsight, they are a per-user affair (credentials and all that).
I think the concept of drive letters is flawed.
Even Microsoft appears to agree with you, given that drive letters are symlinks. It's basically legacy, there's just no plan or reasonable path forward that will remove them.
Drive letters made sense in 1981 for personal computers. Of course a network run by IT isn't personal anymore - by definition.
I always tried to point people to DFS w/ the FQDN path. We added a shortcut to the user's desktop that pointed to their home folder on the DFS namespace.
You can fix the drive letter assignments at any time if they become a problem, or use a directory as a mount point if that's less troublesome. (Win-R, diskmgmt.msc)
If you go with the defaults, they might be. But if you manually define the letter for your external drive, it will keep it forever. (I have my external drive set to X. I’m not sure if Windows would respect that assignment if I had plugged in 19 other drives, but that is never going to happen.)
Only if the actual "drive letter" assigned to the drive is the special value for "auto".
Otherwise, the drive letter is allocated statically and won't be used by another volume.
You can't work anymore only if you are incurious and unable to google a simple solution - assign a different drive letter with the disk management program.
[dead]
[dead]
I hope this article gets archived in a computer history, so people in the future can read how today's default operating system persisted in requiring its vict..., umm, users, to honor an archaic practice long past any imaginable justification, while free alternative operating systems don't have this handicap.
I regularly have this conversation with my end-user neighbor -- I explain that he has once again written his backup archive onto his original because he plugged in his Windows USB drives in the wrong sequence. His reply is, more or less, "Are computers still that backward?" "No," I reply, "Windows is still that backward."
The good news is that Linux is more sophisticated. The bad news is that Linux users must be more sophisticated as well. But this won't always be true.
Are Linux /dev device paths (originating from Unix) really much better? They're a pretty odd feature if you think about it. "Everything is a file", except only certain things can be files and at least by convention they only appear under /dev. Plan 9 takes the everything is a file concept to its logical conclusion and is much better designed.
Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
> Are Linux /dev device paths (originating from Unix) really much better?
Not better at all, which is why Linux uses partition UUIDs to identify specific storage partitions, regardless of hardware identifiers. This isn't automatic, the user must make it happen, which explains why Linux users need to know more than Windows users (and why Linux adoption is stalled).
> Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
Yes, true, another reason to use partition UUIDs.
> Plan 9 takes the everything is a file concept to its logical conclusion and is much better designed.
It's a shame that Plan 9 didn't get traction -- too far ahead of its time I guess.
I always saw it as two different mindsets for data storage.
One vision is "medium-centric". You might want paths to always be consistently relative to a specific floppy disc regardless of what drive it's in, or a specific Seagate Barracuda no matter which SATA socket it was wired to.
Conversely it might make more sense to think about things in a "slot-centric" manner. The left hand floppy is drive A no matter what's in it. The third SATA socket is /dev/sdc regardless of how many drives you connected and in what order.
Either works as long as it's consistent. Every so often my secondary SSD swaps between /dev/nvme0 and /dev/nvme1 and it's annoying.
> One vision is "medium-centric". You might want paths to always be consistently relative to a specific floppy disc regardless of what drive it's in, or a specific Seagate Barracuda no matter which SATA socket it was wired to.
> Conversely it might make more sense to think about things in a "slot-centric" manner. The left hand floppy is drive A no matter what's in it. The third SATA socket is /dev/sdc regardless of how many drives you connected and in what order.
A third way, which I believe is what most users actually want, is a "controller-centric" view, with the caveat that most "removable media" we have nowadays has its own built-in controller. The left hand floppy is drive A no matter what's in it, the top CD-ROM drive is drive D no matter what's in it, but the removable Seagate Expansion USB drive containing all your porn is drive X no matter which USB port you plugged it in, because the controller resides together with the media in the same portable plastic enclosure. That's also the case for SCSI, SATA, or even old-school IDE HDDs; you'd have to go back to pre-IDE drives to find one where the controller is separate from the media. With tape, CD/DVD/BD, and floppy, the controller is always separate from the media.
AmigaOS supported both. Each drive and in addition each medium had it's own name. If GAMEDISK was in floppy 0, you could reference it either as DF0: or as GAMEDISK:
You could even reference media that was not loaded at the time (e.g. GAMEDISK2:) and the OS would ask you to insert it into any drive. And there were "virtual" devices (assigns) that could point to a specific directory on a specific device, like LIBRARIES:
And the sad thing is that stuff directly in `/dev` isn't neither, it's just "first come first served" order, that is more or less guaranteed to be non-deterministic BS. One is supposed to use udev /dev/disk/by-path/ subtree if one really wants "slot-centric" connections.
Windows drive letters are also linked to some partition UUIDs, which is why you can move a partition to a different drive, or move drive to a different address (change SATA/m.2 port)
You can use mountvol command to see the mount-letter/GUID mapping.
This has (more or less) been covered before!
https://news.ycombinator.com/item?id=17652502
VMS expects to be run as a cluster of machines with a single drive system. How that actually happens is “hidden” from user view, and what you see are “logicals”, which can be stacked on top of each other and otherwise manipulated by a user/process without affecting the underlying file system. The results can be insane in the hands of inexperienced folks. But that is where NT came from.
All true, all good points. Some day partitions and their unique UUIDs will be the sole valid identifiers. Then end users will have to be warned not to copy entire partitions including their (no longer unique) UUID. Sounds bizarre but I've had that exact conversation.