8 ms·
DOS APPEND
- pavlov 2y ago> “In fact it is known that DOS 2.0 could not be built on PCs at all, and was built on DEC mainframes.” Nitpick, but DEC never made a mainframe. Their products like the PDP-11 were considered minicomputers (even though the CPU was the size of a fridge) to distinguish them from IBM’s mainframes and medium sized computers.
- p_l 2y agoThe PDP-11 was minicomputer, but PDP-10s were "minis" only formally, with VAX due to reasonable size and comparable performance coining the title "supermini" IIRC.
- surgical_fire 2y agoNitpick, but as far as I remember, minicomputers are midrange computers. DEC PDP-11 would be in the same class as IBM AS/400, so while they were distinguished from mainframes, they were "medium sized computers". Assuming, of course, that those "medium sized computers" are the midrange.
- jasomill 2y agoThis gets even more confusing when you consider that IBM released a number of mainframes smaller than many of their midrange systems, including both System/370 and System/390 systems implemented as PC expansion cards (ISA, MCA, and PCI). Ultimately, within IBM at least, "mainframe" ended up just referring to any computer that implemented the System/360 architecture or its descendants. Outside IBM, I've seen the term applied to just about any multiuser system accessed primarily through a terminal interface, including x86 servers running Linux, though typically by nontechnical users.
- deleted 2y ago[deleted]
- retrac 2y agoDEC was always finnicky about naming; the PDP series originally wasn't supposed to be called a computer because computers were thought of as much bigger than the products DEC sold, and customers in the 50s and 60s might be put off by a name they associated with multi-million dollar expenses. But the PDP-10 and VAX 9000 were basically mainframes. Million dollars or more. Whole large room with three phase power. Standard building AC might suffice but that was pushing the margin. And the faster clocked VAX 9000 was water cooled! That's not a minicomputer.
- mmooss 2y ago> But the PDP-10 and VAX 9000 were basically mainframes. Million dollars or more. Whole large room with three phase power. Standard building AC might suffice but that was pushing the margin. And the faster clocked VAX 9000 was water cooled! That's not a minicomputer. Why is that not a minicomputer. From our perspective it's a massive installation; from the perspective of the time, it was not necessarily.
- varjag 2y agoMinicomputer at the time was considered a system that fits in a rack or three. Not something that requires a purpose built room with own mains, raised floor and AC.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- somat 2y agoI am not exactly sure what makes a modern mainframe(same architecture as a historical mainframe I guess) but for historical machines I consider the wide machines(like the 36-bit pdp-10) mainframes, where minicomputers were usually narrower. 16 or 18 bit machines. Really there is no good formal definition, dividing computers into three groups(mainframe, minicomputer, microcomputer) based on how much you payed for it, is as good a mechanism for figuring this out as any other.
- mepian 2y agoThe PDP-10 was a mainframe: https://en.wikipedia.org/wiki/PDP-10#cite_note-1 https://en.wikipedia.org/wiki/PDP-10#cite_note-1
- deleted 2y ago[deleted]
- Hilift 2y agoIt was probably a VAX 11/780. If you were cheap you purchased an 11/750. The 780 had a PDP-8 for a console processor. https://news.microsoft.com/features/the-engineers-engineer-computer-industry-luminaries-salute-dave-cutlers-five-decade-long-quest-for-quality/ https://news.microsoft.com/features/the-engineers-engineer-c...
- SulphurCrested 2y agoThe console processor was an LSI-11, a PDP-11 on a chip. It hung off the inside of one of the cabinet doors. It was responsible for booting the 780 and also gave VMS access to its own 8″ floppy drive, which had a habit of overheating. The 750 was later technology, IIRC MOSFET. It also lacked the 780’s “compatibility mode”, which allowed VMS to run 16 bit RSX-11 executables by implementing the PDP-11 instruction set in addition to the 32 bit VAX one, and could boot without a console processor. If you didn’t need all the users on one machine, the 750 was cheaper per user.
- SunlitCat 2y agoAnother handy dos command, originating back to DOS is SUBST. Came in pretty handy when I wanted to share a folder with Remote Desktop, but it would only let me select whole drives. Made a SUBST drive letter for that folder, worked like a charm!
- bombcar 2y agoIIRC originally SUBST was designed for that - early programs didn't understand directories but did understand drives, and so you could make a directory appear to be a drive and they'd be happy - otherwise they'd dump everything in the root of C:\ (or A:\).
- mycall 2y agoI still use SUBST with my team so we all have our source code on P:\ which can be mapped to wherever they want it to be. This helps keep Visual Studio object files and project includes pointing to the same place, especially when mistakes are made (they should be relative paths but things happen). It is run from a registry key upon bootup.
- Kwpolska 2y agoSUBST is all fine, up until the point some tool explodes when it sees that normalizePath("P:\\whatever") == "C:\\code\\whatever", and it ends up with two paths to one file, or no way to build a relative path. I’ve seen that happen with some node tooling, for example.
- tom_ 2y agoI think some of the WSL stuff refuses to deal with SUBST'd drives. And if you use voidtools's Everything, it's worth spending 2 minutes setting up some excluded paths so that you don't get doubled up entries. But it seems it does generally work pretty well. I've recently done work for a former employer, who it seems are still using SUBST'd drive Z:, just as they'd always done when I worked there nearly 20 years ago. (Main reason: we'd found it worked well at the place we'd all worked at previously...) The idea of everybody having the same paths for things never sat right with me, because it's an easy way for absolute paths to sneak in, which can be (and occasionally was) a problem when trying to support multiple branches later in the project lifecycle. But if you've got a CI system, which people typically do in 2024, that's much less of an issue (because you can arrange for the CI system to build from a random path each time). And it is pretty handy when you can paste universally-usable paths into the chat.
- miohtama 2y agoI remember wondering APPEND as a kid three decades ago. Looks like it had a very specific legacy use case, which was no longer present in more modern DOS versions. Live and learn.
- pram 2y agoIs INT 2fH the DOS equivalent of PATH? What a bizarre mechanism, I've read it 2 times and I have no idea what it's saying lol: http://vitaly_filatov.tripod.com/ng/asm/asm_011.16.html http://vitaly_filatov.tripod.com/ng/asm/asm_011.16.html
- epcoa 2y agoIt's just an ugly ass syscall extension mechanism (so it has no direct equivalent in Linux lets say), it definitely looks bizarre in modern times. Int 2F is initially handled by DOS as a stub, but additional programs (like drivers and TSRs) can override INT 2F, put their bucket of functionality and then fallback to whatever the previous installed handler was (called chaining) for whatever they don't handle. This gives a glimpse into how much various crap could end up installed as an Int 2F handler: https://www.minuszerodegrees.net/websitecopies/Linux.old/docs/interrupts/int-html/int-2f-1.htm https://www.minuszerodegrees.net/websitecopies/Linux.old/doc... It was often used for feature/presence checks and usually nothing time critical as that chaining setup was most definitely not timing friendly.
- skissane 2y ago> This gives a glimpse into how much various crap could end up installed as an Int 2F handler: Lot's of crap in INT 21 too: https://fd.lod.bz/rbil/zint/index_21.html https://fd.lod.bz/rbil/zint/index_21.html (on the whole I like this HTMLified version of Ralf Brown's Interrupt List better) But I suppose they invented INT 2F to discourage people from doing that to INT 21. And then Ralf Brown also proposed an alternative multiplex interrupt, INT 2D: https://fd.lod.bz/rbil/interrup/tsr/2d.html#4258 https://fd.lod.bz/rbil/interrup/tsr/2d.html#4258
- astrobe_ 2y agoINT 21 was for DOS what INT 80 was for Linux: the gateway to the OS kernel. Overriding software interrupt handlers was a common mechanism, applied to BIOS interrupts as well (e.g. there was a BIOS timer interrupt that was there just for that). The idea was that programs would take over the interrupt vector then chain-call the previous handlers. One can still see something similar at play in certain scenarios with e.g. callbacks. The system/library doesn't have to maintain a list of clients.
- TeMPOraL 2y ago> APPEND is one of the things that are completely irrelevant 99.99% of the time… yet can be extremely useful when the need arises. Is it really that irrelevant? I mean, if you look past the specifics (directories, interrupts, DOS versions), this seems to be implementing the idea of bringing something into scope, in particular bringing it into scope from the outside, to modify the behavior of the consumer (here, assembler) without modifying the consumer itself. Today, we'd do the equivalent with `ln -sr ../../inc ../inc`. I'd argue the general idea remains very important and useful today, though it's definitely not obvious looking back from the future what this was what APPEND was going for.
- theamk 2y agoYes, general idea is still very important and useful, but this is post about specific command called "APPEND" in MS-DOS environment. Also, it's not an equivalent of "ln -sr" as "ln" replaces targets and not stacks them. The proper modern equivalents are environment variables like LD_LIBRARY_PATH, PYTHONPATH, PKG_CONFIG_PATH, etc... and overlayfs mounts for a generic case. But back to the APPEND: in all my time working with MS-DOS, I don't remember ever needing that, so it was 100% irrelevant to me. But this could be because I've worked with more "modern" programs (like Turb Pascal 5) which had good support for directories.
- deleted 2y ago[deleted]
- anyfoo 2y agoAlways a joy when os2museum updates. I, too, remember the trifecta of APPEND, JOIN, and SUBST. And while I always thought they were interesting, I was also wondering for most of them when I would ever use that. At the time, DOS versions and hence applications for it that don’t know subdirectories didn’t cross my mind, as my first DOS version was 2.11, I think.
- Joe_Cool 2y agoWhen I got my fancy 1.6 GB harddisk I used `subst R: .\cd` to run my games needing the CD in the drive from a directory on the harddrive instead. Boy did load times improve a ton.
- pavlov 2y agoCD-ROMs were extremely slow from a modern point of view. The original 1x speed was 150 KB/s, or 1.2 Mbps. That’s like trying to stream over a 3G mobile network with substantial packet loss, except it’s physically inside your computer.
- bluedino 2y agoPlus 400-500ms seek times and a driver that might suck up all your precious CPU when reading data
- mikaraento 2y agoSUBST was commonly used for source code directories. It served at least two purposes: making source appear at the same location on all machines and working around path length limits. I've also used SUBST when reorganizing network drive mappings.
- wruza 2y agoMy favorite program in DOS was smartdrv.exe. I know it’s much more late addition, but it was a game-changer for these slow hard drives. Even a tiny cache size (I believe I tried kilobytes range) sped up things like 10-20x. Even windows 3.x and 95 (surpisingly) ran faster with smartdrv preloaded. 95’s default cache for some reason was worse than smartdrv and literally produced harder sounds on my hdds. The second favorite was a TSR NG viewer, can’t remember the name.
- skissane 2y ago> The second favorite was a TSR NG viewer, can’t remember the name. I know what a TSR is, but what's an "NG viewer"?
- wruza 2y agoNorton Guides, iirc. E.g. Ralf Brown Interrupt List was available in it. Reading the docs without leaving an editor made programming much easier.
- anyfoo 2y agoI sometimes wistfully look back to the days where I had a bunch of books and printouts open on my desk for programming. Of course, that's more than likely romanticizing things quite a lot...
- kelnos 2y agoI remember in middle school I had the giant Visual Basic 3 book, and it was... amazing, but looking back, super annoying to deal with, always having to lug it around, dig through the table of contents and index to find what I was looking for, etc. So much easier now to just type a query into a search engine.
- anyfoo 2y ago> and 95 (surpisingly) ran faster with smartdrv preloaded. 95’s default cache for some reason was worse than smartdrv My (weak) guess is that you "32 bit disk access" and "32 bit file access" wasn't active then, i.e. Windows 95 did not use its native 32 bit disk drivers, but 16 bit BIOS access. I have a hard time seeing how Smartdrv could have done anything otherwise, unless it really had some tight integration with 32 bit Windows (which would be very surprising, it's a 16 bit TSR first and foremost). But yeah, overall, I agree, it's surprising what even a tiny cache does. If you just manage to eliminate the seek times to the root directory for pretty much every single access to a new file, that can probably do a lot already. Especially in the days before "native command queuing", where the HD would try to reorder disk accesses to find a better (physical!) head seek path across the platter. Later HDs had some cache on board.
- NotYourLawyer 2y agoHuh. I knew this command existed but never looked into it. I assumed it was like cat, just appending files together.
- troad 2y agoThis is really neat! Are there any good books on DOS that a person who enjoys articles like this may also enjoy? And more broadly, does anyone have any good books to suggest about the personal computers of the 80s and 90s, that don't skimp on the messy technical details?
- fredoralive 2y ago“Undocumented DOS” goes very deep into the technical details, if you want to know what’s going on behind the curtain.
- troad 2y agoThank you!