On Sun, 13 Jul 2014 19:41:54 +0200, Michael B. Brutman <[email protected]> wrote:
> The road map from the Wiki dated August 2010 seems to be wildly > optimistic. It is talking about tightly integrated protected mode > support, protected mode networking and USB, borrowing device driver code > from other OSes, etc. > > I don't think that road map is feasible. Ever. I think it is. Just not immediately. Projects like MenuetOS and BareMetal OS have shown that it is possible to do DOS-like operating systems taking advantage of 32-bit and 64-bit processors. By "DOS-like", I mean an OS that is written mostly or entirely in assembly, has a very small footprint, and gives applications direct access to the hardware - without reusing much or any code written for other operating systems (since writing drivers for new operating systems today sadly largely seems to mean porting code written for Linux). > Tightly integrated protected mode support basically leaves 8088 or 80286 > class machines behind. Which seems fair given that those machines are > 25 or more years old now but a big "market" for running any form of DOS > is to support old hardware. So a new version of FreeDOS that does not > work on that hardware limits its reach. (I suspect that those machines > would be perfectly happy remaining frozen in time, running an earlier > version of FreeDOS so this may not be a real issue for them.) If "tightly integrated protected mode support" means having a DPMI host built into the kernel and running the current FreeDOS kernel in virtual 8086 mode, I don't think pre-386 support has to be dropped. Just run the 16-bit kernel directly in real mode. I don't know how you'd natively run it in long mode (on 64-bit processors) though, since there's no virtual 8086 mode there. (I might be wrong there because I don't really know much about x86-64, nor DPMI really.) But I don't know of any 64-bit DOS software either. Alternatively, two kernels could be maintained, the pre-386 one being based on the current one, so that pre-386 machines can at least benefit from bug fixes. This would require much more effort though, so I'm in favor of the virtualization approach. > Re: Protected mode USB. What does "protected mode" mean in this context > - is the intent to run in protected mode all of the time, not just > switch into protected mode when an application loads? I understand it as the USB drivers running in protected mode. But I'm not sure why that is better, as Bret Johnson's (and many other) USB drivers show that it's possible to have USB support in real mode. Unless protected mode would somehow improve performance? > Re: Protected mode Networking. Every DOS application "brings its own" > networking code. To take advantage of any new networking you would need > to change the applications. But apparently having to write applications from scratch wasn't a problem for you when you started writing mTCP. :) I think it could be done by writing e.g. a WATTCP-compatible library that would just call the kernel or, preferably, a TSR to do the actual processing. Then each application using WATTCP would only have to be recompiled to use the new networking code. > I don't think there is any point to adding new features to FreeDOS that > older applications can not use. I agree that we should consider backwards compatibility first when adding new features. So before adding protected mode networking or USB drivers, I would rather have Sound Blaster-emulating drivers for modern sound cards, and, less importantly (for me, but maybe not for others), drivers that intercept BIOS printer functions and convert e.g. ESC/P commands to PostScript. > if hardware support becomes too much of a problem then falling back to > emulation environments that run FreeDOS in a virtual machine might be > the answer. (If you have a hard requirement that FreeDOS boots on bare > hardware then this does not work for you.) IMO, if your OS can't run without requiring another OS and some sort of emulator, you can't call it an OS anymore. Having DOS on real hardware is very important to me, and I'm sure people using it for e.g. embedded systems and other niche markets would agree. Is there such a thing as a BIOS emulator for UEFI systems? > What I do see as a threat is the lack of people who know how to code > under DOS, whether that be applications, TSRs, device drivers, etc. I think the lack of people comes from the lack of documentation. Writing a TSR isn't difficult if you know assembly language. But some things are really only known to very few people. For example, I'd love to know how to write a network redirector (is that the proper name?) to let DOS access additional file systems and/or networks, but I simply don't know where to start. > We need to clean up our documentation, improve our install and updating > process, and generally do things that attract new users. I agree with the installation part. The installer for FreeDOS 1.1 takes forever to install FreeCOM and I'd abandon the idea of disksets entirely. If someone is not installing FreeDOS from a CD, but from floppy disks, they probably know which packages they want, so it shouldn't be too hard to just ask "please insert the disk containing the file MTCP.ZIP". Regarding documentation: what kind of documentation are you talking about? I think that over all, DOS is the best documented OS there is, having Ralf Brown's Interrupt List and hundreds of books documenting it, but, as I have said, some areas are not documented well enough. > I'm trying to make network programming under DOS easier by providing a > pretty complete framework for doing it. That's great. Please continue. :) ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
