DESKTOP is a graphical user interface for DOS, which ones used to be a commercial shell like MS-Windows 3.0 or GEOS. However, due to the dominance of MS-Windows 95, we were forced to stop publishing the program, so it’s free now…
I’ve done a lot of digging into these alternative shells for both MS-DOS and Windows 3.x/9x, but I had somehow never heard of this one. It’s freely available, and has some neat and interesting features, like copy and paste, a full file manager, and much more.
Nope. I’ve just tried this thing in DosBox.
1. No multitasking of any kind: either you’re running something or you need to close it
2. It basically exists for itself
3. UI is as basic as humanly possible
4, No real graphics – it runs on top of DOS graphics mode
5. No API of any kind
6. No networking of any kind
Even Windows 3.0 is leaps and bounds more advanced. Windows 3.0 was basically an OS. Quite limited and with no real multi-tasking (Was NT 3.5 the first Microsoft OS to implement it? Don’t remember now).
I’d call this thing a pseudo-graphical Norton Commander/Volcov Commander clone. That’s it. Microsoft had nothing to do with its demise.
Xenix was MS’s first multitasking OS. For a while in the 80s MS was the largest unix vendor I think.
Xenix was quite popular and Microsoft used to have a three step plan before starting on OS/2 and NT.
Basic users would get DOS with no multitasking and most limited feature set.
Intermediate users would get XDOS that was a low requirements hybrid between DOS and Xenix
Advanced users woulg get Xenix as it had the most features, bells and whistles.
I saw a claim back in the day, that the focus on Xenix was dropped by microsoft as it was seen as a competitor to their OS/2 contract with IBM.
Wasn’t there a DOS 4 version with multitasking?
smashIt,
There were several ms dos competitors that supported that. Here are just a few.
en.wikipedia.org/wiki/PC-MOS/386
en.wikipedia.org/wiki/DESQview
en.wikipedia.org/wiki/DR-DOS
Surprisingly microsoft was a laggard in terms of a multitasking DOS (if you don’t count windows support for DOS multitasking).
However you might be thinking of ms dosshell?
https://archive.org/details/msdos_dosshell
https://www.os2museum.com/wp/multitasking-ms-dos-4-0-lives/ shows it in operation. Seemed to have been slotted to compete with DRI’s DOSPLUS. If one wasn’t going to stick with what IBM was offering, may as well go for DRI and take advantage of the larger pool of background friendly Concurrent CP/M-86 programs.
krebizfan,
Wow, apparently there were two versions of “MS DOS 4”. One was an unshipped branch of MS DOS 2 with multitasking features added. but it did not ship through normal channels. And the one most people would be familiar with was the successor to MS DOS 3 without any multitasking.
Eugenia Loli posted about this on osnews 🙂
https://www.osnews.com/story/6452/ms-dos-40-the-next-gen-dos-that-never-shipped/
t don’t remember hearing about it before, but obviously this is exactly what smashit was referring to. Thanks for the info & links! It looks like a proof of concept. I wonder why ms didn’t clean it up and add to shipping versions of DOS. I guess it would go on to become dosshell? It still looks like multitasking MS DOS 4 was behind other multitasking DOS competitors.
To move the needle a bit further…
Windows 3.1 had multitasking. Albeit it was “cooperative” multitasking, but you could run many applications at the same time.
It also had:
* Limited 32bit API: https://en.wikipedia.org/wiki/Win32s
* Ability to run multiple DOS applications (v86)
* Again DPMI for high memory DOS applications
* Networking (especially in Windows for Workgroups)
* “Proper” graphics drivers
* OLE and registry
And many other “modern” operating system components.
Yeah, I remember that “multitasking”, it wasn’t just cooperative, the minimized apps basically stopped completely but you could revive them by restoring them.
Was registry a Windows 3.1 thing? I thought registry was created with/for Windows 95.
Artem S. Tashkinov,
I don’t recall the windows 3.1 scheduler preventing minimized windows apps from running. You could even use invisible windows for your event loops. While windows uses window handles for event queues, it’s cooperative multitasking wasn’t tethered to the state of the UI. Background/minimized applications could wake up to handle events without being in the foreground. Interestingly DOS application did use preemptive multitasking even in windows 3.1. They continued running in the background with smaller time slices. This allowed things like DOS dialup software like to continue working in the background under windows.
I thought it started in 3.1, but I had to check to be sure…
https://en.wikipedia.org/wiki/Windows_Registry
Yes, basically this was the point. You had to actively ask for CPU slices by setting up timers or other events. If you did not receive messages, your app you just stay “suspended”.
https://en.wikipedia.org/wiki/Message_loop_in_Microsoft_Windows
Somehow it worked most of the time. Which is a major achievement for a software of its time (286 – 386 era)
sukru,
IMHO event oriented programming is quite sensible. You get one or more events, you process them, and then return/yield. I often elect this event oriented programming model over blocking threads for my own software. Of course, long/infinite loops break the model, but even a cooperative multi-threading OS should still be able to kill hung programs via interrupts such as a keyboard or timer event, say to pop up the task manager.
https://guidebookgallery.org/screenshots/win311fw
However I don’t know if windows 3.1 did that. Does anyone know what win31 did in the case of hung tasks? I’d imagine this is something microsoft would have anticipated, but beyond DOS, which I programmed for into the 2000s, my experience with technology of that era is too limited.
Alfman,
If I recall correctly, we’d hit Ctrl-Alt-Del and it offered to kill the current hanging program.
Checking… Yes, it was the case: https://devblogs.microsoft.com/oldnewthing/20140912-00/?p=44083#:~:text=Although%20you%20can%20use%20CTRL,key%20to%20return%20to%20Windows.
I am not sure this required 386 or worked on 286 as well.
sukru,
Awesome, good find!
I would imagine it works well enough for software & drivers operating from the same 286 CPU mode. However Intel’s 286 protected mode had a glaring design fault – it was one way! There was no instruction to switch back from 286 protected mode. IIRC the only way to switch modes was to perform a full CPU reset. IBM compensated for intel’s limitation by added motherboard logic to physically reset the CPU and checked some flags in the BIOS bootup sequence to return control to the OS & software, which was already loaded in memory. It was nuts, and slow. A triple fault also caused the 286 to reset.
https://retrocomputing.stackexchange.com/questions/11954/how-to-switch-an-80286-from-protected-to-real-mode
So task switching on a 286 (between dos software/drivers and windows) was technically possible but my understanding is that the CPU would have to be reset every time you needed to switch modes like scheduling a DOS time slice from windows or accessing EMS memory from DOS Ouch!
I have to wonder if, in addition to the overhead, there were other race conditions resulting from the CPU resetting. I guess as long as interrupts are disabled across the reset, they wouldn’t get lost.