Hi, On Tue, Aug 8, 2023 at 10:46 AM Kirn Gill via Freedos-devel <freedos-devel@lists.sourceforge.net> wrote: > > On Mon, Aug 7, 2023 at 7:24 PM Rugxulo via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: >> >> Wikipedia says the 286 "was designed for multi-user systems with >> multitasking applications". OS/2 1.x targeted it. > > Multitasking requires no special hardware whatsoever. Cooperative > multitasking simply requires an API > designed to yield control to the next task upon a system call. Preemptive > multitasking only requires a timer > that generates a hardware interrupt with sufficient regularity.
I have never used Desqview nor Desqview/X (DJGPP v1 SDK), so I don't know how those worked. But I have used DR-DOS 7.03's 386 multitasking. To me it was nice but limited use (to my usage scenario) because it was limited to 64 MB per task and required their DPMI (and their EMM386) to always be enabled. (DR-DOS also can run Windows 3.x but not quite run Win95 although allegedly comes close.) > ELKS - the Embeddable Linux Kernel Subset - performs preemptive multitasking > on an 8086. I never got around to trying ELKS. The lack of obvious releases (back in the day) confused me. I can't remember if they used a FreeDOS boot disk or not. They claimed networking and LFNs. It sounded interesting, but I was never sure what apps were precompiled for it (IIRC, using BCC/dev86). QEMU Advent Calendar had an image for it, but I don't think I ever got around to trying it. Comparatively, I've (rarely) run the 16-bit Minix 2.0.x a few times. They used segmentation to share static code between processes, I think (e.g. multiple instances of the same executable). Several caveats but still a cool OS. >> > > For >> > > instance, DR-DOS 7.03 supports "task swapping" on 286s but only >> > > "multitasks" on 386s. >> > >> > Yes, because it uses 386 hardware features to do multitasking. Its proprietary EMM386 doesn't need a separate HIMEM.SYS and has embedded VXDs (or something weird like that which I don't understand) and a built-in DPMI server. Although it reports "XMS 3.0", it really caps out at 64 MB. >> OS/2 was "a better DOS than DOS". Originally it was even codenamed >> "DOS 5", right? The so-called "European MS-DOS v4 that multitasks" >> used NE format in real mode. That's similar to OS/2 (which also used >> NE, as did Win 3.x). >> >> DOS was never their top priority, but it made them money. >> Compatibility was important (for a time). >> >> I doubt they originally intended to sell multiple OSes, but when you >> try to support 8086, 286, 386 ... what can you do? Ever-increasing >> memory amounts needed newer OSes and APIs. > > The original plan was to let Windows fade away after 2.x; there was an > engineer at Microsoft that mostly > improved Windows by himself enough to run all of the Microsoft Office > components at the same time > (a difficult, if not impossible feat under Windows 2.x of any flavor) and got > an executive's attention shortly > after the OS/2 launch with his experimental Windows build that it caused > Microsoft to repivot around DOS > and Windows again. Gordon Letwin had a long post explaining his view of the MS split from IBM: * https://groups.google.com/g/comp.os.ms-windows.misc/c/-iNeep60eVE/m/Xl5ddAtJENcJ?hl=en > My understanding is that OS/2 is a direct descendant of Multitasking MS-DOS > 4.10 (an even rarer update > to the already-rare multitasking 4.00) with a LOT of reengineering behind the > scenes. Limited analysis with > Ghidra, however, can neither confirm nor deny this hypothesis at this time. Most of the work on the 1.x (16-bit) versions of OS/2 was done by Microsoft. Supposedly their 32-bit "portable rewrite" is what became NT. (However, Win95 could still barely run atop a 386 with 4 MB of RAM, so it stuck around on the consumer side.) >> > > NT was not aimed at DOS software. It was incomplete in DOS support in >> > > many ways (and had a much higher footprint). >> >> Win95 had DOS features (FAT32, LFNs) that NT didn't get until Windows 2000. > > But back to DOS, NT's support for DOS is cruddy on purpose. It's meant as a > developer compatibility tool > to keep old compilers working, it wasn't really meant for consumer use. On > i386, it's uses the Virtual 8086 > Mode to implement a fresh DOS environment. Windows 3.0 and Windows NT 3.1 both had many DOS bugs that were only fixed later. Heck, Win95 had various bugs. Even XP (which "mostly" worked) had bugs. NT wouldn't run Quake because of its DJGPP's nearptr usage while Win95 could (with help from CWS of CWSDPMI). Some bugs in XP were worked around in DJGPP "patchlevel 2" to 2.03 (aka 2.03p2). So apps compiled after that (late 2001) actually worked again. I don't think OpenWatcom for DOS had the same fixes / workarounds, so it's less stable on NT. A ton of DJGPP code relied (and still relies) on building atop NTVDM (mostly due to LFNs). DJGPP still hosts a TSR / DLL combo for NT 4 to work with LFNs. > Visi-On used a p-code type bitcode system a la modern .NET or Java. James Gosling was familiar with UCSD Pascal (based upon ETH Zurich's Pascal P sources) which also used pseudo code. (P4 has been ported to DOS, so has its successor P5.) There was also (an official??) Java 1.1 build for DOS in 1997 via DJGPP, but I've never seen much mention of it being used. > Because of this, Visi-On was able to implement a multitasking scheme that was > completely divorced from > the hardware (in)capabilities of the IBM Personal Computer and/or its Intel > 8086 processor. However, > it doesn't multitask DOS applications, only Visi-On GUI applications. Feel free to make P4 or P5 multitask. (The old Copascal and various Ada interpreters for DOS were loosely based upon Pascal-S, I think. GWU Ada was verified at one point. There also was an EZ2LOAD GNAT/DJGPP build in the late '90s that allegedly had some tasking support. But later GNAT builds didn't due to whatever obscure reason.) Yes, this is getting a bit off-topic, but Jim mentioned GEM and apps, so I was reminded of Visi On (running atop DOS with its own apps). Long story short: I don't think FreeDOS not having a DOSshell clone is a significant omission. Nobody will write the "program switcher" code (too complex), and we already have file managers. So I don't see what else it would offer. Feel free to prove me wrong, but there's just too much inertia and not enough time or experience to do such heavy tasks like that. FreeDOS is already good enough as it is. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
