I'd have given my left nut to have desqview in the late 80s/early 90s. I was just a kid with a homegrown BBS but the concept was out-of-this-world cool.
hey there, friend! still running a wildcat BBS on DOS and Desqview here. 5 wildcat instances on a Pentium 133MHz box with 32MiB of RAM and a NETBIOS connection to a fileserver, access to the nodes via a rocketport sio board and a serial server for telnet. gotta admit desqview, when properly tweaked up, really is an amazing bit of magic.
currently trying to get things moved over to freeDOS and virtualize the whole thing on qemu with virtualized serial I/f for the BBS. still gonna use desqview if I can get everything to play nice.
oh, the memories!
Wow it's amazing you've still got one going. Are you still letting users connect to the system? Over IP I'd imagine. Recently I went down the rabbit hole and found that MajorBBS is now available for free. I installed it in a virtual dos environment and got tcp/ip connections to it up and running. That system, at least in it's heyday, was one of the few that could run multiple lines simultaneously in DOS and I always wanted to see the backend.
My BBS back in the day was running Wildcat! As well and then eventually moved to RoboBOARD which had the first mouse gui system. For the front end I used BinkleyTerm to get FIDOnet working. For a lot of the time it was up and running on OS/2 as well, so I could get multiple lines working.
Such great stuff that led me directly into an IT/entrepreneur career.
I ran a FidoNet BBS back then on a 386-16 and 2400 baud modem. Woot! It would run WordPerfect 5.1 while people were logged on to the board but compiling brought it to its knees.
Nice trip down memory lane.. Quarterdeck ftw
I'm not familiar enough with 8088 to know... And it doesn't seem to come up in a search... How the heck did they do (presumably) pre-emptive task scheduling on that chip? Anyone know?
You'd need some kind of timer interrupt that has very high priority to be able to do something like that I would think.
You're on the right track with the timer interrupt assumption!
One of the key techniques involved the use of the Intel 8253/8254 Programmable Interval Timer (PIT), present in IBM PCs/compatibles at the time. DESQView would reprogram this timer to generate interrupts regularly, and more frequently, than its default setting used by the operating system for clock ticks.
When this timer interrupt fired, DESQView's interrupt handler would kick in, save the current state of the CPU (registers etc), and then switch the context to another process by loading its saved state. By juggling the CPU time between different programs this way, DESQView could give the illusion of running multiple programs simultaneously on hardware that was originally designed for a single task at a time.
DESQView used other tricks too, like monitoring keyboard and mouse interrupts, to make multitasking smoother. Pressing the Alt key by itself brought up the DESQview menu, and pressing Shift+Alt allowed you to record custom macros. A more interesting thing was how DESQView managed to intercept Ctrl+Alt+Del - pressing it would only terminate and close the window you're in, instead of rebooting the whole box, which, at the time felt like black magic because normally nothing intercepted Ctrl+Alt+Del - you expected it to just work and reboot the box without question.
cc: @raduzaharia@lemmy.sdf.org
Very cool! I appreciate the detailed explanation. Sounds like the coders behind it really knew their stuff.
You could install interrupt handlers in DOS more or less as if you were in the kernel of a higher-level OS. It was honestly dead simple -- just "please run this code on an interrupt," and that's exactly what it would do 🙂. There wasn't any priority or access control; you could request any interrupt, and if you wanted to also have the previous handler run, you had to call it yourself. My guess would be that they just installed a timer interrupt, and every X milliseconds they would just swap the instruction pointer and stack over to a different program, so the programs take turns just like in a memory-protected multitasking OS.
I'm not real familiar with how well you might be able to do memory protection. My guess would be that it all just runs unprotected in the 0-640kb range on an 8088, so your programs had to share and not step on each other, and that some things can be swapped up into 640kb-1mb range on a 286, but I'm not sure on either count. I worked on them but I never really understood the way 8088 and 80286 chips segmented their memory; it was famously fairly bizarre.
But the task scheduling you could absolutely do.
Thanks! I had forgotten about segment registers. Makes more sense now than it did when I first learned about them ages ago.
86Box can emulate the 8088 and WinWorld has the first version of DESQView so I might just try it. As for how they did it...I wouldn't know.
I remember that well. We used DESQView to run our BBS as well. It was only a single line system, but DESQView let us do other things on the computer without taking down the board.
Has anyone played with TriDOS? https://github.com/prokushev/tridos - it doesn’t look nearly as featured, but has the advantage of being open-source and I thought might be interesting for a project I have in mind.
I programmed a few BATCH commands to switch windows and run certain apps to upload mortgage document files to remote offices
Discussions on vintage and retrocomputing