On Sun, 13 Jul 2014 21:24:40 +0200, Michael B. Brutman <[email protected]> wrote:
> Re: FreeDOS vs. DOS-like operating systems > > There are plenty of DOS-like hobby projects out there. But without > applications, they are pretty limited. I think a lot of the value in > DOS and FreeDOS is the ability to run existing applications. So we need > to decide on what we are trying to do; are we going to morph FreeDOS > into yet another hobby operating system that is only slightly compatible > with existing software, or are we going to keep it an open DOS clone? I never suggested dropping DOS compatibility. But maybe defining a 64-bit long mode equivalent to DPMI wouldn't be a bad idea. > Re: Protected mode networking > > Networking provides the most value when it is an integral part of the > operating system. Otherwise, we just have disparate applications that > bring their own library code that the OS is unaware of. No, this only happens when there is no well-defined _interface_ to networking code. You don't see each DOS application containing its own network card drivers, because fortunately there exists a (de facto) standard for network protocol implementations (e.g. mTCP) to talk to network hardware. So we should come up with a standard for end user applications (Web browsers, FTP clients, etc.) to talk to network protocol implementations. Preferably one backwards compatible with the NTCPDRV API, but with IPv6 support (for future extensibility - implementations wouldn't be required to implement it) and a function to resolve host names so each application wouldn't have to supply its own DNS client. The functionality wouldn't necessary have to be part of the kernel, it could just as well be implemented by a TSR, and IMO it should be, because if you don't need networking or if there is no packet driver for your hardware, it would just waste memory for no good reason. > Even just the limited "fix the libraries" solution does not work because > many of the networking applications are stuck in the 90s. The > application code needs to be fixed too. In general, networking needs > much more focus; the libraries really are not the problem. Please explain how it is "stuck in the 90s". As far as I'm aware, all networking code (from the end user application programmer's perspective) is essentially variations on the theme of "create a socket, open it, send and receive data, close it", although the APIs are not necessarily compatible. > Re: Emulation environments > > We're going to have to face reality one day; hardware will move away > from FreeDOS faster than FreeDOS can keep up with it. Unless we can > attract a lot more interest in hard-core, low level programming skills > then emulation will be the only way to deal with this problem. It may be so, but this does not mean we should abandon the idea of running on hardware entirely. > We need a DOS programming Wiki that can get people started. Things like > what development environments are available, primers on real mode vs. > protected mode programming, where the good libraries are, reading lists > on where to look for more, suggested books, etc. A wiki is not necessarily the best idea, as it would involve unnecessary duplication of existing content and contribute even more to the fragmentation, but we could start by making lists of links to Web sites, and, as you said, a general overview for beginners. > The network redirector interface is a poor example to use; it has never > been properly documented. Which is why I think it's a perfect example. :) > If you have the 2nd edition of "Undocumented > DOS" then you can get pretty close to it. There was a new project > announced here recently that used it to provide file system access under > VMWare. Thanks, I'll look into it. > I have looked at it a few times to implement my own version of > a network file system and I've just decided it's not worth the effort. "I have looked at the TCP/IP specifications a few times to implement my own TCP/IP stack and I've just decided it's not worth the effort." Don't be so pessimistic. :) ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
