Google Project Zero reverse-engineers Windows path hacks for better security If you're tearing your hair out trying to make sure your Windows 8 / 8.1 /10 application isn't attackable through the filename structure, a Google security engineer has penned a long look at the API to try and help. The reason behind the long explanation is simple, from Google's point of view: “path'ological reverse engineer” …
The path API containing the sorry mix of VMS and MSDOS semantics is still in there too.
This is one thing which Unix got right early on - mounting volumes at a filesystem point. It provides for a clean and flexible path API. Compared to that the MACHINE::VOLUME::PATH VMS and offspring convention is a complete and utter dogs breakfast.
Sure, Unix had very little to mount back then. Also, it has sillyness like case sensitive file names (for lack of proper collations, and an English-centric mindset) and horror of spaces. A file system designed for computers and not human beings.
Also, you'll never know where your devices get mounted - and you can't access a path if you don't mount if first. The UNC convention is much more useful.
Also, it has sillyness like case sensitive file names (for lack of proper collations, and an English-centric mindset) and horror of spaces
Sigh.
Case-sensitivity is the default for computers because chars map to hex values, or didn't you watch The Martian?. Case-insensitivity is slower and requires more memory. But, of course, speed and memory have never mattered, particularly not in the early days of unix.
Whitespace can be a real problem on terminals and printouts. Much better to make it explicit.
Characters doesn't map to hex values in a 1:1 relationship. Unluckily (for programmers), the human languages and their representations are a bit more complex.
It's just too many developers never learnt how to manage text properly. Unix brother, C, didn't implement a string type either believing array of bytes would have been enough. Classic programmer mistake who couldn't understand how the real world works outside the CPU.
If Unix and C developers had knowledge of other languages beyond English, would have known about synoglyph and other languages "nuisances", and would have developed a better system. Unluckily, they couldn't look beyond assembler, their noses, and their mother tongue.
The bad thing is there are still people that believe they did the right thing, while they were only too limited.
The UNC path is not applicable because here we're talking about filesystems - you know, the storage areas that aren't accessed directly before mounting them to a drive letter or relative path.
Where you thinking about networked resources instead, perhaps? That doesn't apply either - true, it's possible to seamlessly access previously shared resources, but you don't get access to all of the filesystem unless there's a root level share, or you're an administrator and administrative shares haven't been disabled.
Windows doesn't make much difference between local files and remote ones, unlike the old Unix when the nearest computer was probably several hundred miles away on connected through a telephone cable. Windows has a nice thing called network redirector that makes accessing remote resources transparent as much as local ones - because Windows was designed when distributed systems became much more common, and resources were more spread across different systems that in monolithic Unix mainframes....
Really? I am very happy for my file names and paths to be case-sensitive.
Unix/Linux also handles spaces perfectly well. No problem identifying which are FileSystems or directories either - maybe you should spend 5 minutes reading a manual - you'll find it really useful.
Look at the use of apostrophes `, ' & " in filenames and variables. Also the 'mount' or 'df' commands.
Stupid enough to want your software to run on W2K - XP - Vista (cough) - Win7 - etc rather than the latest privacy slurping version only?
And not finding your latest API is pulled from below you if MS decides to change again (how is that Silverlight project going)?
MS has a lot of stupid past decisions to support, and practically the only real argument for choosing Windows has been compatibility with the vast range of so-called legacy software, so sad though it may be, this is still important work. Of course, MS could just open-source the legacy path code so we can see for sure and save this reverse engineering trouble and uncertainty...
The name "Win32" has nothing to do with whether the OS is 32 or 64 bit. Historical reasons; what came before it was Win16, which used a segmented memory model and thus required significant changes going to the 32-bit flat model of NT. No major changes needed to go from there to 64 bit, therefore no change of name.
You still have win32k.sys, kernel32.dll, user32.dll, gdi32.dll et al. on 64 bit Windows, and they are shiny new 64 bit files despite the names (the DLLs also exist in 32 bit versions in the SysWoW64 directory for use by 32 bit applications).
That's the naming convention that really messes with me. Let's recap:
The Win16 subsystem is there to handle the "old" stuff (pre-NT). New was 32-bit. Now we have the funny named directory with "64" in its name, which exists to handle the old 32-bit stuff. The files with 32 in there name are the 64-bit version. Because THAT makes sense!
Yes. Because had they renamed it system64, a lot of badly written stuff would have ceased to work.
And unluckily, a lot of that badly written crap runs a lot of big and rich companies - which may be among Windows best customers....
I would have really liked Microsoft had decided to kill all that crappy code and its crappy developers, just it may not afford it, especially now.
Actually most *nix systems allow any character in directories or file names except '/' (the directory separator) and the NUL 0x00 used for C end-of-string.
It is the command shell like bash, etc, that treats ':' and '*' and so on as special, and also it is the shell that treats a space as a command delimiter as well, unless you quote or escape-sequence the name. E.g. this wont work
cd my directory
As it treats 'my' and 'directory' as separate inputs, but these do work:
cd "my directory"
cd my\ directory
Since they tell the command shell to treat the space as part of a single string passed to the 'cd' command. Windows has similar problems with command-line use, it is just that few people use it or write scripts for it to complain as much.
Sorry, should have been clearer. It's a reserved character in URI paths specifically. The post I was answering was blathering about how URIs contain a colon after the protocol and seemed to be comparing that to the colon after the drive letter in windows.
Never mind that : can be a drive letter...
If they start allowing colon in filenames, then Windows will get dotted with files called C:\npddf32Log\debuglog.txt like my Linux box is. It appears it's Firefox/XULRunner that does leaves these files all over the place - although, right now, 'locate' can't find any for some reason; maybe they fixed it.
You can definitely have drive IDs apart from A-Z. Just do this:
Start up CMD.exe and type in this:
subst [: C:\Users
dir [:
It works under Windows 7 and probably every MS operating system since DOS 3.1.
I recall the old Novell map command assigning drive letters above Z.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
