[HN Gopher] Why DOS was (and is) a thing (2020) [video]
___________________________________________________________________
Why DOS was (and is) a thing (2020) [video]
Author : zdw
Score : 70 points
Date : 2021-09-11 17:55 UTC (2 days ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| prewett wrote:
| The only reason I can think of to still be using DOS is that you
| can do hard real-time processing with it. Although that seems
| fairly niche, and there are other options for that.
| AnotherGoodName wrote:
| DOS on 386ex is still used on old style taxi meters and eftpos
| terminals that are still being made today. The near real-time
| support means that even the cheapest processor can read things
| like the pulses from the odometer without any misses, the
| version of DOS used is kilobytes in size so the components
| needed cost next to nothing and it boots up instantly (partly
| because the bios for the 386ex jumps straight into DOS without
| the memory and drive checks that a full blown x86 bios has).
|
| Sure you can also get a different embedded solution but you're
| going to be writing bare metal. DOS is a nice step up for these
| very low level use cases and very easy to develop for.
| marcodiego wrote:
| One thing I like about DOS is that it is an useful OS and
| bootloader. In the win9x days it allowed me to use the computer
| even when windows broke. I see no replacement for it in the free
| world, freedos has no support to linux file systems and it is
| becoming increasingly hard to run it on modern hardware. I really
| would like a modern replacement for it.
| hnlmorg wrote:
| There's plenty of live CD / USB OS's out there (albeit most
| being based on Linux). I've found they've more than covered my
| DOS use case of "I need to boot something in order to examine
| this busted computer".
| AshamedCaptain wrote:
| what about the bog-standard efi shell that comes in the
| firmware with practically every PC these days?
|
| it even resembles DOS (much more than it does any other os, at
| least)
| mixmastamyk wrote:
| The Linux console has more functionality than DOS ever did,
| sans GUI.
| guerrilla wrote:
| > I see no replacement for it in the free world
|
| I know what you mean, but what about GRUB and UEFI? I think
| both of those could be supplemented to be able to do a lot of
| the same things, don't you think?
| marcodiego wrote:
| Grub is great but has no write access and doesn't allows me
| run eg. run a full compiler.
| AshamedCaptain wrote:
| Well, the UEFI shell does.
| Koshkin wrote:
| > _bootloader_
|
| https://en.wikipedia.org/wiki/Loadlin
|
| (I love the idea of a bootloader I could play Doom on!)
| leeter wrote:
| I'll do you one better, DOOM without an OS at all (sort of)
| https://github.com/Cacodemon345/uefidoom
| hdjjhhvvhga wrote:
| In another video[0], the author demonstrates writing programs for
| FreeDOS using conio.h. I believe it would be more useful to use
| PDCurses instead - just in case your program turns out more
| popular than you had anticipated.
|
| [0] https://www.youtube.com/watch?v=OGeLIWAkncQ
| 1970-01-01 wrote:
| DOS did alright. It was never meant to be anything more than a
| basic CLI OS, and when everyone pushed it beyond that primary
| role, quirks and problems would appear, just like any other
| complex program.
| Koshkin wrote:
| This doesn't sound right to me - there was plenty of GUI-based
| applications, and having DOS at the base was usually not a
| problem (as long as you have the right device drivers - a
| problem not exclusive to DOS).
| 1970-01-01 wrote:
| There really weren't device drivers in DOS. Programs would
| include drivers for running peripheral devices, and then YOU
| had to configure each one to work with DOS. This was the
| biggest problem with DOS. These programs talked directly to
| the hardware. Once TSR drivers were combined with CD-ROM and
| sound drivers, things would be very quirky during a GUI
| install. I remember Peter Norton put out some very good DOS
| books, and he wrote a few chapters about common issues with
| "Multimedia PCs".
| p_l wrote:
| I recall that Peter Norton was also considered responsible
| for why many DOS applications required pretty much error-
| for-error IBM compatibles - because he advocated for
| directly dealing with hardware and disregarding DOS APIs
| (which, admittedly, were bad)
| mattowen_uk wrote:
| The thing about DOS is that it leverages the IBM style BIOS
| heavily. Unlike Linux, it's not just a case of recompiling DOS so
| that it works on different architecture. having DOS boot natively
| on a Pi sounds attractive but isn't feasible.
|
| However, if low-energy x86 compatible SBCs (with compatible BIOS-
| a-like) ever become more than a niche thing, then having fast DOS
| booting into single purpose apps would be a nice addition to the
| space currently dominated by Linux and all those ARM boards.
|
| I can't see it happening though.
| zozbot234 wrote:
| The modern equivalent to DOS is just the UEFI shell. No reason
| why it couldn't be supported on the Pi too - AIUI, there's a
| free implementation of UEFI that can be loaded from uboot.
| rwmj wrote:
| I'm using UEFI on my Raspberry Pi 4:
| https://github.com/pftf/RPi4
|
| Works pretty well.
| hnlmorg wrote:
| DOSbox already flies on a Raspberry Pi. I think this is one of
| those instances where the technology in question (DOS) is so
| old that it makes more sense to solve it in software than it
| does in hardware.
| Koshkin wrote:
| > _is so old_
|
| Indeed - looks like the older the software, the more
| efficient it is.
| hnlmorg wrote:
| That's a fun comment people like to quote but as someone
| who's been writing software since the DOS days, I can tell
| you it's not really true.
|
| - Older software might run less efficiently on newer
| hardware because they don't support newer hardware (eg CPU
| opcodes) and thus perform the same calculations in
| software. This is most visibly true with games that are
| software rendered in DOS rather than hardware rendered.
|
| - Older software might not take advantage of smarter
| algorithms that have been discovered more recently. This is
| best observed in the modern demo scene
|
| - Older software might run faster but that might simply
| because they don't support modern requirements (eg
| cryptography, memory protection, or even error / crash
| handling). This is probably the closest to the "efficient"
| argument but I'd counter by saying the code isn't "more
| efficient", it's "less functional". Sometimes less
| functional is exactly what you want (eg why spin up
| Microsoft Word if all you want to edit is a plain text
| file) but it's still not the same as saying "more
| efficient".
| csnover wrote:
| These are all great points. Something else I would add to
| the list is that older software would often run using a
| busy loop[0]. This was 'fine' on contemporaneous CPUs
| that didn't have any low-power modes, but on a modern CPU
| it means that older software will use 100% of one CPU
| core and force it to stay running at its maximum
| frequency while doing no work at all.
|
| [0] https://en.wikipedia.org/wiki/Busy_waiting
| milesvp wrote:
| DOSbox is great for games, and other Non real-time uses. I'm
| not sure that you get the same timing precision and variance
| in DOSBox as you do with DOS on hardware. I'd be curious if
| older CNC machines have had luck replacing their aging
| hardware with newer machines running DOSbox.
|
| As to solving old hardware in software, I'm starting to see
| HDL as a solution to dealing with this. I've been watching
| the MiSTer project for a while now as a way to capture old
| hardware on a fairly large FPGA.
| hnlmorg wrote:
| Games are probably more real time than CNC machines since
| you're dealing with short feedback loops between user
| interfaces the frame buffer. It's more the esoteric drivers
| that are going to be an issue with those CNC machines.
|
| I've read on here about people running such hardware in
| DOSbox but it's not a problem I've needed to solve
| personally. However since DOSbox is an emulator (as opposed
| to FreeDOS which is a "just" an OS), I wouldn't be
| surprised if DOSbox handled those situations fine.
| userbinator wrote:
| CNC is definitely more "real time" in the sense that if
| the timing isn't right, a tool crashes into the work.
|
| In a game, all that would happen is a little glitch that
| may or may not be noticeable.
| hnlmorg wrote:
| It's been a _looooong_ time since I 've worked with CNC
| machines but doesn't the machine itself cache the
| instructions? Or is the PC the controller?
|
| If it's the latter than I see your and the GP's point
| about RT. :)
| genewitch wrote:
| The old machines wouldn't buffer that much, and newer
| cheaper machines (including every 3d printer I've used)
| still expect a stream of data in real time.
|
| Someone with an inclination could probably make a python
| controller or something but it's probably cheaper and
| safer to just buy new machines.
| Rerarom wrote:
| yeah the x86 is a DOS machine the way Lisp machines are Lisp
| machines (or something like that, I admit I cannot find a
| properly slick way to express it)
| Koshkin wrote:
| > _x86_
|
| 8086, to be specific.
| marcodiego wrote:
| On the other hand, wherever you had a compatible bios and
| processor it was easy to run DOS and CP/M on it. This made both
| systems very popular until ibm-compatible became the standard
| and apps wouldn't run on anything else.
| mattkrause wrote:
| My lab has some modern equipment (high-speed eye trackers) uses
| DOS host computers.
|
| The whole system is closer to an appliance than a general-purpose
| computer. You start the data acquisition software (literally one
| keystroke--we have it aliased to "t"), set some options with the
| keyboard, and the data is streamed out over ethernet or a DAC.
|
| The fact that nothing else is running in the background makes it
| pretty easy to keep real-time guarantees and the fact that it's
| DOS keeps people from messing with it. I have no doubt that you
| could probably get a modern Windows/nix system to run the tracker
| AND do other stuff, but I really doubt it would be worth the
| effort--it works surprisingly well.
| zozbot234 wrote:
| You'd probably reimplement this stuff on a microcontroller,
| rather. Perhaps interfacing with a general purpose system for
| configuration and data output.
| tenebrisalietum wrote:
| Wouldn't an implementation of the DOS API basically fit on
| any modern microcontroller these days?
| anthk wrote:
| You mean the X86 BIOS? No.
| tadfisher wrote:
| There is already a working PC emulator for ESP32, and the
| 86duino is a thing.
| anthk wrote:
| Unusable for near real time tasks DOS did.
| Koshkin wrote:
| How so? The 8086 emulated on ESP32 is faster than the
| real one.
| mattkrause wrote:
| The equipment I have is doing some real-time image
| processing on a 2000 Hz video stream (it extracts
| head/eye positions for vision research).
|
| I'm sure there's _some_ sort of "microcontroller" that
| can do this, but an Arduino isn't it. If they had massive
| volume, I'm sure an ASIC could do it too, but since it's
| a niche application, an COTS x86 might be near the sweet
| spot of price/hassle.
| quietbritishjim wrote:
| "Real time" does not mean fast. It just means with
| guaranteed (or at least predictable) performance.
| iamtheworstdev wrote:
| this video is almost hnsearchable on youtube because they're
| adamant that "dos" really means "does" or "do"
| mixmastamyk wrote:
| What about "DOS" ?
| mixmastamyk wrote:
| DOS was a thing because computers were so expensive in the early
| 80s. Like _incredibly expensive_ for paltry specs and performance
| that you wouldn 't even take for free today. Thousands of 1980
| dollars.
|
| In order for personal computers to be feasible they had to be
| cheap enough for people to afford, which meant they had to be
| downright primitive by today's standards. The OS as well, by
| extension. As mentioned in the video, early DOS is basically a
| boot loader, a few utilities, and a program loader written in
| assembler. That's it. Everything else is done by applications
| that have full access to the hardware. It even dumped the shell
| out of RAM while a large application ran, which is why it would
| run the floppy on exit looking for it.
|
| More substantial OSs already existed of course, Unix and VMS for
| example, but they came with million dollar price tags. Xenix was
| ported to the PC with the 286 I believe, but it wasn't cheap or
| practical for a while, and worse is better as the saying goes.
|
| The 386, Windows, and Linux weren't feasible until a decade
| later.
| WaitWaitWha wrote:
| It is fascinating to read others' comments how DOS was bad.
|
| In my opinion, it was amazing. Prior to graphical user interface,
| various DOS _were_ the only interface in non-*nix world. Beating
| it up because it was not up to 2021 standards, is like beating a
| horse because it is not as fast as a car, does not have a
| blinking turn signal, and of course the suspension is too rough.
| I was delighted moving from writing things down in paper first to
| be able to do command line in DOS. Sure, it was not Unix, but was
| getting closer.
|
| TSRs and various memory tricks demonstrates its flexibility at
| that time, despite hardware and firmware limitations. We wrote
| myriad of tiny programs, that often functioned like *nix
| programs, and became part of the users' ecosystem, albeit lost as
| soon as the user or programmer gave up.
|
| Yes, I am going to be counter argumentative. :)
| Timwi wrote:
| I feel that the video didn't answer the question in its own
| title: why is it still a thing. People are "beating a horse"
| because it is a legitimate question why something slower than a
| car with no blinking turn signal and rough suspension is still
| a thing.
| mikewarot wrote:
| Why do people still ride horses? We don't need them, yet some
| people own and care for horses. Some people still drive Model
| T Fords, and other old things.
|
| I still want a Gray Planer (a huge old obsolete machine tool)
| taking up a huge chunk of my garage, for zero practical
| reason. Though I'd settle for a benchtop shaper.
|
| A lot of programs were written back in the days of MS-DOS
| that people got used to using, and they still work. You can't
| directly run MS-DOS programs anymore. You used to be able to
| right up to Windows 7, 32bit.
|
| If you've got an old program that still does a job, you're
| used to it, why change anything?
|
| There are programs that talk to hardware that run on MS-DOS,
| those programs and hardware represent a huge investment of
| time and effort, writing the program, building the hardware,
| and especially _debugging_ the system. If you have those
| systems in production, you 're going to do every single thing
| you can just to keep them running. You are certainly _not
| going to risk any changes to a working system_ in the name of
| efficiency, especially if your business, or job, depends on
| it.
|
| In many, many cases the original people, documentation, and
| decisions that went into the design are all unavailable, and
| all you have left is the artifact that works reliably if you
| maintain it and feed it proper inputs.
|
| Museums and Archivists need to run old software to be able to
| retrieve old documents. For most cases, you could use DOSbox,
| or QEMU , but sometimes you need the old programs on the old
| hardware.
|
| Finally, and likely most importantly, is nostalgia. For many
| of us our first _real_ computer was an IBM compatible running
| MS-DOS. Because you can 't buy DOS any more, FreeDOS does the
| job.
| Koshkin wrote:
| Some manufacturers can ship computers with FreeDOS
| preinstalled.
| blihp wrote:
| There was a fair amount of software written for DOS that
| never made the jump to Windows (or any other OS) and some
| combination of hasn't been economically viable to redevelop
| and/or people just really liked the way the DOS app worked.
|
| One common use case was control/monitoring software for some
| specialized piece of external hardware such as
| test/measurement equipment, security, HVAC etc. Much of this
| has modern substitutes available on current platforms, but it
| requires replacing the hardware as well as the software.
| Given that people paid 5+ figures for this stuff back in the
| day and if it still works, might as well keep using it until
| the wheels come off.
| hnlmorg wrote:
| > _In my opinion, it was amazing. Prior to graphical user
| interface, various DOS were the only interface in non-*nix
| world._
|
| Microsoft was late to the GUI party. Other platforms like
| Apple, Atari, Acorn, etc had proper GUI operating systems long
| before Microsoft did.
|
| Also DOS wasn't even the only non-GUI outside of UNIX. Micro
| computers had BASIC (which was a lot more powerful than DOS in
| some ways) plus support for Pascal, LOGO, and other languages
| on ROM too. They could also run other operating systems such as
| GeOS, CP/M and others many wouldn't have heard of. There were
| also LISP machines, dumb terminals which would access "green
| screen" TUIs, and a whole slew of other niche systems out
| there.
|
| DOS won because IBM-clones took over the world. DOS won because
| the hardware was cheap to clone not because the OS was the best
| of the era. Albeit it's fair to say once the momentum got
| behind IBM-clones DOS then continued to dominate due to people
| getting locked into MS-DOS applications. But DOS was never a
| particularly interesting operating system. If anything, CP/M
| was more interesting because it came several years before DOS,
| solved the hard problems that people took for granted with DOS,
| and ran on systems with far lower system memory (it was also
| the operating system that IBM PCs were originally intended to
| run -- but I'm sure you all know the conflicting stories behind
| that piece of history)
| LocalH wrote:
| > Micro computers had BASIC
|
| In a large number of cases, that BASIC was Microsoft's, as
| well. So they were already dominating the non-GUI realm of
| personal computing.
| hnlmorg wrote:
| Thankfully here in Europe we had more variety. Commodore
| was still hugely popular but so was Acorn (BBC Basic was
| one of the best of the era) and Amstrad (Locomotive BASIC
| was loosely based on BBC Basic, so also pretty awesome).
| Sinclair machines (eg Spectrum) were also popular but
| that's one of the few machines of that era I didn't do any
| development on (played plenty of games but man are their
| keyboards annoying for any prolonged typing!) so cannot
| comment on how Sinclair BASIC performed against Microsoft
| BASIC.
| Koshkin wrote:
| > _myriad of tiny programs_
|
| And not so tiny, too - DOS extenders made memory constraints
| practically nonexistent.
| MichaelMoser123 wrote:
| DOS was a terrible user experience; there was this constant fight
| to keep all the drivers and TSR programs working, deal with high
| memory, extended memory and other goodies, when the system was
| running out of low memory. Thanks goodness we are past that. No
| nostalgy for DOS on my part...
| pjmlp wrote:
| Given the amount of stuff people keep publishing for UNIX
| terminals, I would say plenty love to live in the past.
| adwn wrote:
| You think the DOS shell is in any way equivalent to a modern
| Unix-style terminal? Why, because they're both text-based?
| pjmlp wrote:
| From the point of view of TUI fetishism, yes.
|
| And to make a point, I started coding in 1986 and my first
| UNIX was Xenix.
| icedchai wrote:
| Plus consider that "modern" Unix terminals have barely
| evolved over the past 30 years. My circa-1990 NeXTStation
| is an incredibly slow version of what we have today. I
| even compiled bash for it!
| theodric wrote:
| For some things, e.g. mass-rename, or glob select file
| management operations, CLIs are much faster than click-click-
| click GUI operations. I use both, and I don't consider it to
| be living in the past to use the best tool for the job rather
| than using the newest thing because it's new.
| [deleted]
| pjmlp wrote:
| That is a big difference between that and living in a
| VT100, using VI directly from there, with a Window manager
| that has feature parity with twm, assuming one is used at
| all.
| chakkepolja wrote:
| Why do you bash* them so much? In almost every thread.
| pjmlp wrote:
| Maybe because luddites slow down progress.
| anthk wrote:
| A pencil and rubber still work and often a modern pen is
| not better. FM radio "degrades" better than DAB. And so
| on.
| [deleted]
| bluedino wrote:
| Carmack: We are not going to do another dos
| game. No amount of flaming hate mail is going to change
| my mind on this (PLEASE don't!). The advantages of good
| TCP/IP support, dynamic linking, powerfull virtual memory,
| device drivers, etc, are just too much to overcome.
| Yes, all of those can be provided under dos in various
| ways, but it just isn't worth it.
| ghaff wrote:
| DOS was OK so long as you stayed comfortably within 640K and
| avoided all the pseudo multitasking hacks like TSR. The things
| you describe are all about pushing DOS beyond it's rather
| limited fundamental design.
|
| That said it wasn't a great OS for it's time and isn't for most
| purposes today.
| hnlmorg wrote:
| It was pretty common for people to need different
| autoexec.bat configurations even just amongst gamers.
| ubermonkey wrote:
| I had an elaborate batch-file based scheme for swapping in
| different versions of both autoexec.bat and config.sys,
| depending on what I needed/wanted to do.
|
| It sucked.
| mook wrote:
| I think newer versions of config.sys (relatively
| speaking) had a menu system that greatly simplified that.
| It would set some environment variable to let
| autoexec.bat jump to the correct section too, I believe.
|
| Ah, Wikipedia says it's since MS-DOS 6.
| beervirus wrote:
| Ha, me too. And although I do look back on those days
| with rose-colored glasses... it did kind of suck having
| to futz with that stuff just to get a game to load.
| mixmastamyk wrote:
| The hardware sucked too! IRQ conflicts and changing
| jumpers! And better not close the case before you
| verified the new settings. :-D
| brk wrote:
| Or sometimes more commonly, an AUTOEXEC.BAT that provided
| the user a menu for which "mode" they wanted to boot into.
| Imagine having to choose between loading mouse drivers, or
| loading sound drivers.
|
| Then when networking started to be more common, choosing
| between loading an IP stack or pretty much anything else :)
| hnlmorg wrote:
| > _Or sometimes more commonly_
|
| You're describing the same thing I was :)
|
| > _Imagine having to choose between loading mouse
| drivers, or loading sound drivers._
|
| Indeed. This is why I don't get when people look back to
| DOS and say "wasn't it great".
|
| Also the hell of having to configure sound card drivers.
| The commands that needed to be entered precisely with no
| clue about why things don't work if they don't. You'd
| often end up spending hours, days or weeks just getting
| something simple working. And most people didn't have
| internet access then so you couldn't just look up the
| problem on Stack Overflow. People moan about Bash scripts
| being hard to parse, autoexec.bat was a thousand times
| worse to work with.
| leeter wrote:
| _Pulls up a recent LGR Video... watches griping about
| various expanded vs. extended vs. whatever memory issues
| games have_
|
| Yeeeep seems canon.
| DarknessFalls wrote:
| I had a batch file just to swap autoexec.bat and config.sys
| with *.bak counterparts depending on the game.
| ghaff wrote:
| Yes, mostly because you were screwing around right at
| memory and other limits of the system. (And it was mostly
| games--at least for typical consumers.)
| hnlmorg wrote:
| You're vastly understating just how commonly people would
| butt head with those limits though.
|
| You're also forgetting just how painful it was setting up
| a working autoexec.bat file in the first place. Never
| mind having dedicated chunks of code for some games and
| not others (eg do I need a mouse in this game? that
| driver is incompatible with this other bit of software,
| etc), just discovering what precise string of characters
| in your autoexec.bat was required to load the damn driver
| could be downright cryptic at times.
|
| DOS wasn't that great. We remember it with rose tinted
| glasses because that's what humans do. But DOS wasn't a
| particularly good operating system, even for its era.
|
| Gaming on DOS, now that was fun. But I'd argue it was fun
| _in spite of_ DOS rather than _because of it_
| ghaff wrote:
| Once you get into games, especially beyond monochrome
| text-based or maybe CGA, you were already pushing the
| limits. DOS was an OS for essentially text-based office
| apps in the early 80s and it just got pushed well-beyond
| that over time. And, yes, it made getting it set up for
| anything that wasn't a lowest common denominator setup
| very challenging.
| hnlmorg wrote:
| In which case you've basically described the vast
| majority of DOS's common use cases. So why even argue
| against my point?
|
| Also there were plenty of text-based office apps that
| required their own dedicated autoexec.bat config too.
| ZetaZero wrote:
| The best thing was, a reboot took 10-15 seconds, IIRC.
| rhacker wrote:
| Yep, for me it was those damn mouse drivers that took up so
| much of my ems memory.
| leeter wrote:
| DOS seems to have been the minimal effort choice of "It's
| like CP/M enough our users will be familiar with it" without
| actually considering those users. Now to be fair in 1981 that
| was "state of the art". The Xerox Alto was something that was
| way beyond reach for most people and GEOS (8 or 16bit) wasn't
| going to exist for another 5 years. But it was a marginal
| improvement over CP/M, which is about as much as one can say
| about it.
|
| Modern UEFI is probably the best parallel, both in that it
| only really deals with text and some graphics (bitmaps only)
| and doesn't have any standardized interface for sound/3d.
| p_l wrote:
| Interestingly enough, UEFI ships with UI toolkit. This can
| be partially customized by vendor, but essentially the idea
| is that for many simpler utilities and config panels, you
| can don't have to worry about details and just use a basic
| UI framework which will be handled into VT-UTF8 or GUI as
| needed.
| ghaff wrote:
| There were better 16-bit OSs in the minicomputer world at
| the time but they were all priced and developed for a very
| different world. It would have been interesting if
| something like RDOS (Data General) had taken off in the PC
| world but that world was just so price-conscious in
| comparison. Heck, the 8088 was chosen over the 8086 mostly
| just to have a smaller data bus.
| MichaelMoser123 wrote:
| don't know who said that 640K is enough, but it was very
| common to hit this limit in my time, around 1992-1993.
| Koshkin wrote:
| DOS extenders solved the 640K limit problem.
| mikewarot wrote:
| Windows is still a terrible user experience, you never know
| when it's going to stop working for half an hour or longer in
| order to run an update.
|
| Sometimes those updates cause printers or other peripherals to
| stop functioning. Sometimes they brick your computer.
|
| Once you have a computer working properly, running MS-DOS,
| Windows, Linux, etc... for the most part it stays running,
| forever... unless you change something.
|
| MS-DOS 6.21 with all the drivers, SideKick loaded as a TSR, and
| my 26th line clock program, with a 40 megabyte hard drive was a
| heck of a productive environment. The only thing that sucked
| was that we didn't have GIT, so you had to back up your source
| code to .zip files on floppy disks.
|
| I had a 300 megabyte backpack hard drive to allow me to make
| backups of my system, and customers. Plug that drive into the
| parallel port (that all computers had back then), and a book
| floppy, and all my stuff was right there.
| Rerarom wrote:
| Imagine how much you'd be valued for that sort of knowledge!
___________________________________________________________________
(page generated 2021-09-13 23:02 UTC)