Eric, I only mentioned the Windows portion because it would tie in compatibility on the Microsoft side of things for classic software, not necessarily to re-invent Windows 3.x or Windows 9x.
I'll try to elaborate more. If you strip the GUI from MS Windows, you have 3 important parts that run to implement 32-bit protected mode. KRNL386, DOSX (the DOS Extender) and a virtual machine manager. If we were able to recreate those three components and build them in such a way that they are compatible with Windows virtual device drivers, we'd have a 32-bit extension to FreeDOS that we could use At the core of it's existence, The portions of the Windows 3.x subsystem that tie into DOS in 386 Enhanced mode consists of a DPMI server and a virtual machine manager of sorts. Microsoft patches certain aspects of DOS when Windows runs. In 1993, we were at best guessing (unless you had an OEM NDA) what was going on and depending on Andrew Schulmann et. al. to provide insight. Now, that we can clearly see what was done (more or less), we can implement a similar concept, but a different way. FreeDOS presently appears to run in protected mode (I found that out trying to run Windows in enhanced mode). The error message that Windows gave was that the processor was already in protected mode. Microsoft demonstrated a means of providing multitasking and 32-bit functionality on top of a 16-bit OS through the development of Windows 3.x and Windows 9x. If we are able to build a 32-bit subsystem that can utilize the device drivers and other existing components of the 32-bit Microsoft subsystem (Win32s or Windows 9x) then FreeDOS gains a 32-bit option that provides the backwards compatibility that is needed to meet spec. If, by doing that, running Windows applications becomes a possibility, that is only a side benefit. The other alternative is to find a way to implement the DOS API completely in a 32-bit address space, which alienates the older applications. On Thu, May 28, 2015 at 8:55 PM, Eric Auer <[email protected]> wrote: > > Hi :-) > > > 1. Start FreeDOS (16-bit mode) 2. Start FreeDOS-32 via a separate > > executable (it would only be installed if it detected a 32-bit > > capable processor), perhaps call it FD32. It would switch to > > protected mode and spawn a protected mode shell. > > http://freedos-32.sourceforge.net/ already exists. No news since 2011. > > FD32 runs more parts in 32-bit, but the advantages compared to using a > classic DOS together with a DPMI compatible DOS extender are minimal. > > > The other possibility During the install, determine if the computer > > can support 32-bit instruction set If so, install FreeDOS and install > > the FreeDOS 32-bit components (provide an option to only run the > > 16-bit OS) FreeDOS 32 starts automatically by running the initial > > 16-bit environment, then spawning the 32-bit environment to take > > over. > > We once pondered this as part of the ISO boot process. But because > it is almost impossible to boot from CD on 8086 or 286 computers, > we dropped the idea. Instead, just take a floppy with a special 16 > bit, 8086 compatible version of DOS if you have such old hardware. > The ISO simply assumes that you have 386 or newer hardware anyway. > > Interestingly, 8086 or PC-XT compatible FreeDOS floppy distros are > actively discussed here and even updated at this very moment :-) > > > All existing drivers developed for FD16 would work. If we use the > > Windows SDK to clean build the 32-bit environment, then perhaps we > > can use Win9x drivers (if they are even still available). > > You cannot use Win9x drivers for DOS software. Also, you cannot use > Windows for Workgroups 3.11 in 386 enhanced mode and expect it to > behave well: It will use built-in 32 bit disk and FAT drivers which > do not work well at all with modern things like FAT32, LBA, SATA. > > You can disable those drivers, but running WfW 3.11 in that mode is > like running Win9x in safe mode: A lot of comfort gets lost. If you > want to enjoy Windows 3 in FreeDOS, use Windows 3.0 or 3.1 and use > standard mode, not WfW 3.11 - even 386enh mode of 3.0 / 3.1 is very > fragile as all your drivers have to cooperate and let Windows take > over as the boss of your protected mode infrastructure, locking the > DOS kernel into a vm86 bubble with a task switching wrapper around > it. FreeDOS tries to support that in newer kernels, but this stays > really hard to do well because basically Microsoft Windows is only > skilled in making bubbles around Microsoft DOS, so we can only try > to be very similar in the parts to which the 386enh bubble sticks. > > > Otherwise, we’d have to clean room Win NT to implement a 32-bit OS > > and ReactOS is still in alpha... > > If you want to use 32 bit Windows programs (beyond Win32s for 3.x), > you do not have the option to use DOS for that. You must use either > ReactOS or Linux with Wine or a closed source OS like OS/2 or actual > Microsoft Windows. In some cases, Japheth's HX / HXRT for DOS will > be able to run really lightweight Windows programs in DOS, of course > only one at a time and only in full screen mode. > > >> However, the folks here seem to have come to the conclusion that > >> FreeDOS will not evolve into the 32-bit realm. > > DOS extenders already have allowed DOS programs to live happily in > the 32-bit realm since the 1990s :-) Next question is what about > the 64-bit realm? Answer is that DOS extenders for that are at an > extremely experimental stage and almost no programs use those yet. > > But at least you can enjoy all your 1990 DOS games and similar and > they can enjoy using between 2 GB and 4 GB of those 64 Gigabytes of > RAM that your newest game PC has ;-) Of course the games still only > use one of your 16 CPU cores, but hey, they were made for 0.1 GHz! > > Cheers, Eric :-) > > >> The goal is existing compatibility so that older DOS applications > >> will run. Obviously, moving to 32-bit will eliminate most of the > >> older processors, HOWEVER. by implementing a Windows 9x like model > >> and build a 32-bit kernel to supplant the 16-bit kernel, we can > >> then spawn 16-bit VM under a 32-bit kernel to run each 16-bit > >> application, as well as develop 32-bit applications. > >> > >> The important pieces I believe that need to be figured out is the > >> VMM (Virtual Machine Manager) and the DOS Extender. I only suggest > >> Windows 9x because it was still able to utilize real mode DOS > >> drivers. > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
------------------------------------------------------------------------------
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
