Hi again, On Fri, May 4, 2012 at 10:21 PM, Michael B. Brutman <mbbrut...@brutman.com> wrote: > > On 5/4/2012 9:29 PM, Rugxulo wrote: >> 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! > > Grr.
Heheh. > The original Unix didn't have all of the things you list. But the point > was, the original architecture was extensible in a sane way! That's why we still use original UNIX (tm), right? Oh wait, we don't, they've basically rewritten everything dozens of times. It has nothing in common anymore. > You had an > operating system with multiple processes in independent address spaces, The 386 already supported that. > kernel level vs. user space protection, Ring 2, anyone? Anyone? (DPMI easily separated all that.) > a well designed system call API, etc. Not so much. Linux has changed a lot over the years. They've added tons of syscalls. You'd have to check Rod Pemberton's list, hmmm, lemme see if I can quote (part of) it: 56 functions - CP/M 2.2 (39 BDOS, 17 BIOS) 40 syscalls - Linux v0.01 (67 total, 13 unused, 14 minimal, 40 complete) ~120 functions - OpenWATCOM v1.3, calls - DOS, BIOS, DPMI for PM DOS apps. 150 syscalls - GNU HURD kernel 170 functions - DJGPP v2.03, calls - DOS, BIOS, DPMI for PM DOS apps. 206 bytecodes - Java Virtual Machine bytecodes 290 syscalls - Linux Kernel 2.6.17 (POSIX.1) Big difference. And this is why Linux is not a totally stable interface, which is also why it is recommended to stick to libc if at all possible. Sure, I'm not sure how much it changes anymore, but you're "on your own" if you hardcode anything. > Adding a GUI (X windows) was easy - that was an application. Hardly "easy", it's a very very complex beast. > Networking was more integral to the OS, I thought BSD invented TCP/IP? BSD != UNIX (tm). They had a common heritage a hundred years ago but not as much now. > but it used the file descriptor APIs that were already established, > allowing re-use of the existing system call APIs. Dunno, you're the expert there. > Job control was already in the base part of the OS, That's not what I heard. Or maybe it was just that both SYS V and BSD had different ways of doing it, and the BSD won out (in POSIX), not sure. > along with the multi-threading. I don't think that was supported at all for a long time. DEC's Taos was the first to support that (Modula-2+ ??). Oops, Wikipedia says it was Topaz, heh. (And in case it wasn't obvious, Java and Python directly borrowed a lot from Modula-3 [sic], which also had multi-threading built into the language.) http://en.wikipedia.org/wiki/Modula-2%2B > Compare to DOS. Which one?? There are about a dozen. MS-DOS is not the only viable choice, never was. I know most people assume IBM and/or MS, but there are several others (not even counting FreeDOS). > Single address space. No kernel vs. user space protection. On an 8086? 386? Just because it's not in the kernel proper doesn't mean nobody ever did it. Unlike VCPI, which was always ring 0, DPMI indeed often preferred ring 3, which was much saner. This may sound dumb, but DPMI "protected" "DOS" apps from each other, and DJGPP is very very stable. > No ability to keep user space applications from touching > hardware (and trashing it). Sure you can, it's just complex, and there is no easy answer for 100% of uses. > Extensibility encouraged through TSRs in an > ad-hoc manner instead of user space daemons running concurrently. The machines weren't powerful enough. I'm not convinced even 486s could multitask properly. They were just too darn slow and RAM-starved. It's not an accident that hardware keeps getting beefier every year. It's a very difficult task, and people don't like how slow everything is. > It's just not built to be extensible - it reflects the entry level PC > hardware and the needs of home users at the time. It is slightly > extensible, but to continue to bad analogy the foundation of the > building can't support all of the advanced features. Which features? This is what people can't decide. Heck, we can't even decide what cpu. Worst case, everyone assumes 8086, but in reality, nobody assumes that anymore. I know some people still play with old machines, and I have nothing against them, but I'm talking "overall", and for the most part, people using DOS aren't on 8086s, they're on modern machines that (for whatever reason) can't or won't run well for them when using other OSes. I hate to keep pumping DPMI here, but it was a really good solution and widely supported (OS/2, Windows, DOS, Merge, etc). Heck, it was even standardized, twice. It's just a shame that Windows grew less and less interested in keeping it working. And of course, DPMI requires minimally a 286, but 90% of all DPMI stuff is exclusively for 386s. Note that I'm not advocating for making FreeDOS "386" (or 686 or ...) only, just saying, we are allowed to leverage extra features, it's not forbidden! > What is the point here? I'm talking about the structure and base > features of the OSes. Multi-tasking, independent address spaces for > processes, the file descriptor style API, etc. all exist independently > of the compilers and specific applications. We're talking about the > architecture of the building and the foundation, not the curtains. I know you want to pretend it's all standardized and always available, but that's not true. There is no huge continuity available across ten bazillion *nix clones, not even today. They tried to standardize part of it, but that's a mixed bag. > You are making my case for me - PC hardware and DOS reflected what was > available at the time. And as things got slightly better, the new > functions were layered on top of the existing code base, mostly to > preserve backward compatibility. Yes, and what's wrong with that? > Anything that changes that > compatibility might result in a nice operating system, but it would be > hard to call it DOS if it didn't run WordPerfect 5.1 and the various > versions of the Flight Simulator that are out there. Windows didn't seem to mind gradually getting lousier and lousier DOS support! I'm not saying we should wimp out like them. Compatibility is very very important. But a few things could still be fixed, it's not all downhill. > Time out. > > Windows does not use DOS for memory management. Yes it does, just not for "most" stuff. It's all behind the scenes. Would you consider EMM386 part of "DOS" or not? (Yes, I know it mostly avoids that.) Of course you have to do something extra to get at higher RAM. Even the clipboard, I believe, needed to swap to conventional memory. (Even lowly DOSSHELL swapped tasks to conventional memory only, IIRC.) > Windows does not use DOS for semaphores, This I dunno, there are some weird undocumented bits in MS-DOS for various oddball things. So I'm not sure. > task scheduling, etc. Windows does not use DOS for most things. It definitely uses it for file access and shell capabilities, at least Win9x did. Sure, there were add-ons, but you can't say "it's not DOS" just because it's not bundled inside the kernel, can you?? > Yes, those classic versions of Windows used DOS for > bootstrapping and to run DOS applications, but once again it was for > backwards compatibility. Break that compatibility and nobody wants to > talk to you. They *did* break compatibility, just (usually) not on purpose. Yeah, duh, compatibility means a lot, esp. for a closed source atmosphere. I'm surprised that given 2x longer time for DOS apps to emerge, that it's now considered *less* useful than it was back then! And yet we have much *worse* compatibility in Windows (etc.) nowadays. Very annoying. > Win 95 and Win 98 are big pieces of code with lots of function in them. > Once they are loaded and running, DOS is fairly irrelevant. No. They still call DOS a ton behind the scenes. The only reason Win95 came bundled with MS-DOS proper was for marketing, not technical, reasons. It was more or less just a (heavily) upgraded Win 3.1. Seriously, it could (and did) run atop DR-DOS, which (as you probably know) had 0% MS code in it. MS tried hard to fight it, but they literally lost a lot of money in court once that was proven. I have some old floppies with Win 3.0 [sic] on them. It's like two or three. I don't remember if that assumed DOS came with it or not, probably not since they were mostly sold separate. Then I have a bunch of Win95 "upgrade" floppies, and it's like 15 more floppies. Quite a behemoth. If you think you can run Win95 "easily" without DOS, you're mistaken. NT circa 1993 just used too much RAM, so they kept going with Win9x. Actually, I think Win95 was said to run in as little as 4 MB (painful), even on old 386s. But WinXP needs minimum something like a Pentium with 64 MB of RAM. I've run XP atop a P4 (Compaq, 2003 mfgr'd) with 128 MB, and it wasn't really comfortable except for very very light use. Opera worked tons better for very light browsing than Firefox. NTVDM worked fine because most of my favorite DOS apps (even DJGPP) didn't need too too much. But it's a stretch to call XP "lean". Anyways, what was my point? I guess my point is that RAM was always very expensive (and there were a few RAM shortages over the years), hence why push NT when nobody will buy it or can't run it well? Heck, Vista and 7 require at least 512 or 1 GB of RAM just to barely function. So MS didn't push NT until RAM got cheap enough. (Though you could arguably say there was little else they could do with an aging codebase.) Software is heavily tied to hardware. You can't just throw anything you want out there, even if it is (allegedly) "better" or "improved". Sometimes you have to live within your means. The fact that (weird) people are starting to "need" more than 4 GB means 64-bit is getting quite popular, there is no other choice (esp. as MS refuses to support PAE), which means all new drivers (yet again) with a new ABI (incompatible with SYS V, natch). > No, DOS really doesn't multi-task well. DOS doesn't have a concept of > networking. DOS isn't keeping up with BIOS changes, USB, and other > devices that require something more advanced than the original device > drivers we are carrying around. DOS doesn't do 32 bits - DOS extenders > do, in a hacked up kludgey way. No concept of networking? MS NET? Redirector thingamabob? I'll take your word for it, you're the resident expert here for that. 32-bit? You know you can use 32-bit instructions even in 16-bit code, right? You don't need pmode at all, but it does add an opcode override here or there. To use 32-bit segments, you (more or less) need pmode. And DPMI is far from a kludge, it explicitly (esp. in 1.0) uses the 386 in the way it was designed. V86 is not a kludge, and neither is the 386. DPMI is (was?) very popular and stable and well-used. > So where should we spend our time? Dunno. > Trying to recreate all of the modern > conveniences of Linux (32/64 bit support, multi-tasking, networking, > modern device support, etc.) Not all at once, no, but rewriting some things wouldn't necessarily hurt. > or writing some compatibility layer code so > that we can boot our existing OS that runs our existing code? Dunno, easier said than done. > A lot of the DOS applications that we are using date back quite a few > years. Dunno, what's the oldest apps you have? I don't use a lot of apps from the '80s. But I don't need (or want) a lot of word processing, spreadsheet, etc. My uses are more random, not specific requirements. > They need refreshing, and given that a lot of them don't have > source code available it is not going to happen. They don't need refreshing, necessarily, unless they are broken. Lack of source code, fine, but it's very difficult to port Linux-era stuff back to DJGPP (hi Ralf). > Case in point - my > TCP/IP code. Not to throw mud on the existing networking code out > there, but it was pretty old, pretty buggy, and pretty slow. A few > modernized applications can go a long way to keeping DOS useful for people. I have no problem with how DOS works today. I'm not ashamed of it. It works great, and I use it. However, if you want me to say that, "No, we don't need to rethink some things", I can't say that. I don't personally "need" 64-bit or SMP or multitasking to be happy with DOS. Some things are just big dreams, who knows what will happen in the future. (Ask the RDOS guy at OpenWatcom's forum, he's doing some interesting stuff.) But there are still a lot of little things that could be better, IMO. We don't need "another Linux", but (in theory) it wouldn't hurt to support more modern hardware (even if it's difficult or practically impossible, I can dream can't I?). > Once again, where should we focus scarce resources - keeping what we > have running and refreshing some of the apps, or trying to do a complete > redesign from the ground up and re-inventing a lot of code that has > already gone into Linux? We're not redesigning anything. If anything, we just want more robust, more stable, more useful. I'm not saying throw anything away. Yes, refresh all you want, and I'm actively for it (and already done various silly things over the years). I'm just saying ... for instance, would it kill us to support another file system? Would ext2 support be horrible? Is that too much of a dream? Or is that also "reinventing" or wasting time? Linux has 40+ file systems, but I'm somehow silly for suggesting we get one more?? > Anybody can go off and start another SourceForge project. There are > lots out there. But we need another 32 bit "DOS like" operating system > that doesn't run the existing applications like a hole in the head. Nobody advocated for that. I don't care for specific 16-bit or 32-bit or 64-bit at all. It's not about bits, it's about apps. If it works, it works. I'm not arguing change for change's sake. Nor do I believe the hype that 64-bit (vs. 32-bit) is always superior (or 32- vs. 16-bit). I'm just saying, no reason we can't "extend" *some* stuff. > Like it or not, the path for the future is going to be running DOS > inside of virtual machines hosted by an operating system that is kept > current and up to date. Maybe. Though some people think the future is tablets or smartphones. Others think the web (HTML5 + JS) will be the new "platform". Others think netbooks or ultrabooks. In short, nobody knows. Maybe it's all those things. You can't predict the future. DOSBox has already achieved quite a bit, and it's not even real DOS! But we all know it has some penalties (lacks some compatibility, slow as dirt). It's great, it's stable. So nobody can ever fix or improve it? It's frozen forever?? You think there's no room for improvement there?? Gog.com (and a few others) sells commercial software with it bundled, for freak's sake. > It's easier to keep the emulators going than it > is to keep up with all of the device driver and hardware changes that we > are going to need. It shouldn't be that hard. It's just ridiculous (or maybe I'm naive) to think that we have to recompile software across the *exact same x86 machine* for different OSes! Even across 32-bit OSes. It's very silly. And Java is not the answer for various reasons. Similarly for drivers, how many different ways do you have to do the same thing? I know it's 10x more complicated than that, but in theory you don't want to have to rewrite for every minor OS revision, whether DOS or otherwise. > Virtual environments are going to look pretty > attractive when you can't boot a machine with DOS running on the bare > metal in a few years. Obviously, esp. if BIOS dies (like they seem to want). But will there be a suitable alternative, or do they want to split all the developers into ten bazillion other camps (already started)? You shouldn't kill something without something to replace it, but they seem intent on doing that. Speaking of "kludges", welcome to the modern big three OSes, a bunch of server OSes with heavy GUIs and very high RAM requirements. Yeah, they're perfect, nothing needs to ever change ... oh wait, new upgrade available, only $99.95, what a bargain! Look at all those shiny new features! (repeat ad infinitum) I guess it's not "Windows" anymore now that it runs on ARM. And it's not "Linux" anymore since it runs on a tablet. And it's not "Mac" anymore now that they (years ago) switched away from 68000 to PPC to x86, Carbon to Cocoa, Objective-C 2.0, etc. etc. etc. ------------------------------------------------------------------------------ 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
