Hi, On Fri, May 4, 2012 at 8:17 AM, Michael B. Brutman <mbbrut...@brutman.com> wrote: > > Analogies are a slippery slope. > > By many definitions, DOS is not even an operating system. It is a > device driver, file system, and rudimentary memory manager that stays > resident while a user program is running. When the user program stops a > simple command shell replaces it.
No reason that more things can't be improved. As it is, most things are add-ons to that via TSRs or shell improvements or drivers or 3rd party tools (e.g. memory managers). If you unified more things inside the kernel itself (even if keeping them as loadable modules), it would be more flexible, IMO. > BSD comes from something that is more substantial in nature - Unix. > Linux might not be Unix, but it was heavily influenced by it and has all > of the same major design points and attributes. Wasn't BSD a spinoff of the original AT&T UNIX (tm)? POSIX was a compromise, and VAX was where 32-bit and virtual memory became popular. 64-bit came later with various things, including DEC Alpha. In other words, original UNIX (tm) didn't have all the GUIs, multi-threading, 64-bit, job control, networking, tons of memory, etc. that we take for granted today. Heck, the PDP was 16-bit! > The bad analogy to use here would be that Unix and the variants endure > because the foundation of the building was good. You see anybody still writing K&R C? Using the ed editor? Even plain vi has been replaced by huge additions like VIM or VILE. GNU prefers Emacs, which alone is bigger than the first UNIX (tm). Nobody uses a.out or a.outb anymore, only ELF (or barely, COFF). The original Bourne shell is not supported by most as it's not POSIX compliant (as most assume Korn or Bash extensions). So a lot has changed. > In comparison, DOS is > the hut out in the woods - primitive and good at the time when you > needed shelter, but it was never designed to compete with full operating > systems that do multitasking, demand paging for memory management, > decent network stack hooks, device driver/module support, etc. The original PCs only had like 64k RAM! I know you of all people know that. Try porting Linux to that. Even ELKS can barely do anything useful in 640k. Compilers (and authors) just aren't dedicated enough to waste hours trying to cram things into small amounts of RAM. So the increase continues. And when your kernel demands 128 MB or more just to boot up, you have no reason to use uber lean and mean things like DOS (though you can barely use anything else either these days, sheesh). It was the 286 that had hardware support for task switching, not the 8088 (though a limited 8086 Desqview version existed, right?). You did have device drivers for DOS, but they too were limited in RAM and features depending on which hardware extensions you had. Demand paging? Did even the 286 have an MMU? Can't remember, doubt it. That's why EMM386 exists at all. Face it, the 386 is a monster machine. It doesn't make everything else crap, but it does support a lot of things. But so-called "386" OSes these days ... ugh. Even 386BSD could run in a handful of RAM originally. Linux too used to run in 2 MB. Well not anymore, sadly. GCC alone probably won't work anymore with less than 256 MB without heavy paging. And BTW, networking ... what networking? In 1981? At best you could maybe dial up a BBS, heh. Those were fun (during mid '90s for me), and they were well-supported for DOS, but that was a far cry from what we have today (as you know). You can't blame DOS for not supporting what didn't exist. > Windows is not a relative of DOS. Even something primitive like Win 31 > or Win 95 basically looks at DOS like a boot loader. They are not in > the same league. Both of those 100% relied on DOS to do various calls behind the scenes. They would not run without DOS. It's already been proven that Win 3.1 could run atop DR-DOS (and even run Win95 GUI with a small, proprietary hack). There is more stuff going on, yes, but it's still heavily dependent on DOS proper. Was it perfect? No, but it worked. Win 3.0 was originally going to be a DPMI client, I think, but that idea was later abandoned. However, internally their Win16 apps (not counting the very few that were 8086-based, which was soon abandoned) used DPMI themselves! BTW, the bugs in NT's DPMI were never fixed by MS (e.g. for Quake 1) because they didn't intend NT (at that time) for home users or games. Of course that target (but without bugfix) was changed later with Win2000 (added FAT32, LFNs) because they decided to abandon Win9x. When WinXP came out for home users, they officially declared DOS dead (as it didn't use DOS at all at bootup, only a patched v5 version for its buggy old NTVDM). > Here is the crux of my argument - if you need modern hardware support > and modern features, you probably should use something that is current > and maintained. Everything fades, so you can't rely on anybody, sadly. DEC was long ago bought out by Compaq (which got bought by HP), for instance. Novell bought and sold Digital Research, which spun off a bunch of times. Even your beloved IBM no longer messes with home computers directly as it spunoff to Lenovo. It's quite a brittle industry. > It is not feasible to "grow" DOS to do all of these > other things; It's already been done, more or less. > what would be left would be something that barely runs any > DOS applications and doesn't do all of the new stuff well either. There > is not enough demand or qualified people with free time. Probably not enough demand, no, but qualified people always find a way to extend Linux. Nothing is stopping those same people (or similar) from improving things. If I said, "Linux will never support xyz", I'd be short-sighted and probably proven wrong. But if I say the same about FreeDOS, somehow I'm being fair? Why are people so stubborn? > Want to keep DOS relevant? We need applications ... today. Yes, but our bigger problem is the entire architecture is dying. Not x86, that's thriving big time, but just 16-bit in general. They want to replace the BIOS with UEFI, and who knows how long before cpus no longer support legacy mode. VT-X is better than nothing, I guess, but that isn't universal yet. > (Different topic: In an earlier note you misinterpreted me. I said you > could re-implement DOS with the int 21 interface easily, and some well > behaved code might even run. But if you don't have the direct access to > all of the hardware, TSRs, device drivers, segmented memory tricks, > etc., it's not really DOS anymore - it would run so few applications.) VMs are too slow and buggy. Maybe we should focus on improving those (VirtualBox, Bochs, QEMU, DOSBox). But I doubt that will be easy. Long story short: you think the answer to everything is "more apps"?? DOS already has 30 years of apps, and it didn't phase MS (of all people) one bit. Win64 still doesn't support it, they didn't even try (and yes, they do know how). DOSEMU isn't in most distros at all. DOSBox is only treated as a lark for rare games. So much good stuff seems to be thrown out the window. :-( Could we use more apps? Sure. Would I be willing to help? Of course, in whatever little way I can. But will it solve anything long-term? No. The kernel isn't the problem (though it can always be improved), it's the ecosystem, the world, developers, everything has changed so much. Everybody has their own (incompatible) solutions to everything, which sadly often doesn't involve FreeDOS at all, not even when appropriate. Saying we can't fix or improve anything is very pessimistic. No, I don't see any technical reason to drop compatibility, and I don't want anybody to do so, but I don't necessarily think we should rest on our laurels. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
