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.
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.
I don’t like running games from the early 2000s outside of a sandbox of some description.
While I understand the appeal of software longevity, I also think there is an oft-unspoken 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 only one, maybe two decades old.
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.”
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, limit a line to 40–60 characters; for programming it may be wider due to often longer “words” and other factors and conventions like syntax highlighting or indentation, and when dealing with particularly long identifiers (I’m looking at you, CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter) wider still.
[0] Relatedly, codebases roughly following the 80 character line length limitation unlock more interesting columnar layouts in editors and multiplexers.
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.
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?
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.
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.)
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.
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.
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.
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.
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.
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!
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.
> 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.
> 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".
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.
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.
> 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>
I don't know what it scans 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]:
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?
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.
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.
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.
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.
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.
> [ .. ] 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.
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.)
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'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.
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.
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:\
While I understand the appeal of software longevity, I also think there is an oft-unspoken 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 only one, maybe two decades old.
“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..
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, limit a line to 40–60 characters; for programming it may be wider due to often longer “words” and other factors and conventions like syntax highlighting or indentation, and when dealing with particularly long identifiers (I’m looking at you, CNLabelContactRelationYoungerCousinMothersSiblingsDaughterOrFathersSistersDaughter) wider still.
[0] Relatedly, codebases roughly following the 80 character line length limitation unlock more interesting columnar layouts in editors and multiplexers.
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?
[0] https://pnp.github.io/powershell/cmdlets/Connect-PnPOnline.h...
It works under Windows too.
Proof:
https://winclassic.net/thread/1852/reactos-registry-ntobject...
I don't understand what you mean by this. I can access them "as a file" because they are in fact just files
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.
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).
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.
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.
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.
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.
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.
Used to be able to use these with SQL Server.... 2000.
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 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!
Well there goes my plan to replace all my drive letters with emojis :(
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.
> 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.
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.
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".
It would likely break a lot of analysis tools and just generally make things very difficult.
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.
https://www.crowdstrike.com/en-us/blog/anatomy-of-alpha-spid...
AFAIK you need admin priviledges to play with drives in Windows.
That may have been DOS 3.3, not later. IDK when it changed.
I never tried, but I wonder if you could use direct registry editing to create some really strange drive letters.
I wonder, does `subst I: .` create i: or ı: under the Turkish locale?
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.
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?
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?
the linked source checks out. diskcopy will also do this for you if you give it source = dest.
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.
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.
On my laptop, D is the SD card slot. On my desktop, it's the 2nd SSD.
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 also use the drive letter assignment feature, so my external USB drive is always drive X.
So it’s fixed. What’s windows’ excuse? :-)
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.
Two other people were able to concisely explain the problem instead of being rude and condescending.
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 think the concept of drive letters is flawed.
Otherwise, the drive letter is allocated statically and won't be used by another volume.
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.
Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
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.
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.
You can use mountvol command to see the mount-letter/GUID mapping.
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.