"Hadron" is a liar.
in [General Linux]
|
Prev: NYC LOCAL: Tuesday 3 August 2010 NYLUG: Pharo Smalltalk, Python, and More
Next: +++ NFL Jerseys On Sale at www.ajerseys.com
From: Ezekiel on 3 Aug 2010 14:49 "Aragorn" <aragorn(a)chatfactory.invalid> wrote in message news:i39gjb$qe8$1(a)news.eternal-september.org... >>>>>> --- "NT offered NTFS and ACLs, but most of the security hooks in >>>>>> Windows and most of the memory management is ... simply an updated >>>>>> version of the one in Windows95/98/ME" >>>>>> >>>>>> Windows 95 was released in 1995. Win98 was releaed in 1998. >>>>>> Windows NT was released in 1993. Did they use a time machine to >>>>>> use 1998 code in an OS that was released in 1993 ???? >>>>> >>>>> The version of Windows NT which was released in 1993 used the same >>>>> modified winkernel, except that it still had the GUI of the old >>>>> Windows 3.x for DOS. And as of Windows 3.1 - not 3.0![*] - that >>>>> winkernel would for most part remain the same, the sole difference >>>>> being that more parts of it were being ported to 32-bit, whereas >>>>> they used to be 16-bit protected mode code. (Not all of it was >>>>> converted to 32-bit, though.) >>>> >>>> What on earth are you talking about? You claimed that Windows NT >>>> winkernel - "is simply an updated version of the one used in >>>> Windows95/98/ME" >>> >>> Yes. And I have just explained that the one used in Windows 95/98/ME >>> was in fact in itself only an updated version of the one used in >>> Windows 3.1 and 3.11. And those two DOS-based Windows versions were >>> already around *before* Windows NT was released. In fact, that's why >>> the very first version of Windows NT bore the version number NT 3.1 >>> rather than NT 1.0. >> >> So which is it??? One side of your mouth is claiming that the NT >> kernel was lifted/stolen from VMS by Cutler [... > > Yes, that is correct. > >> ...] and the other side of your mouth is claiming that it's based on >> the Windows 3.1 kernel [... > > No, that is *not* what I was saying. And this is exactly *why* I have > elaborated on the design of the NT-based Windows versions earlier on. > > I have specifically stated that all current versions of Microsoft > Windows - all of which are based on NT, as you well know - use a > *compound* kernel, i.e. there are two separate entities both running in > kernelspace - or in layman's terms: in the highest privilege ring of > the underlying microprocessor, i.e. ring 0 - and that one of those two > is the NT kernel (which is based upon VMS) and the other one is the > winkernel - I think it's called win32, but in the 64-bit versions it'll > probably have been renamed to win64 - which runs atop of the NT kernel. Huh??? Perhaps it's time for a link or something to clarify what you're trying to say. I've never heard of a "compound kernel" being used anywhere in NT. There's the kernel itself and then there are various *subsystems* such as the Win32 subsystem and at one time the Posix subsystem and OS2 subsystem. > It is this latter winkernel - win32 or win64, whatever it's called - > which is basically still the same as in Windows 3.1, but which has been > adapted to run on top of NT instead of on top of DOS. No. But if you'd like to provide some sort of evidence or a decent example then I'd reconsider. >> ...] which is laughable. (NT was 32-bit, pre-emptive, ran on MIPS, >> Alpha, x86, i860, etc). > > Yes, it would have been laughable if that was what I have said, but it > is *not* what I have said, and even if my above explanation (once > again) is not good enough for you or any other Microsoft advocate, then > the thread of this conversation is still readable in your newsfeed. > > I *did* elaborate on this. And that's why I said that you have either > not read it or that you have failed to comprehend that elaboration. > >> And the reason that the initial release of NT was 3.1 and not 1.0 has >> nothing to do with it being based on (16-bit) Windows 3.1. It's >> because the GUI was nearly identical to the GUI of 16-bit Windows 3.1. > > Not just the GUI. See, the fact of the matter is that Windows in itself > as a design - which includes the win32/win64 kernel but not the NT > kernel - *is* basically nothing but a GUI that attempts to be more than > just a GUI. Where exactly are you getting this information from. It's just wrong on so many levels. > And _that_ is where the problem lies, because that is a legacy _of_ the > old Windows 3.1 for DOS. Microsoft has held on to that design, instead > of throwing the operating system-level functions in the Windows > component away and delegating that to the underlying NT kernel. And > they have done that, yes, to a certain extent, but by far not as much > as would actually have been needed to make Windows into a stable, > secure and true multi-user platform. Windows-NT is stable and it is a multi-user OS and has been since day #1. It supports multiple telnet clients, or SSH clients and with NT Server it supports multiple GUI clients as well (via RDP). > Or let me try and put this another way: You've got two kernel > components, both of which run in kernelspace, i.e. in the highest > privilege mode of the processor. One component (NT) is specialized > enough to allow for a powerful multi-user operating system, given that > it's based upon VMS, and the other component is a kludgy leftover from > when the whole of Windows was running as a memory extender annex GUI on Instead of hype and rhetoric how about a specific example of how this "kludgy leftover" is doing what you're trying to claim it does. > This is quite a different organization of the way the user is presented > with a graphical user interface from how it is done in Windows. And > given that Windows NT is based upon VMS, which itself also could use an > X Window System, this is how Microsoft *should* have done it. But they > didn't, because of backwards compatibility and because they wanted to > make as little changes as possible to the Windows concept. It was a design decision. Fact is that X was terribly slow at the time and it was a decision based on performance. > And so, instead of going this way, they simply ported the existing > Windows design to the NT kernel as if it was just another version of > DOS. Given that the Windows versions which were available as > applications/environments for a separately sold MS-DOS/PC-DOS package > also doubled as memory extenders and (cooperative) multitaskers for > DOS, the concept of making the underlying parts of Windows into a > kernel component was already there. Hint... the 'video subsystem' is NOT the entire design of Win-NT. And the MS-DOS "memory extenders" have absolutely nothing to do with Win-NT which runs in a flat 32-bit (now 64-bit) address space unlike MS-DOS and its segmented memory model. > The foundations for this were even already laid from before Windows 3.0, > but it wasn't until Windows 3.1 that this winkernel really became > elaborate. And so, when Microsoft decided to develop Windows NT, this > is what they built upon, You're simply repeating yourself with no specific examples or citations/links. The closest you've come is to complain that MS didn't implement an X-Windows like protocol for the video subsystem. Whoop-de-dooo.
From: Aragorn on 3 Aug 2010 19:33 On Tuesday 03 August 2010 20:49 in comp.os.linux.misc, somebody identifying as Ezekiel wrote... > "Aragorn" <aragorn(a)chatfactory.invalid> wrote in message > news:i39gjb$qe8$1(a)news.eternal-september.org... > >> [Ezekiel wrote:] >> >>> So which is it??? One side of your mouth is claiming that the NT >>> kernel was lifted/stolen from VMS by Cutler [... >> >> Yes, that is correct. >> >>> ...] and the other side of your mouth is claiming that it's based on >>> the Windows 3.1 kernel [... >> >> No, that is *not* what I was saying. And this is exactly *why* I >> have elaborated on the design of the NT-based Windows versions >> earlier on. >> >> I have specifically stated that all current versions of Microsoft >> Windows - all of which are based on NT, as you well know - use a >> *compound* kernel, i.e. there are two separate entities both running >> in kernelspace - or in layman's terms: in the highest privilege ring >> of the underlying microprocessor, i.e. ring 0 - and that one of those >> two is the NT kernel (which is based upon VMS) and the other one is >> the winkernel - I think it's called win32, but in the 64-bit versions >> it'll probably have been renamed to win64 - which runs atop of the NT >> kernel. > > Huh??? Perhaps it's time for a link or something to clarify what > you're trying to say. Sorry, I do not collect links on the specifics of Windows - as an ostensible Microsoft Windows advocate, that should be *your* job instead - but I will expound upon this subject in my comments below your next statements. > I've never heard of a "compound kernel" being used anywhere in NT. > There's the kernel itself and then there are various *subsystems* such > as the Win32 subsystem and at one time the Posix subsystem and OS2 > subsystem. Okay, you have now named them "subsystems", which *is* actually what I was talking about - and if I'm not mistaken, that is also the nomenclature that Microsoft themselves use in order to refer to these components, albeit that the term "subsystem" is generally used in a more comprehensive manner, i.e. in reference to both the kernel and userspace components of such a subsystem. But you're right, perhaps using the term "subsystem" is better verbage. So here goes... You have just referred to various subsystems in the Windows NT, which were all still part of NT 4.0, which is the NT version I have been using between late 1997 and late 1999. These subsystems were... ° the Windows-native (win32) subsystem (and now also win64) ° the OS/2 subsystem, which was only a 16-bit subsystem and thus only compatible with OS/2 1.x applications; OS/2 1.x was the only OS/2 generation jointly developed by IBM and Microsoft, and OS/2 2.x - which was 32-bit - was developed solely by IBM and was thus not supported by Microsoft ° the POSIX subsystem, which - if memory serves me right - was also only a 16-bit subsystem; a more recent re-implementation of this subsystem is the "Services for Unix", which I believe is a 32-bit subsystem All three of the above are/were comprised of a kernelspace component and a userspace component. So while the NT kernel itself - NTKRNL.EXE? - was the bottom component of the kernel, the various subsystems added an additional kernel layer, specialized for each of the three environments. The win32 (and now also win64) kernel component is the winkernel I was talking of, and is what Windows uses for most of its kernel tasks, even though the underlying NT kernel could do all of those things as well, and even better. >> It is this latter winkernel - win32 or win64, whatever it's called - >> which is basically still the same as in Windows 3.1, but which has >> been adapted to run on top of NT instead of on top of DOS. > > No. But if you'd like to provide some sort of evidence or a decent > example then I'd reconsider. I have just confirmed that what I was talking about is the same thing as what you call "subsystems". Or at least, at the kernel level, because naturally, these subsystems also have their userspace components. >>> ...] which is laughable. (NT was 32-bit, pre-emptive, ran on MIPS, >>> Alpha, x86, i860, etc). >> >> Yes, it would have been laughable if that was what I have said, but >> it is *not* what I have said, and even if my above explanation (once >> again) is not good enough for you or any other Microsoft advocate, >> then the thread of this conversation is still readable in your >> newsfeed. >> >> I *did* elaborate on this. And that's why I said that you have >> either not read it or that you have failed to comprehend that >> elaboration. >> >>> And the reason that the initial release of NT was 3.1 and not 1.0 >>> has nothing to do with it being based on (16-bit) Windows 3.1. It's >>> because the GUI was nearly identical to the GUI of 16-bit Windows >>> 3.1. >> >> Not just the GUI. See, the fact of the matter is that Windows in >> itself as a design - which includes the win32/win64 kernel but not >> the NT kernel - *is* basically nothing but a GUI that attempts to be >> more than just a GUI. > > Where exactly are you getting this information from. It's just wrong > on so many levels. It is not wrong at all, but perhaps you could be paying a little bit more attention to what I'm saying and putting a little less effort into your attempts at reading what I am not saying at all. As for where I have gotten this information, bear in mind that I am talking of my experiences with Windows - and my being subscribed to a local (hardcopy) computer magazine that dealed with this kind of information - from back at the end of the 1990s. I have also extensively discussed these subjects with people who were in the know - back at the time, one could subscribe to a certain service at Microsoft and you would then be sent the source code (under a read-only license) for various Microsoft products, including the entire NT-family of operating systems. Next to that, I pick up something here and there from technical websites, but only if I happen to come across it by chance. I don't actively go hunting for this information, since it is neither my duty to know these things, nor within my interest to monitor Microsoft's technical evolutions. Like I said, I'm not the Microsoft Windows advocate here. That would be you instead. (Speaking of the debate between you and I, of course - I'm not including anyone else subscribed or not subscribed to either or all of the crossposted newsgroups.) >> And _that_ is where the problem lies, because that is a legacy _of_ >> the old Windows 3.1 for DOS. Microsoft has held on to that design, >> instead of throwing the operating system-level functions in the >> Windows component away and delegating that to the underlying NT >> kernel. And they have done that, yes, to a certain extent, but by >> far not as much as would actually have been needed to make Windows >> into a stable, secure and true multi-user platform. > > Windows-NT is stable [... If that were the case, then how come so many people know what a "blue screen of death" is, and why did it even get to be called that? > ...] and it is a multi-user OS and has been since day #1. No, that is not correct either. The *NT* kernel supports multi-user functionality, but the Windows subsystem does not. Well, there is a very limited multi-user functionality in the Windows subsystem now, but this was again bolted on afterwards, and not even by Microsoft itself. This added-on functionality was actually developed by Citrix Systems and originally sold as Citrix Metaframe, but Microsoft then took a license on this and incorporated it with the server edition of Windows NT, and named it Windows NT Terminal Services. But an add-on it was and still is, since it didn't even exist in Windows NT 4.0 Workstation, Windows 2000 Professional and Windows XP Home Edition. A modified version of it was available via Windows XP Professional Edition, though, via the Remote Desktop Procedure (RDP) which you are referring to farther down, but the use of RDP precluded the "fast user switching" option. You had to use one or the other, but you could not use them both at the same time. > It supports multiple telnet clients, or SSH clients and with NT > Server it supports multiple GUI clients as well (via RDP). See above. This functionality was *added* *to* certain versions of Windows as part of the Windows subsystem - again, because the NT kernel does and already did support it, but Microsoft has opted to do this kind of stuff via the win32/win64 subsystem instead, with just a few hooks into the underlying NT kernel layer - and it was originally developed by Citrix Systems and sold as Citrix Metaframe. >> Or let me try and put this another way: You've got two kernel >> components, both of which run in kernelspace, i.e. in the highest >> privilege mode of the processor. One component (NT) is specialized >> enough to allow for a powerful multi-user operating system, given >> that it's based upon VMS, and the other component is a kludgy >> leftover from when the whole of Windows was running as a memory >> extender annex GUI on > > Instead of hype [... I don't what you could possibly interpret as hype in what I have written above, since I'm strictly talking of technical matters. > ...] and rhetoric how about a specific example of how this > "kludgy leftover" is doing what you're trying to claim it does. That is what I've been trying to explain to you all along, and I like to think that my English is sufficiently good so that you would understand it. In fact, another poster has already attempted to clarify to you what exactly I meant, so that means that this other poster (1) was able to ascertain what I was talking about and (2) also has knowledge about the subject I was referring to. I also don't quite see my explanations as a rhetoric, given that it was my intent to clarify something to you which you yourself did not seem to understand. >> This is quite a different organization of the way the user is >> presented with a graphical user interface from how it is done in >> Windows. And given that Windows NT is based upon VMS, which itself >> also could use an X Window System, this is how Microsoft *should* >> have done it. But they didn't, because of backwards compatibility >> and because they wanted to make as little changes as possible to the >> Windows concept. > > It was a design decision. Fact is that X was terribly slow at the time > and it was a decision based on performance. Terribly slow? I'd say that X is actually pretty fast and pretty lean, if you compare the hardware requirements for Vista - I'm not aware of the requirements for Windows 7 - with the hardware requirements for any GNU/Linux distribution that could already do far more graphics-wise than Vista before Vista was released. You needed half the system RAM, half the video RAM, and a processor that was also only half as fast. And then it still beat Vista like a hare racing a tortoise. I would rather think that Microsoft did it the way they did it for the reasons I've mentioned, *plus* that they wanted to do it in a proprietary way, of course. I'm not sure on the status of any open source X11 implementations during the development of the first versions of Windows NT, but going the open source way was not exactly in line with Microsoft's corporate strategy, and taking out a license on a proprietary implementation of the X Window System would have been too costly and thus too limiting in terms of the profit margin. It would have been a bad strategy from the corporate point of view. >> And so, instead of going this way, they simply ported the existing >> Windows design to the NT kernel as if it was just another version of >> DOS. Given that the Windows versions which were available as >> applications/environments for a separately sold MS-DOS/PC-DOS package >> also doubled as memory extenders and (cooperative) multitaskers for >> DOS, the concept of making the underlying parts of Windows into a >> kernel component was already there. > > Hint... the 'video subsystem' is NOT the entire design of Win-NT. Oh, I know that, and I'm not even talking of the video subsystem[*] but of the win32/win64 subsystem, of which the userland and part of the kernel in some (but not all) of the NT-based Windows versions are so tightly integrated with the graphical user interface that it's virtually if not entirely unseparable. [*] The video subsystem is only a small component of any GUI. > And the MS-DOS "memory extenders" have absolutely nothing to do with > Win-NT which runs in a flat 32-bit (now 64-bit) address space unlike > MS-DOS and its segmented memory model. Again you are demonstrating that you have not properly read what I have been attempting to explain to you. I have never said that there were any DOS extenders in Windows NT, nor have I ever contested that Windows NT runs in a flat 32-bit or 64-bit address space. Okay, let's rewind a bit here. DOS did indeed have a 16-bit segmented memory model, but that was not the only property of DOS. DOS was also designed for a 16-bit processor with such a 64 KB segmented memory model and which only had a 1 MB address space, of which the top 384 KB was used for the mapping of ISA peripherals, similar to how PCI devices also have an address space between the 3 GB and 4 GB barriers on 32-bit and 64-bit systems. And in addition to that, this processor, the Intel 8086, also did not have any privilege rings, so everything running on that processor had all access to the hardware. Since DOS was developed for such a processor, every application that ran atop of DOS would also have full privileges and full access to everything, and effectively became the operating system once it was loaded into memory. That was in fact what a "disk operating system" was intended to do, i.e. it was an executable loader, not a real operating system. Then came the Intel 80286. This processor had a mode which was compatible with the 8086 (and the slightly slower but functionally equivalent 8088), and this was called "real mode", because all memory addresses accessed from within this mode are the real addresses, i.e. there is no remapping or address translation going on. This real mode still exists in all x86-32 and x86-64 processors today, and at machine power-up, this is the mode that is active. The other mode of that 80286 processor was still only 16-bit and also still used a 64 KB segmented memory model, but it was a quite different mode, with privilege separation, in which an operating system kernel could access and assign the memory to applications, without that the applications themselves would be aware of where in memory they were being loaded. This mode was called protected mode, and it also had hardware support for threads, and thus for multitasking. The soon therafter released 80386 would extend this protected mode to 32-bits (for both addressing and instructions), and as such, introduced the flat memory model. Now, let's take a jump to Windows 3.0 and 3.1, because that's where it started getting interesting. See, Windows 3.0 had three modes - "real mode", "standard mode" and "386 enhanced mode" - of which the former was dropped in Windows 3.1. In "standard mode" and "386 enhanced mode", Windows itself would be not just a graphical user interface, but would run in protected mode for a lot of what it was doing - more so in Windows 3.1 than in 3.0 - because Windows also became a DOS extender. It added cooperative multitasking, and it was capable of accessing a great deal more of memory than DOS, thanks to the protected mode of the underlying processor. Now, you may find all of this boring and you may think once again that I'm beating around the bush, but I'm not. I am explaining all of this to you so that you would be able to follow where I'm going with this. So, to come back to what Windows was already doing in its 3.0 and 3.1/3.11 guises, we could say that Windows was taking over from DOS at "being an operating system". And when Windows 95 was introduced, that is still what Windows was doing, but with parts of the code extended to the 32-bit level - Windows 3.0 and 3.1/3.11 were still 16-bit and only used some 32-bit code on an i386 or better processor for virtual memory management and access to the swapfile, bypassing the DOS I/O protocols, which were expensive (in terms of the processor having to drop back to real mode before it could execute the I/O operation). So what you have here, is basically the whole Windows subsystem. In Windows 95, it was a blend of 16-bit and 32-bit protected mode code, and thus it would not run on an i286 anymore, while in Windows 3.1, it was still capable of running on an i286 in "standard mode", albeit that it paid off to run it on an i386 because of the ability to multitask DOS applications via the i386's "virtual 8086 mode", and because of the better memory management and swapfile access. Now, with all of this in mind, let's jump back in time to before Windows 95 was released, and to when Windows NT was being developed. So you already had a complete Windows "subsystem" in the form of Windows 3.1/3.11. And so what Microsoft did was conceive Windows NT as a modular platform, with the underlying NT kernel being the basis for multiple "personalities", or subsystems, if you will, and each subsystem "doing its own thing". And so they adapted the existing Windows 3.1 subsystem - which still ran atop of DOS, although it wasn't using DOS for much anymore - to the underlying 32-bit NT kernel. The NT kernel itself would be used for process scheduling and memory management, and as a hardware abstraction layer. The NT kernel layer - which is actually a kind of microkernel - also offered security hooks, and these were taken advantage of by the NTFS filesystem in the form of ACLs, provided that this filesystem were used of course, because that was not a requirement for the operation of the system; Windows NT would just as happily run off of a FAT16 filesystem - FAT32 was not supported yet until Windows 2000. So there was some kind of privilege control already in terms of who could do what on the system, but this was not fully taken advantage of, because Windows NT - and I am emphasizing the word "Windows" in that sentence - was not intended as an operating system for concurrent multi-user access. Instead, it was conceived as a platform for sequential multi-user operation, meaning that it could accomodate multiple users, as long as there was only one of them logged in at a time. (Use as a fileserver is an entirely different thing and cannot be considered a concurrent multi-user environment.) Now, ask yourself why Windows NT would be just as happy booting and running off a FAT16 filesystem. The answer is evident, i.e. the security subsystem was a bypassable layer. NT - and I am now talking of the NT microkernel which was written by Dave Cutler, not of the Windows NT operating system as a whole - didn't care about what filesystem it was on, because its only job with regard to filesystems was to provide the security hooks via the access control lists. And the Windows subsystem could use such access control lists, but did not require them either, since it was basically nothing but a port of the old "Windows 3.1 for DOS" subsystem to the underlying 32-bit NT microkernel, and so most of the kernel functions - except for memory management and certain types of process management, low-level hardware access and the optional security layer - were still handled by the Windows subsystem, which as the result of its adaptation to the underlying NT kernel was upgraded to what you would now call win32 (and the win64 equivalent). Although the following analogy is not entirely correct, one could perhaps view the underlying NT kernel - and it was also described in this very same way by Eric Funkenbusch, whom I'm sure you're quite familiar with - as a kind of hypervisor, with each of the subsystems you've described - albeit that the OS/2 subsystem was removed in Windows 2000 and that the POSIX subsystem was also removed for Windows XP, but then readded again as an optional add-on in Windows 2008 Server - being their own "operating system", comprised of a kernelspace component and a userspace component (for the Windows "personality" and in part for the OS/2 "personality", but the POSIX subsystem on the other hand only provided for a very limited kernelspace component with an ABI - it didn't have any filesystem support, nor did it have any POSIX-compatible shell, or at least, not in NT 4.0 and earlier). I know this has been a very long and technical read, but apparently I had to spell it out like this to you before you could understand what I was talking about, and although it may be somewhat of a stretch in confidence, I am now hoping on whatever honesty you may have within you to recognize and acknowledge what I was trying to say in the first place. For once, we were getting into the technical aspects without (too much) resorting to namecalling, and as I have stated before already, I will not walk away from a civilized debate. That doesn't mean that I cannot be proved wrong - nobody's infallable - but I am quite convinced of the veracity of all that I've written about this subject so far, based upon all the stuff I've read over the years with regard to operating system technology, and at one stage, when I was using NT, Microsoft technology as well. (Not for the sake of any advocacy - I was by far not into that in the two years that I was using NT, except maybe for the fact that I was encouraging people to try NT instead of Win95/98, the stability of which they kept on complaining about - but for the sake of technical interest and broadening my knowledge.) As I have told you (and others) many times already, Windows NT was a compromise for me, because I came from 32-bit OS/2 and I had actually wanted a UNIX system - NeXtSTeP, to be precise - but proprietary UNIX was incredibly expensive for private use, and I had no internet and GNU/Linux was still pretty much in its infancy - we're talking 1997 here. OS/2 was as good as dead in terms of support from independent software vendors, and I realized, with UNIX out of the equation due to the financial implications - we're talking USD $~900 for the "simple" enduser license to NeXtSTeP and more than twice as much for the developer license (which gave you all the source code as well) - that if I wanted a platform that had a sufficient offer in application software, then I would have to go with Windows. But coming from OS/2, I did not want to go with the DOS-based Windows versions, so I opted for NT 4.0 Workstation instead. And that was quite a daring thing to do back in those days, because apart from Microsoft itself, virtually no other software vendor was offering NT-specific software, and I had a hell of a time trying to get NT to play nicely with my videocard at the time, which was one of the first ATi AGP cards - "Rage Turbo" or something; I don't exactly remember what it was called, but I do remember that I needed Service Pack 3 to get it to work, and the boxed NT version I had was only SP 1, so I had to order said Service Pack from Microsoft. Similarly, it was also not easy to get NT to work with my soundcard. There was no such thing as autodetection of my hardware in NT 4.0. Then, in 1999, I came across GNU/Linux - Mandrake, as a shrinkwrapped box in a software shop, because I still didn't have any internet - and after I had installed that, I realized that I now had what I had in fact been wanting for back in my last days of using that old 80386 machine with OS/2. I now had a UNIX(-like)/POSIX operating system, and the philosphy of Free & Open Source Software appealed to me very strongly. My bottom line here is that I did not ditch Windows because I didn't like it - well, I never did fully like it, since it was not a UNIX/POSIX, but it was okay enough for my needs back then, and it was certainly a lot better than the Win95/98 used by my friends - or because it supposedly crashed on me, or because of viruses or intrusions or any of such things. I did not hate Windows. I was not looking to escape from it. It was just something I had used by lack of that which I really wanted, and when that which I really wanted came along, I made the transition. It's as simple as that. Each to his own, as the saying goes. So why do I advocate GNU/Linux? Because it's a good, decent and very powerful operating system, and if you really care about IT, then there's a lot you can learn by using it. And because there are people whose needs are not met by Windows, or who are having too much trouble with all the malware et al. So those are people I suggest GNU/Linux to, and I don't mind explaining the technical aspects to them to help them better understand. I am however not *pushing* GNU/Linux onto anyone. If they like Windows, hey, it's their machine, and they're the ones who have to use it. No problem there at all. It's just that I hate two things: (1) lies (of any kind); and (2) being ordered around and being told what I can and cannot use on my own computers, or anywhere else in my life for that matter. Too many people are subjected to both of the above, and often without that they're realizing it. And so I attempt to rectify those abominations. Sometimes it works, and other times it doesn't - e.g. because there are certain people who enjoy bashing us GNU/Linux advocates just a little too much, and such people are not open to truth or fact. And while such people may be parrotting corporate propaganda - whether they actually believe in its validity or not - the whole "GNU/Linux versus Microsoft Windows" debate is only a smokescreen to most of them. They're not here so much because they hate GNU/Linux, but simply because they're looking to bully someone. Something to think about... (And by the way, thanks for keeping this a civil debate. That's how any and all advocacy should be. Mudslinging has never benefitted anyone.) -- *Aragorn* (registered GNU/Linux user #223157)
From: Ezekiel on 3 Aug 2010 21:18 "Aragorn" <aragorn(a)chatfactory.invalid> wrote in message news:i3a901$3kl$1(a)news.eternal-september.org... > On Tuesday 03 August 2010 20:49 in comp.os.linux.misc, somebody > identifying as Ezekiel wrote... > >> "Aragorn" <aragorn(a)chatfactory.invalid> wrote in message >> news:i39gjb$qe8$1(a)news.eternal-september.org... >> >>> [Ezekiel wrote:] >>> >>>> So which is it??? One side of your mouth is claiming that the NT >>>> kernel was lifted/stolen from VMS by Cutler [... >>> >>> Yes, that is correct. >>> >>>> ...] and the other side of your mouth is claiming that it's based on >>>> the Windows 3.1 kernel [... >>> >>> No, that is *not* what I was saying. And this is exactly *why* I >>> have elaborated on the design of the NT-based Windows versions >>> earlier on. >>> >>> I have specifically stated that all current versions of Microsoft >>> Windows - all of which are based on NT, as you well know - use a >>> *compound* kernel, i.e. there are two separate entities both running >>> in kernelspace - or in layman's terms: in the highest privilege ring >>> of the underlying microprocessor, i.e. ring 0 - and that one of those >>> two is the NT kernel (which is based upon VMS) and the other one is >>> the winkernel - I think it's called win32, but in the 64-bit versions >>> it'll probably have been renamed to win64 - which runs atop of the NT >>> kernel. >> >> Huh??? Perhaps it's time for a link or something to clarify what >> you're trying to say. > > Sorry, I do not collect links on the specifics of Windows - as an > ostensible Microsoft Windows advocate, that should be *your* job > instead - but I will expound upon this subject in my comments below > your next statements. > >> I've never heard of a "compound kernel" being used anywhere in NT. >> There's the kernel itself and then there are various *subsystems* such >> as the Win32 subsystem and at one time the Posix subsystem and OS2 >> subsystem. > > Okay, you have now named them "subsystems", which *is* actually what I > was talking about - and if I'm not mistaken, that is also the > nomenclature that Microsoft themselves use in order to refer to these > components, albeit that the term "subsystem" is generally used in a > more comprehensive manner, i.e. in reference to both the kernel and > userspace components of such a subsystem. But you're right, perhaps > using the term "subsystem" is better verbage. At least we've solved the verbiage and terminology issue. > So here goes... You have just referred to various subsystems in the > Windows NT, which were all still part of NT 4.0, which is the NT > version I have been using between late 1997 and late 1999. These > subsystems were... > > ° the Windows-native (win32) subsystem (and now also win64) > > ° the OS/2 subsystem, which was only a 16-bit subsystem and > > ° the POSIX subsystem, which - if memory serves me right - was > > All three of the above are/were comprised of a kernelspace component and > a userspace component. So while the NT kernel itself - NTKRNL.EXE? - > was the bottom component of the kernel, the various subsystems added an > additional kernel layer, specialized for each of the three > environments. The win32 (and now also win64) kernel component is the > winkernel I was talking of, and is what Windows uses for most of its > kernel tasks, even though the underlying NT kernel could do all of > those things as well, and even better. Yes and no. The underlying "kernel" proper doesn't have a user-mode interface for user-mode apps to run. It's the individual subsystems that provide this. >>> It is this latter winkernel - win32 or win64, whatever it's called - >>> which is basically still the same as in Windows 3.1, but which has >>> been adapted to run on top of NT instead of on top of DOS. It's not basically the same. The user-mode interface/API is similar to make porting apps easier. The calls to CreateWindow() and MoveTo()/LineTo() are nearly identical whenever possible but that's about it. The underlying implementation is different. >>> And _that_ is where the problem lies, because that is a legacy _of_ >>> the old Windows 3.1 for DOS. Microsoft has held on to that design, >>> instead of throwing the operating system-level functions in the >>> Windows component away and delegating that to the underlying NT >>> kernel. And they have done that, yes, to a certain extent, but by >>> far not as much as would actually have been needed to make Windows >>> into a stable, secure and true multi-user platform. >> >> Windows-NT is stable [... > > If that were the case, then how come so many people know what a "blue > screen of death" is, and why did it even get to be called that? Where did the term "kernel panic" originate from? For the BSOD it's because there were many millions of users with a huge combination of hardware, BIOS, software and drivers and some of these combinations caused problems. It's literally been *years* since I've had or seen a BSOD. >> ...] and it is a multi-user OS and has been since day #1. > > No, that is not correct either. The *NT* kernel supports multi-user > functionality, but the Windows subsystem does not. Exactly what in the Windows subsystem doesn't support multi-user functionality? > Well, there is a > very limited multi-user functionality in the Windows subsystem now, but > this was again bolted on afterwards, and not even by Microsoft itself. So it's just like the X-windowing system which was developed and bolted on to Unix at a later date. > This added-on functionality was actually developed by Citrix Systems and > originally sold as Citrix Metaframe, but Microsoft then took a license > on this and incorporated it with the server edition of Windows NT, and > named it Windows NT Terminal Services. But an add-on it was and still > is, since it didn't even exist in Windows NT 4.0 Workstation, Windows > 2000 Professional and Windows XP Home Edition. It did exist in these versions of the OS but was artificially restricted to the "server" version of the OS - not the desktop version. That's a licensing/sales issue, not a technical limitation. >> It supports multiple telnet clients, or SSH clients and with NT >> Server it supports multiple GUI clients as well (via RDP). > > See above. This functionality was *added* *to* certain versions of > Windows as part of the Windows subsystem - again, because the NT kernel > does and already did support it, but Microsoft has opted to do this > kind of stuff via the win32/win64 subsystem instead, with just a few > hooks into the underlying NT kernel layer - and it was originally > developed by Citrix Systems and sold as Citrix Metaframe. And X-windows was *added* to Unix after the fact. NT has supported multiple user accounts since day #1 and telnet and multi-user telnet and other non-GUI support has existed for well over a decade now. >>> This is quite a different organization of the way the user is >>> presented with a graphical user interface from how it is done in >>> Windows. And given that Windows NT is based upon VMS, which itself >>> also could use an X Window System, this is how Microsoft *should* >>> have done it. But they didn't, because of backwards compatibility >>> and because they wanted to make as little changes as possible to the >>> Windows concept. >> >> It was a design decision. Fact is that X was terribly slow at the time >> and it was a decision based on performance. > > Terribly slow? I'd say that X is actually pretty fast and pretty lean, > if you compare the hardware requirements for Vista - I'm not talking about today - the design decision not to use a client-server model for the GUI was made back in the early 1990's when computing capacity was a small fraction of what's available today. > I would rather think that Microsoft did it the way they did it for the > reasons I've mentioned, *plus* that they wanted to do it in a > proprietary way, of course. I'm sure they had their reasons. RDP protocol isn't as flexible as X-11 but it certainly works and performs very well. > I'm not sure on the status of any open source X11 implementations during > the development of the first versions of Windows NT, but going the open > source way was not exactly in line with Microsoft's corporate strategy, > and taking out a license on a proprietary implementation of the X > Window System would have been too costly and thus too limiting in terms > of the profit margin. It would have been a bad strategy from the > corporate point of view. I'd agree that this was probably a factor in the decision. >>> And so, instead of going this way, they simply ported the existing >>> Windows design to the NT kernel as if it was just another version of >>> DOS. Given that the Windows versions which were available as >>> applications/environments for a separately sold MS-DOS/PC-DOS package >>> also doubled as memory extenders and (cooperative) multitaskers for >>> DOS, the concept of making the underlying parts of Windows into a >>> kernel component was already there. >> >> Hint... the 'video subsystem' is NOT the entire design of Win-NT. > > Oh, I know that, and I'm not even talking of the video subsystem[*] but > of the win32/win64 subsystem, of which the userland and part of the > kernel in some (but not all) of the NT-based Windows versions are so > tightly integrated with the graphical user interface that it's > virtually if not entirely unseparable. The kernel itself isn't tied to a GUI. But many applications are. But many applications and services/daemons (CLI, web-server, database, scripting, etc) don't need a GUI to run. > Okay, let's rewind a bit here. DOS did indeed have a 16-bit segmented > memory model, but that was not the only property of DOS. DOS was also > designed for a 16-bit processor with such a 64 KB segmented memory > model and which only had a 1 MB address space, of which the top 384 KB > was used for the mapping of ISA peripherals, similar to how PCI devices > also have an address space between the 3 GB and 4 GB barriers on 32-bit > and 64-bit systems. And in addition to that, this processor, the Intel > 8086, also did not have any privilege rings, so everything running on > that processor had all access to the hardware. Agreed. In the same context the 640k limit wasn't a limitation of DOS. The original 8086 could only access 1MB of address space (which you mentioned) of which the uper 384k was reserved. That leaves 640k which is what DOS had to run in. > Since DOS was developed for such a processor, every application that ran > atop of DOS would also have full privileges and full access to > everything, and effectively became the operating system once it was > loaded into memory. That was in fact what a "disk operating system" > was intended to do, i.e. it was an executable loader, not a real > operating system. By todays standard it wasn't much of an OS but it did provide some "OS like" functionality such as access to disk drives, the file system and etc. Not much compared to what an OS provides today but it was slightly better than nothing. > Then came the Intel 80286. This processor had a mode which was > compatible with the 8086 (and the slightly slower but functionally > equivalent 8088), and this was called "real mode", because all memory > addresses accessed from within this mode are the real addresses, i.e. > there is no remapping or address translation going on. This real mode > still exists in all x86-32 and x86-64 processors today, and at machine > power-up, this is the mode that is active. And the 80286 could switch from real-mode to protected-mode but was basically brain dead when switching back. (It could switch back and forth but it was slow and convoluted.) > The other mode of that 80286 processor was still only 16-bit and also > still used a 64 KB segmented memory model, but it was a quite different > mode, with privilege separation, in which an operating system kernel > could access and assign the memory to applications, without that the > applications themselves would be aware of where in memory they were > being loaded. This mode was called protected mode, and it also had > hardware support for threads, and thus for multitasking. The soon > therafter released 80386 would extend this protected mode to 32-bits > (for both addressing and instructions), and as such, introduced the > flat memory model. > > Now, let's take a jump to Windows 3.0 and 3.1, because that's where it > started getting interesting. See, Windows 3.0 had three modes - "real > mode", "standard mode" and "386 enhanced mode" - of which the former > was dropped in Windows 3.1. In "standard mode" and "386 enhanced > mode", Windows itself would be not just a graphical user interface, but > would run in protected mode for a lot of what it was doing - more so in > Windows 3.1 than in 3.0 - because Windows also became a DOS extender. The main reason for the "DOS extender" in Windows 3.1 was so that users could continue to use the plethora of DOS applications that existed at the time. Releasing a new OS that couldn't run any existing DOS software would have been the kiss of death. > It added cooperative multitasking, and it was capable of accessing a > great deal more of memory than DOS, thanks to the protected mode of the > underlying processor. The 80386 really changed things. > Now, you may find all of this boring and you may think once again that > I'm beating around the bush, but I'm not. I am explaining all of this > to you so that you would be able to follow where I'm going with this. Not boring. I lived through all that and was working while it happened so it brings back some memories. One bad memory was "palettes" for video cards that only supported 256 colors which was a major PITA from a development perspective. > So, to come back to what Windows was already doing in its 3.0 and > 3.1/3.11 guises, we could say that Windows was taking over from DOS > at "being an operating system". And when Windows 95 was introduced, > that is still what Windows was doing, but with parts of the code > extended to the 32-bit level - Windows 3.0 and 3.1/3.11 were still > 16-bit and only used some 32-bit code on an i386 or better processor > for virtual memory management and access to the swapfile, bypassing the > DOS I/O protocols, which were expensive (in terms of the processor > having to drop back to real mode before it could execute the I/O > operation). I agree. > So what you have here, is basically the whole Windows subsystem. In > Windows 95, it was a blend of 16-bit and 32-bit protected mode code, > and thus it would not run on an i286 anymore, while in Windows 3.1, it > was still capable of running on an i286 in "standard mode", albeit that > it paid off to run it on an i386 because of the ability to multitask > DOS applications via the i386's "virtual 8086 mode", and because of the > better memory management and swapfile access. So far so good. > Now, with all of this in mind, let's jump back in time to before Windows > 95 was released, and to when Windows NT was being developed. So you > already had a complete Windows "subsystem" in the form of Windows > 3.1/3.11. > > And so what Microsoft did was conceive Windows NT as a modular platform, > with the underlying NT kernel being the basis for > multiple "personalities", or subsystems, if you will, and each > subsystem "doing its own thing". And so they adapted the existing > Windows 3.1 subsystem - which still ran atop of DOS, although it wasn't > using DOS for much anymore - to the underlying 32-bit NT kernel. The > NT kernel itself would be used for process scheduling and memory > management, and as a hardware abstraction layer. Okay. > Now, ask yourself why Windows NT would be just as happy booting and > running off a FAT16 filesystem. The answer is evident, i.e. the > security subsystem was a bypassable layer. NT - and I am now talking > of the NT microkernel which was written by Dave Cutler, not of the > Windows NT operating system as a whole - didn't care about what > filesystem it was on, because its only job with regard to filesystems > was to provide the security hooks via the access control lists. And > the Windows subsystem could use such access control lists, but did not > require them either, since it was basically nothing but a port of the > old "Windows 3.1 for DOS" subsystem to the underlying 32-bit NT > microkernel, and so most of the kernel functions - except for memory > management and certain types of process management, low-level hardware > access and the optional security layer - were still handled by the > Windows subsystem, which as the result of its adaptation to the > underlying NT kernel was upgraded to what you would now call win32 (and > the win64 equivalent). On NT support for legacy 16-bit apps was handled by WoW (Windows on Windows) where the 16-bit apps ran in what I'll loosely call a "virtualized" 16-bit Windows environment. Similar to how backward compatibility with 32-bit Windows apps is handled on 64-bit versions of Windows. > As I have told you (and others) many times already, Windows NT was a > compromise for me, because I came from 32-bit OS/2 and I had actually > wanted a UNIX system - NeXtSTeP, to be precise - but proprietary UNIX > was incredibly expensive for private use, and I had no internet and > GNU/Linux was still pretty much in its infancy - we're talking 1997 > here. NT was always a 32-bit OS but because of the reality of the marketplace it had to be backward compatible and support 16-bit apps. There's no 16-bit code anywhere in NT but WoW allowed 16-bit apps to be run on a 32-bit OS. I really don't see this as a limitation or otherwise crippling of the underlying 32-bit OS. > But coming from OS/2, I did not want to go with the DOS-based Windows > versions, so I opted for NT 4.0 Workstation instead. And that was > quite a daring thing to do back in those days, because apart from > Microsoft itself, virtually no other software vendor was offering > NT-specific software, and I had a hell of a time trying to get NT to > play nicely with my videocard at the time, which was one of the first > ATi AGP cards - "Rage Turbo" or something; I don't exactly remember > what it was called, but I do remember that I needed Service Pack 3 to > get it to work, and the boxed NT version I had was only SP 1, so I had > to order said Service Pack from Microsoft. Similarly, it was also not > easy to get NT to work with my soundcard. There was no such thing as > autodetection of my hardware in NT 4.0. The typical pains of being an early adopter. At work my supervisor gave me a budget of $xk to buy a computer. I picked out a dual-processor Micron to run NT 4.0 on. > So why do I advocate GNU/Linux? Because it's a good, decent and very > powerful operating system, and if you really care about IT, then > there's a lot you can learn by using it. And because there are people > whose needs are not met by Windows, or who are having too much trouble > with all the malware et al. So those are people I suggest GNU/Linux > to, and I don't mind explaining the technical aspects to them to help > them better understand. I'm more than familiar with Linux and Unix in general. At work we develop software for Linux, Solaris, HPUX, AIX, zOS etc so I spend plenty of time with those OS's as well as Windows (which is my desktop). It's also the typical desktop at the development house I work in although a few people do run Linux as their desktop OS. Cheers and good night. - Zeke
From: Aragorn on 3 Aug 2010 22:30 On Wednesday 04 August 2010 03:18 in comp.os.linux.misc, somebody identifying as Ezekiel wrote... > "Aragorn" <aragorn(a)chatfactory.invalid> wrote in message > news:i3a901$3kl$1(a)news.eternal-september.org... > >> On Tuesday 03 August 2010 20:49 in comp.os.linux.misc, somebody >> identifying as Ezekiel wrote... >> >>> I've never heard of a "compound kernel" being used anywhere in NT. >>> There's the kernel itself and then there are various *subsystems* >>> such as the Win32 subsystem and at one time the Posix subsystem and >>> OS2 subsystem. >> >> Okay, you have now named them "subsystems", which *is* actually what >> I was talking about - and if I'm not mistaken, that is also the >> nomenclature that Microsoft themselves use in order to refer to these >> components, albeit that the term "subsystem" is generally used in a >> more comprehensive manner, i.e. in reference to both the kernel and >> userspace components of such a subsystem. But you're right, perhaps >> using the term "subsystem" is better verbage. > > At least we've solved the verbiage and terminology issue. Yes, speaking the same language (in the figurative sense) is essential for any debate. And given your background as you have layed it out at the bottom of this post, you appear to be a different person from whom I originally thought you were, so you may not be aware of this, but although my English is reported to be quite good by many, I am not a natively English speaker, and I also happen to be a high-functioning autistic adult. One of the problems I often have in communicating is that I know exactl what message I want to convey, but my brain doesn't seem to come up with the correct words. The fact that I communicate on a daily basis in at least two languages - neither of which is my native language - throws in a lot of neurological confusion to my speech center. ;-) >> So here goes... You have just referred to various subsystems in the >> Windows NT, which were all still part of NT 4.0, which is the NT >> version I have been using between late 1997 and late 1999. These >> subsystems were... >> >> ° the Windows-native (win32) subsystem (and now also win64) >> >> ° the OS/2 subsystem, which was only a 16-bit subsystem and >> >> ° the POSIX subsystem, which - if memory serves me right - was >> >> All three of the above are/were comprised of a kernelspace component >> and a userspace component. So while the NT kernel itself - >> NTKRNL.EXE? - was the bottom component of the kernel, the various >> subsystems added an additional kernel layer, specialized for each of >> the three environments. The win32 (and now also win64) kernel >> component is the winkernel I was talking of, and is what Windows uses >> for most of its kernel tasks, even though the underlying NT kernel >> could do all of those things as well, and even better. > > Yes and no. The underlying "kernel" proper doesn't have a user-mode > interface for user-mode apps to run. It's the individual subsystems > that provide this. Yes, that is what I was saying, or attempting to say, at least. >>>> It is this latter winkernel - win32 or win64, whatever it's called >>>> - which is basically still the same as in Windows 3.1, but which >>>> has been adapted to run on top of NT instead of on top of DOS. > > It's not basically the same. The user-mode interface/API is similar to > make porting apps easier. The calls to CreateWindow() and > MoveTo()/LineTo() are nearly identical whenever possible but that's > about it. The underlying implementation is different. True, but that is exactly why it - "it" meaning the win32/64 kernel component - natively does not provide for a multi-user API. The multi-user functionality is there in the NT kernel, but the Windows subsystem doesn't have that, or at least, it didn't until Microsoft bought the Citrix Metaframe technology. On account of that, the OS/2 subsystem was of course also not multi-user aware - OS/2 was never intended for that sort of thing - but I'm also not sure on whether the POSIX subsystem fully supported that. I believe that I may have read somewhere that it didn't, but then again I could be wrong on that, so take this with a grain of salt. >>>> And _that_ is where the problem lies, because that is a legacy _of_ >>>> the old Windows 3.1 for DOS. Microsoft has held on to that design, >>>> instead of throwing the operating system-level functions in the >>>> Windows component away and delegating that to the underlying NT >>>> kernel. And they have done that, yes, to a certain extent, but by >>>> far not as much as would actually have been needed to make Windows >>>> into a stable, secure and true multi-user platform. >>> >>> Windows-NT is stable [... >> >> If that were the case, then how come so many people know what a "blue >> screen of death" is, and why did it even get to be called that? > > Where did the term "kernel panic" originate from? For the BSOD it's > because there were many millions of users with a huge combination of > hardware, BIOS, software and drivers and some of these combinations > caused problems. It's literally been *years* since I've had or seen a > BSOD. Perhaps, but it is also well-known that the BSODs were actually disabled by default via a Registry entry as of Windows XP on. That didn't mean that the system wouldn't crash anymore, but just that it wouldn't spit out a BSOD when it did. >>> ...] and it is a multi-user OS and has been since day #1. >> >> No, that is not correct either. The *NT* kernel supports multi-user >> functionality, but the Windows subsystem does not. > > Exactly what in the Windows subsystem doesn't support multi-user > functionality? The fact that it was never designed for that. The underlying NT kernel was, but the way multi-user functionality was implemented in the NT-based Windows versions - as something developed by a third party, i.e. Citrix Systems - is not exactly ideal. It still for a large part relies on the Windows subsystem itself - and does not integrate with it as well - instead of really digging in deep into what the underlying NT kernel itself can do. But of course, the latter method would require a far more substantial revision of (the) Windows (subsystem) as a design in itself. >> Well, there is a very limited multi-user functionality in the Windows >> subsystem now, but this was again bolted on afterwards, and not even >> by Microsoft itself. > > So it's just like the X-windowing system which was developed and > bolted on to Unix at a later date. True, but the X-Window System was never intended to be an operating system. It does not have a kernel component floating on top of the underlying POSIX kernel. Everything that concerns the kernel in a UNIX/POSIX system is handled by that kernel, and the X Window System only provides for a GUI interface to the underlying operating system. It doesn't even have a personality of its own, because in terms of user interface, X11 is as rudimentary as it gets. (That's where the window managers and desktop environments come in.) The difference between X11 and the Windows subsystem is that the Windows subsystem does still perform a number of kernel tasks, and in so much actually that although the NT kernel component in itself is a microkernel, the compound NT kernel and win32/64 kernel is rather monolithic. (Well, it's a hybrid, actually, and more so now in the most recent versions of Windows.) >> This added-on functionality was actually developed by Citrix Systems >> and originally sold as Citrix Metaframe, but Microsoft then took a >> license on this and incorporated it with the server edition of >> Windows NT, and named it Windows NT Terminal Services. But an add-on >> it was and still is, since it didn't even exist in Windows NT 4.0 >> Workstation, Windows 2000 Professional and Windows XP Home Edition. > > It did exist in these versions of the OS but was artificially > restricted to the "server" version of the OS - not the desktop > version. That's a licensing/sales issue, not a technical limitation. Chronologically, Citrix Metaframe was only developed *after* Windows NT had already been released, though, since Citrix used (the server version of) Windows NT as the basis for its Metaframe. It cannot have been added by Microsoft before NT 4.0, which was the first version I know of that had a Terminal Server Edition, and at that time, Citrix Metaframe was still around in corporate deployment under that name. >>> It supports multiple telnet clients, or SSH clients and with NT >>> Server it supports multiple GUI clients as well (via RDP). >> >> See above. This functionality was *added* *to* certain versions of >> Windows as part of the Windows subsystem - again, because the NT >> kernel does and already did support it, but Microsoft has opted to do >> this kind of stuff via the win32/win64 subsystem instead, with just a >> few hooks into the underlying NT kernel layer - and it was originally >> developed by Citrix Systems and sold as Citrix Metaframe. > > And X-windows was *added* to Unix after the fact. True, but you cannot compare X11 to the Windows subsystem. The latter is far more elaborate, both because it has a kernel component and because it provides for a complete GUI, with its window management, window decorations and icons. X11 has none of those things. It's a very thin network-transparent client-server layer, but very little more than that. > NT has supported multiple user accounts since day #1 and telnet and > multi-user telnet and other non-GUI support has existed for well over > a decade now. Multiple user accounts, yes, but sequentially. Telnet and multi-user telnet and non-GUI support, yes, but these were low-level accesses provided via the underlying NT kernel, not accesses into and provided by the Windows subsystem. >>>> This is quite a different organization of the way the user is >>>> presented with a graphical user interface from how it is done in >>>> Windows. And given that Windows NT is based upon VMS, which itself >>>> also could use an X Window System, this is how Microsoft *should* >>>> have done it. But they didn't, because of backwards compatibility >>>> and because they wanted to make as little changes as possible to >>>> the Windows concept. >>> >>> It was a design decision. Fact is that X was terribly slow at the >>> time and it was a decision based on performance. >> >> Terribly slow? I'd say that X is actually pretty fast and pretty >> lean, if you compare the hardware requirements for Vista - > > I'm not talking about today - the design decision not to use a > client-server model for the GUI was made back in the early 1990's when > computing capacity was a small fraction of what's available today. Well NeXtSTeP seemed to be doing quite well, and although its GUI was proprietary (and object-oriented), it ran on top of a BSD system. >>>> And so, instead of going this way, they simply ported the existing >>>> Windows design to the NT kernel as if it was just another version >>>> of DOS. Given that the Windows versions which were available as >>>> applications/environments for a separately sold MS-DOS/PC-DOS >>>> package also doubled as memory extenders and (cooperative) >>>> multitaskers for DOS, the concept of making the underlying parts of >>>> Windows into a kernel component was already there. >>> >>> Hint... the 'video subsystem' is NOT the entire design of Win-NT. >> >> Oh, I know that, and I'm not even talking of the video subsystem[*] >> but of the win32/win64 subsystem, of which the userland and part of >> the kernel in some (but not all) of the NT-based Windows versions are >> so tightly integrated with the graphical user interface that it's >> virtually if not entirely unseparable. > > The kernel itself isn't tied to a GUI. But many applications are. But > many applications and services/daemons (CLI, web-server, database, > scripting, etc) don't need a GUI to run. True, but these are again not specific to the Windows subsystem. They are rather specific to the underlying NT kernel. It's the Windows subsystem which I consider to be a kludge, not the underlying NT kernel. NT itself is a pretty decent kernel. >> Since DOS was developed for such a processor, every application that >> ran atop of DOS would also have full privileges and full access to >> everything, and effectively became the operating system once it was >> loaded into memory. That was in fact what a "disk operating system" >> was intended to do, i.e. it was an executable loader, not a real >> operating system. > > By todays standard it wasn't much of an OS but it did provide some "OS > like" functionality such as access to disk drives, the file system and > etc. Not much compared to what an OS provides today but it was > slightly better than nothing. Well yes, it was very limited, but that was all it was designed to do on that particular type of processor. And MS-DOS/PC-DOS was actually bought by Bill Gates from Tim Paterson of Seattle Computer, who had written it (under the name QDOS, for "Quick & Dirty Operating System") as a kind of "unauthorized upgrade" to CP/M, which itself was designed for either a 4-bit or an 8-bit microprocessor - I forgot which one. Back in those days, microcomputers did not even have hard disks yet, and they were so incredibly expensive that it was unthought of that they'd ever become commonplace in (virtually) every home. >> Then came the Intel 80286. This processor had a mode which was >> compatible with the 8086 (and the slightly slower but functionally >> equivalent 8088), and this was called "real mode", because all memory >> addresses accessed from within this mode are the real addresses, i.e. >> there is no remapping or address translation going on. This real >> mode still exists in all x86-32 and x86-64 processors today, and at >> machine power-up, this is the mode that is active. > > And the 80286 could switch from real-mode to protected-mode but was > basically brain dead when switching back. (It could switch back and > forth but it was slow and convoluted.) Well, yes, because on the 80286, switching from protected mode to real mode implied that the processor had to be reset. The 80386 did not have this requirement anymore and could switch back and forth far more easily, which is how "unreal mode" came to be, and by consequence, the "systems management mode" on the 80386sl. "Unreal mode" is achieved by setting up protected mode with the pagetables and all, and then dropping back to real mode, so that all of the installed memory could be accessed from there. The 80386sl's "systems management mode" made use of this for suspending the operating system and running highly privileged BIOS code, e.g. for turning on or off fans. >> It added cooperative multitasking, and it was capable of accessing a >> great deal more of memory than DOS, thanks to the protected mode of >> the underlying processor. > > The 80386 really changed things. It sure did. Linus Torvalds initially began working on Linux for the sake of exploring the possibilities of the 80386. >> Now, you may find all of this boring and you may think once again >> that I'm beating around the bush, but I'm not. I am explaining all >> of this to you so that you would be able to follow where I'm going >> with this. > > Not boring. I lived through all that and was working while it happened > so it brings back some memories. One bad memory was "palettes" for > video cards that only supported 256 colors which was a major PITA from > a development perspective. Gawd, the palettes, yes, I remember that. :-) No way you could be hoping to use an actual photograph as a background back in those days, even if you were able to get such a large file as a real photo on your hard disk, because all you had were those 256 colors out of a chosen and predefined range. :-) But then again, that was already quite an improvent for those of us who came from the "phosphor green screen". ;-) >> As I have told you (and others) many times already, Windows NT was a >> compromise for me, because I came from 32-bit OS/2 and I had actually >> wanted a UNIX system - NeXtSTeP, to be precise - but proprietary UNIX >> was incredibly expensive for private use, and I had no internet and >> GNU/Linux was still pretty much in its infancy - we're talking 1997 >> here. > > NT was always a 32-bit OS but because of the reality of the > marketplace it had to be backward compatible and support 16-bit apps. > There's no 16-bit code anywhere in NT but WoW allowed 16-bit apps to > be run on a 32-bit OS. I really don't see this as a limitation or > otherwise crippling of the underlying 32-bit OS. Yes of course, but I was not implying that NT wasn't a real 32-bit operating system. I was pointing out that Windows 95 and 98 weren't (and neither was ME, but that was even later), and that this is why I didn't want to use Windows 95 - 98 wasn't even out yet. So that's why I decided to settle for Windows NT 4.0. It was Windows - and thus I had the availability of plenty of enduser software - but it was at least a genuine 32-bit protected mode system. The compromise in my decision lies with the fact that I really wanted a UNIX system, which Windows NT was not. But at least it was 32-bit, and far more stable than the archaic Win95 that my friends were using and which was more recent than the OS/2 versions I had been using on my old computer, but still not as advanced. > Cheers and good night. Likewise. I was actually already on my way to bed when I saw your message appear in my feed (along with a couple of e-mails coming in, even though that's a separate application). I'm guessing it's a lot later already over here than in your local timezone. ;-) (04:30 AM as I'm sending this off.) -- *Aragorn* (registered GNU/Linux user #223157)
From: David Brown on 4 Aug 2010 03:57
On 04/08/2010 01:33, Aragorn wrote: > On Tuesday 03 August 2010 20:49 in comp.os.linux.misc, somebody > identifying as Ezekiel wrote... > >> "Aragorn"<aragorn(a)chatfactory.invalid> wrote in message >> news:i39gjb$qe8$1(a)news.eternal-september.org... >> > >> I've never heard of a "compound kernel" being used anywhere in NT. >> There's the kernel itself and then there are various *subsystems* such >> as the Win32 subsystem and at one time the Posix subsystem and OS2 >> subsystem. > > Okay, you have now named them "subsystems", which *is* actually what I > was talking about - and if I'm not mistaken, that is also the > nomenclature that Microsoft themselves use in order to refer to these > components, albeit that the term "subsystem" is generally used in a > more comprehensive manner, i.e. in reference to both the kernel and > userspace components of such a subsystem. But you're right, perhaps > using the term "subsystem" is better verbage. > > So here goes... You have just referred to various subsystems in the > Windows NT, which were all still part of NT 4.0, which is the NT > version I have been using between late 1997 and late 1999. These > subsystems were... > > ° the Windows-native (win32) subsystem (and now also win64) > > ° the OS/2 subsystem, which was only a 16-bit subsystem and > thus only compatible with OS/2 1.x applications; OS/2 1.x was > the only OS/2 generation jointly developed by IBM and > Microsoft, and OS/2 2.x - which was 32-bit - was developed > solely by IBM and was thus not supported by Microsoft > > ° the POSIX subsystem, which - if memory serves me right - was > also only a 16-bit subsystem; a more recent re-implementation > of this subsystem is the "Services for Unix", which I believe > is a 32-bit subsystem > > All three of the above are/were comprised of a kernelspace component and > a userspace component. So while the NT kernel itself - NTKRNL.EXE? - > was the bottom component of the kernel, the various subsystems added an > additional kernel layer, specialized for each of the three > environments. The win32 (and now also win64) kernel component is the > winkernel I was talking of, and is what Windows uses for most of its > kernel tasks, even though the underlying NT kernel could do all of > those things as well, and even better. > In the early days of NT and OS/2, there was a lot of talk about separation of the kernel of an OS, and "personalities" or APIs. The idea was that at the bottom you would have a kernel - NT, OS/2, or a *nix kernel of some sort. On top of that you would have different personalities, such as Win16, Win32, OS/2, and posix, which would act as translation layers between an API and the kernel and other components. Additional components such as drivers, gui, etc., would run on top of this. That way you could buy an OS that suited your needs and your hardware (Windows at the low end, OS/2 in the middle, and *nix for high end hardware), and run any application on top of it. At most you might have to add a new personality to your system. The developers and technical people thought it was a great plan, as did the more advanced customers. Marketing people from MS and IBM liked to talk about it - giving the customer choice, etc. Then when Win95 came out and MS's marketing muscle combined with IBM's incompetence pushed OS/2 off the agenda, MS dropped all pretence at interoperability and everything non-Windows became periphery - why place nice with the other systems when you can take the whole market? <snip> > >>> This is quite a different organization of the way the user is >>> presented with a graphical user interface from how it is done in >>> Windows. And given that Windows NT is based upon VMS, which itself >>> also could use an X Window System, this is how Microsoft *should* >>> have done it. But they didn't, because of backwards compatibility >>> and because they wanted to make as little changes as possible to the >>> Windows concept. >> >> It was a design decision. Fact is that X was terribly slow at the time >> and it was a decision based on performance. > > Terribly slow? I'd say that X is actually pretty fast and pretty lean, > if you compare the hardware requirements for Vista - I'm not aware of > the requirements for Windows 7 - with the hardware requirements for any > GNU/Linux distribution that could already do far more graphics-wise > than Vista before Vista was released. You needed half the system RAM, > half the video RAM, and a processor that was also only half as fast. > And then it still beat Vista like a hare racing a tortoise. > > I would rather think that Microsoft did it the way they did it for the > reasons I've mentioned, *plus* that they wanted to do it in a > proprietary way, of course. > In NT 3.x, the gui was separate from the kernel - it ran entirely in user space. This made the system more stable - even if the graphics drivers crashed (and many of the early graphics drivers were seriously buggy), the system as a whole did not go down. Just like with *nix, you could re-start the gui without affecting the underlying OS. However, this separation was slow. When working towards NT 4.0, which had a Win95-style gui, it was just too slow on reasonably priced hardware. The graphics drivers and much of the gui were moved into kernel space, making them significantly faster. Speed was the only reason for this decision. For comparison, *nix systems that ran on the same hardware at the time were typically much faster for non-gui operations, but X and gui apps were much slower and had fewer features (at the time, there was no such thing as 3D acceleration in X unless you had a huge wallet). If you look at modern X on Linux, you see a similar system. There are parts of the drivers that have moved into kernel space, and many of the more demanding features (such as DRM) bypass the layer separation of X for speed. I don't know how much of Win3.x and/or Win9x kernels or subsystems were copied into the original NT. But given that much of the low-level parts of Win3.x were written in x86 assembly, while NT was mainly in C (and some Pascal, I think - hence the non-C calling conventions), I'd assume there was a lot re-written. It may have been simply re-coded in C rather than re-designed. The version numbering of NT was chosen for marketing purposes. NT 3.1 was so-called because it couldn't be a lower number than the current Win3.0. However, it was almost non-existent in the real world. It wasn't until NT 3.5 that anyone actually used the OS, and the version number was chosen to be higher than that of other systems (both Windows and OS/2). It was also designed to give the impression that this was a mature OS that had gone through many years of development, when really NT 3.5 was a version 1.0 product (NT 3.1 was a prototype). Regarding multi-user support, NT had it from the start at the lower levels - things like ACL support in the file system, and user, ownership and permission information for all processes and system objects. What has always been almost entirely missing (and still is, even in Win7) is support in the user-level system - the file system layout, the gui, the software (from MS and from third parties) views multiple users as a personalisation issue, not a security issue. Thus you have multiple logins so that different users can have different desktop backgrounds and have their files somewhat separated - but not so that you keep them securely separated. <snip> |