On Mon, Aug 7, 2023 at 7:24 PM Rugxulo via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote:
> Hi, > > On Mon, Aug 7, 2023 at 7:45 AM Liam Proven via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > > > On Sun, 30 Jul 2023 at 17:55, Rugxulo via Freedos-devel > > <freedos-devel@lists.sourceforge.net> wrote: > > > > > I believe "task swapping" was one of the main benefits of a 286. > > > > It's not a 286 hardware feature, no. > > > > It's a feature of DOS-compatible OSes of the 286 era. It's a software > > feature not a hardware one. But it was enabled by XMS memory > > management, something that a DOS could only do on a 286 or later. > > Wikipedia says the 286 "was designed for multi-user systems with > multitasking applications". OS/2 1.x targeted it. > What it was "designed for" is irrelevant. Also, Wikipedia, the free encyclopedia that *anyone can edit*. 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. ELKS - the Embeddable Linux Kernel Subset - performs preemptive multitasking on an 8086. > > > > 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. > > > > > (This probably also goes back to IBM's own > > > TopView, which predated DesqView.) > > > > I don't think TopView did much multitasking at > > all, but the thing here is that the DesqView style of multitasking is > > done in software and everything has to fit into conventional memory: > > all apps share the base 640kB of RAM. > > Wikipedia says "TopView is the first object-oriented, multitasking, > and windowing, personal computer operating environment for PC DOS > developed by IBM". > > > The later 386 type of multitasking doesn't: it's using hardware to do > > it it and the software is running in protect mode and has up to 4GB of > > virtual address space to play with. > > > > It's a really big important difference. > > I'm sure you're more familiar with OS/2 1.x than I am. But clearly > that multitasked apps on a 286 in protected mode. > Yes, but only OS/2 applications. DOS applications - when they ran at all - were limited to one at a time, and the entirety of OS/2 (minus the few parts needed to run the DOS environment) was paused when the DOS session was in the foreground. TL;DR: OS/2 1.x didn't multitask DOS programs and freezes when DOS programs run. > > > > > Anyone who wasn't booting straight into Windows, and who still used > > > > DOS apps, I configured the PC to boot straight into DOSShell instead. > > > > I made menu entries for all their DOS apps, and one for Windows 3.x > > > > too. > > > > > > Clearly OS/2 and/or Windows were considered the future. (Novell's > > > attempt at improving DR-DOS failed against Win95.) > > > > Clearly according to whom? > > 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. 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. > > > > > [6] By 1993-1994 most PCs booted straight into Windows 3.1 but I made > > > > launchers for their DOS apps in Program Manager, and in the > > > > background, I hand-optimised their RAM with EMM386.EXE so there was > > > > lots of free RAM for those big power-user DOS apps. > > > > > > Win95 was better. (I still have my overformatted "upgrade" Win95 > floppies.) > > > > That seems a bit like saying that the wheel is better than fire. > > > > It's a different thing that happened at a later time. They are not > comparable. > > As far as DOS compatibility goes, Windows 3.1 and 95 had a lot in common. > Pretty much. Both of them work by running a VM hypervisor, the Virtual Machine Manager or VMM (WIN386.EXE or VMM32.VXD), and then loading the Windows/386 kernel (KRNL386.EXE) into the "root" VM (what you'd call "dom0" in Xen terminology). The main difference is that Windows 95 has better utilization of the underlying virtual machines, including mapping memory pages to multiple VMs. Each individual Win32 thread existed in a separate VM; a process was simply a group of VMs that shared a single page table. The 16-bit programs all share the "root" VM as in Windows 3.1 (under 3.1, the entirety of the Windows GUI ran in a single virtual machine. Only DOS programs got individual VMs.) As for preemptive scheduling, only virtual machines are scheduables - the Virtual Machine Manager (VMM) has no concept of processes or threads. Windows/386 2.x does much the same but it's even more primitive than Windows 3.x in 386 Enhanced Mode. Yes, this means Windows/386 2.01 and later basically did what VMware/VirtualBox/Hyper-V do today, using the 80386's Virtual 8086 Mode as the hardware virtualization mechanism. VxD drivers, then, implement hypercalls, not system calls. > > > > 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. > Correct; it was expected that Windows NT 4.0 would be used on NTFS and not FAT. NT 4.0 also predates Windows 95 OSR2; Windows 95 had DOS features (FAT32, LFNs) that Windows 95 didn't get until Windows 95 OSR2. Therefore, Windows NT 4.0 and Windows 95 were equivalent in their lack of FAT32 and LFN support in their respective initial release forms. 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/286 2.x through Windows Me instead mapped the pre-existing DOS environment used to start Windows into every VM. NTVDM doesn't really allow much in the way of extension, whereas VMM allows for loadable VxD drivers that can emulate hardware for the VMs and provide new hypercalls to extend the environments (including DOS environments) inside. This is why the 16-bit .drv portion of Windows 9x/Me drivers were often referred to as "miniport" drivers (they mainly served to make hypercalls to the companion VxD that actually interfaced with the hardware.) The Windows Driver Model introduced in Windows 98 and present in Windows Me complicated things by allowing a subset of Windows NT drivers to be loaded into the VMM alongside traditional VxDs. The PE loader and limited "ntoskrnl.exe" exports were hosted in NTKERN.VXD. This is how they were able to implement the Windows Driver Model on top of Windows 2000 later on - it really was just a restricted subset of the existing NT driver model with some unique extensions - 2000 just needed to have the extensions added to the existing NT base. > > > > > DOSShell was a great DOS app launcher and file manager, but didn't > have apps. > > > > > > Apparently "Visi On" in 1983 was the first (and yes, it did allow > > > third-party apps in "restricted subset of C" for its VM.) > > > > I don't really see any connection here, TBH...? > > Wikipedia says "VisiCorp Visi On was a short-lived but influential > graphical user interface-based operating environment program for IBM > compatible personal computers running MS-DOS". > Randomly quoting Wikipedia to try to sound relevant? Not a good look, especially when you're clearly doing so to "me too!" the conversation. Please stop, you're embarrassing yourself. Visi-On used a p-code type bitcode system a la modern .NET or Java. Programs were written and compiled on a UNIX workstation and then executed on a PC. The Visi-On system's use of an architecture-independent bitcode meant that all Visi-On programs would be instantly ported to every new architecture to receive Visi-On with zero effort necessary. 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. What's the connection? You're discussing early PC multitasking systems, yes? Visi-On was an early PC multitasking system of some sort. There's your (so painfully obvious that I feel my IQ dropping from having to explain it) connection. However, it doesn't multitask DOS applications, only Visi-On GUI applications. > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
