Safename: restricting "dangerous" file names

Posted May 12, 2016 13:40 UTC (Thu) by khim (subscriber, #9252)
In reply to: Safename: restricting "dangerous" file names by farnz
Parent article: Safename: restricting "dangerous" file names

if I did B: CHDIR AWESOME then A:\SAUCE, there was no way to tell whether an access to "COM1" was intended to be a DOS 1.0-style access to the serial port, or a DOS 2.0-style access to B:\AWESOME\COM1

Really? The fact that DOS 1.0 program would use function 0F and DOS 2.0 program would use function 3D is not bin enough clue?

The fact that MS DOS 2.0 kept all these special files accessible from all places is just lazyness, plain and simple. MS DOS 2.0 could have fixed that problem easily. Now, with MS DOS 3.0 or MS DOS 5.0 it would have been problematic because at that point there were programs which used old behavior - but that's different story.

What MS DOS 2.0 did and what Windows did was clearly a mistake which haunts us to this day. That OS also made another mistake: it kept "/" as a command line switch character by default. Sure, it introduced the ability to change it but kept "/" as default we are still struggling with crazy "/" vs "\" mixup.

Now, it's easy to say that all these things were clearly a mistakes - but they kept MS-DOS usable back then and that's why we fight them now. In an alternate universe "proper" MS-DOS would have just died and we would have blamed some other OS for our miserable present.

Safename: restricting "dangerous" file names

Posted May 12, 2016 14:16 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

At least one program I used (and ported to Linux) used functions 0Fh/14h/15h for all file access - it had been written for DOS 1.0, and a small amount of DOS 2.0 functionality was added as later extensions, using function 3Bh to change directory, but still using the old (working) core to access files. It massively reduced the scope of the rework required if 0Fh still worked as the "DOS 2.0" file access function - in this particular case, it meant that the program worked on both DOS 1.0 and DOS 2.0, but the extra functionality for DOS 2.0 machines simply didn't work (the program ate the errors).

And note that internally, this program was messy (as so many in-house programs are); once DOS 2.0 was deployed company-wide, later functionality was added using function 3Dh/3Fh/40h to access files, except where it was interfacing with the old core, where it used 0Fh/14h/15h. As a result, we needed an access to a file via 3Dh/3Fh/40h to access the same thing that 0Fh/14h/15h would, because otherwise whether (e.g.) COM2 was the second serial port or a file would depend on whether you were using the old bit of the codebase or the new...

Windows maintaining this in the Win16/Win32 API, however, has no excuse.

Safename: restricting "dangerous" file names

Posted May 17, 2016 14:15 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

Windows maintaining this in the Win16/Win32 API, however, has no excuse.

I'm not exactly sure what you mean by that sentence. Have people stopping writing messy programs when Windows was introduced? Or have they stopped using old code? Win16 programs had access to the very same DOS functions in Windows 1.0/2.0, you know. And even with 3.x many INT21 functions were available.

If it made no sense to break compatibility with MS DOS 2.0 then I don't see how Windows could have made any other choice.

As a result, we needed an access to a file via 3Dh/3Fh/40h to access the same thing that 0Fh/14h/15h would, because otherwise whether (e.g.) COM2 was the second serial port or a file would depend on whether you were using the old bit of the codebase or the new...

You mean your code was so convoluted and obfuscated that it was impossible to call wrapper which would give you "compatible" interface on top of the 3Dh/3Fh/40h functions? Were you writing your programs in Malbolge?

Yes, I could easily understand why some programs needed that kludge. They could have easily added it to their own codebase. As temporary one or permanent one - but it would have been their choice. MS DOS 2.0 had no need for it, it could have easily fixed that problem with MS DOS 2.0 but it choose to be compatible. Windows suffered the same fate for the same reason.

Safename: restricting "dangerous" file names

Posted May 17, 2016 14:26 UTC (Tue) by farnz (subscriber, #17727) [Link]

I mean that when you're redoing the program to use Windows file APIs, instead of calling the DOS file APIs, you can lose the back compat behaviour - you're having to do major surgery to bring in a GUI instead of a CLI or TUI anyway, so this is just one more "port from DOS to a GUI" tax that shouldn't cost you much, relative to the huge cost of having to redo every user interface decision in the program to use Win16 calls instead of DOS calls; after all, when I rewrote the program for Linux (in C, instead of a mix of 8080 CP/M assembler that went through an automated translator to get 8086 DOS 1.0 code, hand-written 8086 machine code using DOS APIs - co-worker who thought that assemblers were likely to introduce bugs to his code - and 8086 assembler written for DOS native APIs), I had to find and change all these API calls anyway. In contrast, for a lot of apps, the move from DOS 1.0 to DOS 2.0 was supposed to just bring in directory support, nothing else.

And yes, we could have added it internally - but then we wouldn't have bothered adding in directory support (costs too much for the value provided), and would have stuck with the DOS 1.0 API until we ported to another platform. Arguably, had they done that, we'd have ported to a UNIX earlier than we did - when we looked at adding a GUI, the decision was made to move to Linux/X11 instead of Windows, because we already had X11 servers running on client machines, and we could thus run the program on controlled Linux servers instead of having users able to copy it to floppies and ruin our careful deployment strategy.