Below anything in black is quoted from Wikipedia and a review of OS/2 PPC by an enthusiast
Windows NT and Variants
Windows NT is a family of operating systems produced by Microsoft, the first version of which was released in. The architecture complemented versions of Windows that were based on MS-DOS until Windows XP and Windows Server 2003 are the latest versions of Windows NT, though they are not branded as such for marketing purposes.
Ah the truth will out, yes, Windows, including 95, 98 and ME, were GUI shells over MS-DOS, which dates back to the venerable 8-bit QDOS (Quick and Dirty Operating System) without instruction set redesign from 1979. MS didn’t even write QDOS, they bought it off some guy that wrote it in his basement for $4k or something around there.
When development started in November , Windows NT (using protected mode) was to be known as OS/2 2.0, the next version of the operating system developed jointly by Microsoft and IBM. In addition to working on two versions of OS/2, Microsoft continued parallel development of the DOS-based and less resource-demanding Windows environment (using real mode). When Windows 3.0 was released in May 1990, it was so successful that Microsoft decided to change the primary application programming interface for the still-unreleased NT OS/2 (as it was then known) from an extended OS/2 API to an extended Windows API. This decision caused tension between Microsoft and IBM, and the collaboration ultimately fell apart. IBM continued OS/2), Windows NT (using protected mode) was to be known as OS/2 2.0, the next version of the operating system developed jointly by Microsoft and IBM. In addition to working on two versions of OS/2, Microsoft continued parallel development of the DOS-based and less resource-demanding Windows environment (using real mode<). When Windows 3.0 was released in May 1990 it was so successful that Microsoft decided to change the primary application programming interface for the still-unreleased NT OS/2 (as it was then known) from an extended OS/2 API to an extended Windows API. This decision caused tension between Microsoft and IBM, and the collaboration ultimately fell apart. IBM continued OS/2 2.0 development alone (IBM had already done a complete rewrite between 1.2 and 1.3 to fix MS bugs and performance problems), while Microsoft continued work on the newly-renamed Windows NT.
\n\n
Microsoft hired a group of developers from Digital Equipment Corporation led by Dave Cutler to build Windows NT, and many elements of the design reflect earlier DEC experience with VMS and RSX-11. The operating system was designed to run on multiple instruction set architectures and multiple hardware platforms within each architecture. The platform dependencies are largely hidden from the rest of the system by a kernel mode module called the HAL.
Put another way, a more accurate way IMO, Dave Cutler rewrote VMS, which had already been killed even within DEC by Unix and OS/400. If you really want to see NT internals (and how poorly designed they are) d/l a copy of OpenVMS, Cutler can\’t design his way out of a paper bag, never mind that the competency of both the management and development staff on the NT project is questionable at best – over 80% of the core code had to be rewritten for XP service pack 2 (remember all the incompatibilities?) due to its being total spaghetti code, and all that spaghetti is still in Windows 2003 Server – the poor sales of Windows Server can\’t justify the costs of merging the code streams. As for RSX, the first OS I used was RSX-9 on the DEC PDP-9, which was obsolete (but still pretty damn cool for the time) already in 1972 when I got one. Believe me it ain\’t much, more of a mildly task-sharing DOS for minicomputers than a real operating system. Oh and HAL? Outside 2001 A Space Odyssey "HAL" is a nicer way of saying conversion layer. Windows NT and all its variants are, and will always remain, 32 bit ports of a 16 bit OS with a 16 bit API, with conversion code to allow it to run on new processors with different bit sizes and instruction sets. Compile a Windows NT program and you\’re running binary that was designed for the 8 bit, 650khz (yes that\’s kilohertz, not mega or giga) Intel 8080 chip.
Microsoft hired a group of developers from Digital Equipment Corporation led by Dave Cutler to build Windows NT, and many elements of the design reflect earlier DEC experience with VMS and RSX-11. The operating system was designed to run on multiple instruction set architectures and multiple hardware platforms within each architecture. The platform dependencies are largely hidden from the rest of the system by a kernel mode module called the HAL. Put another way, a more accurate way IMO, Dave Cutler rewrote VMS, which had already been killed even within DEC by Unix and OS/400. If you really want to see NT internals (and how poorly designed they are) d/l a copy of OpenVMS, Cutler can’t design his way out of a paper bag, never mind that the competency of both the management and development staff on the NT project is questionable at best – over 80% of the core code had to be rewritten for XP service pack 2 (remember all the incompatibilities?) due to its being total spaghetti code, and all that spaghetti is still in Windows 2003 Server – the poor sales of Windows Server can’t justify the costs of merging the code streams. As for RSX, the first OS I used was RSX-9 on the DEC PDP-9, which was obsolete (but still pretty damn cool for the time) already in 1972 when I got one. Believe me it ain’t much, more of a mildly task-sharing DOS for minicomputers than a real operating system. Oh and HAL? Outside 2001 A Space Odyssey “HAL” is a nicer way of saying conversion layer. Windows NT and all its variants are, and will always remain, 32 bit ports of a 16 bit OS with a 16 bit API, with conversion code to allow it to run on new processors with different bit sizes and instruction sets. Compile a Windows NT program and you’re running binary that was designed for the 8 bit Intel 8080 chip. <!– D(["mb"," Windows NT\'s kernel mode code further distinguishes between the\n"kernel," whose prime purpose is to implement\nprocessor-architecture-dependent functions, and the "executive." This\nhas led some writers to refer to the kernel as a microkernel,\nbut the Windows NT kernel does not meet many of the criteria required\nto be a "microkernel" and this was not the intention of Windows NT\'s\ndesigners. Both the kernel and the executive are linked together into a\nsingle loaded module, ntoskrnl.exe; from outside this module there is\nlittle distinction between the kernel and the executive. Routines from\neach are directly callable, as for example from kernel mode device\ndrivers. \nWhich leaves NT as open to vulnerabilities in security from intentional hacks or simply bad code. And Unix is no better (other than Mac OS X - which IS a microkernel design) except Unix has had longer to incubate so there\'s less bugs in the core code itself, and more of the obvious gaps have been filled in.\n OS/2 for PowerPC OS/2 PPC had precious little in common\nwith the Intel version. The product was based on the IBM microkernel,\nwhich was a refinement of the Carnegie Mellon University MACH\nmicrokernel. The microkernel bore no resemblance to the Intel OS/2\nkernel whatsoever and it was also very different from other operating\nsystems. \n\n
The OS/2 PPC development tools were quite different from their Intel\ncounterparts. For starters, instead of the LX executable format, OS/2\nPPC used the industry standard ELF. Several tools were completely\nunchanged (IPFC for instance), most were entirely new (linker,\nlibrarian, resource\ncompiler). The ABI (Application Binary Interface) used in OS/2 PPC was\nbased on and very similar to the UNIX SVR4 PowerPC ABI, although OS/2\nof course ran in little endian mode, unlike PowerPC Unices but just\nlike Windows NT.",1] ); //–>
Windows NT’s kernel mode code further distinguishes between the “kernel,” whose prime purpose is to implement processor-architecture-dependent functions, and the “executive.” This has led some writers to refer to the kernel as a microkernel, but the Windows NT kernel does not meet many of the criteria required to be a “microkernel” and this was not the intention of Windows NT’s designers. Both the kernel and the executive are linked together into a single loaded module, ntoskrnl.exe; from outside this module there is little distinction between the kernel and the executive. Routines from each are directly callable, as for example from kernel mode device drivers. Which leaves NT as open to vulnerabilities in security from intentional hacks or simply bad code. And Unix is no better (other than Mac OS X – which IS a microkernel design) except Unix has had longer to incubate so there’s less bugs in the core code itself, and more of the obvious gaps have been filled in. OS/2 for PowerPC OS/2 PPC had precious little in common with the Intel version. The product was based on the IBM microkernel, which was a refinement of the Carnegie Mellon University MACH microkernel. The microkernel bore no resemblance to the Intel OS/2 kernel whatsoever and it was also very different from other operating systems. The OS/2 PPC development tools were quite different from their Intel counterparts. For starters, instead of the LX executable format, OS/2 PPC used the industry standard ELF. Several tools were completely unchanged (IPFC for instance), most were entirely new (linker, librarian, resource compiler). The ABI (Application Binary Interface) used in OS/2 PPC was based on and very similar to the UNIX SVR4 PowerPC ABI, although OS/2 of course ran in little endian mode, unlike PowerPC Unices but just like Windows NT.<!– D(["mb"," \n The initial grandiose plan was to build the Workplace OS, the One\nRing to Bind Them All of operating systems. Workplace OS (or WPOS for\nshort) was supposed to be built on top of the IBM/MACH microkernel and\nsupport\nmultiple "personalities". The personalities would implement existing\noperating systems such as OS/2, AIX, Windows NT and perhaps even MacOS.\nIn the end this never happened and the only supported personality was\nOS/2. The initial design is still tangible in OS/2 PPC. The OS/2\npersonality is implemented in the "OS/2 Server" and there are\ncertain "personality neutral" services. Most device drivers were\npersonality neutral and worked directly with the microkernel. This\nincluded disk and network drivers. A notable exception were display\ndrivers,\nwhere OS/2 PPC introduced the GRADD model, later ported to Intel\nOS/2. Documentation on OS/2 PPC internals is somewhat sparse and\nthe online books shipped with PowerPC Toolkit are in many cases either\nincomplete or simply unmodified copies of OS/2 for Intel documentation.\nA good\nsource of information is redbook entitled "OS/2\nWarp (Power PC Edition) - A First Look" published by IBM\nInternational\nTechnical Support Organization in December 1995, document number\nSG24-4630-00 for those interested. \n \nWhat was OS/2 Warp, PowerPC Edition like? An unfinished\nproduct, rough around the edges but simultaneously technically very\ninteresting and advanced and showing promise. Even though the OS/2 PPC\nrelease wasn\'t called beta, it is obvious that this is a beta level\nproduct (if even that in some respects). Many features are unfinished\nor completely missing (networking in the first place). The kernel level\ncode doesn\'t look much like production build and prints out quite a lot\nof\ndebugging output on the serial console. The HPFS support was very\nunstable, and the stability of Win-OS/2 left a lot to be desired. There\nwere too many clearly unfinished parts of the product (documentation,\nmissing utilities etc.).",1] ); //–> The initial grandiose plan was to build the Workplace OS, the One Ring to Bind Them All of operating systems. Workplace OS (or WPOS for short) was supposed to be built on top of the IBM/MACH microkernel and support multiple “personalities”. The personalities would implement existing operating systems such as OS/2, AIX, Windows NT and perhaps even MacOS. In the end this never happened and the only supported personality was OS/2.
The initial design is still tangible in OS/2 PPC. The OS/2 personality is implemented in the “OS/2 Server” and there are certain “personality neutral” services. Most device drivers were personality neutral and worked directly with the microkernel. This included disk and network drivers. A notable exception were display drivers, where OS/2 PPC introduced the GRADD model, later ported to Intel OS/2. Documentation on OS/2 PPC internals is somewhat sparse and the online books shipped with PowerPC Toolkit are in many cases either incomplete or simply unmodified copies of OS/2 for Intel documentation. A good source of information is redbook entitled “OS/2 Warp (Power PC Edition) – A First Look” published by IBM International Technical Support Organization in December 1995, document number SG24-4630-00 for those interested. What was OS/2 Warp, PowerPC Edition like? An unfinished product, rough around the edges but simultaneously technically very interesting and advanced and showing promise. Even though the OS/2 PPC release wasn’t called beta, it is obvious that this is a beta level product (if even that in some respects). Many features are unfinished or completely missing (networking in the first place). The kernel level code doesn’t look much like production build and prints out quite a lot of debugging output on the serial console. The HPFS support was very unstable, and the stability of Win-OS/2 left a lot to be desired. There were too many clearly unfinished parts of the product (documentation, missing utilities etc.).<!– D(["mb"," \n \nOn the other hand a large portion of the system worked well. The user\ninterface and graphics subsystem in general didn\'t exhibit any\nanomalies. Multitasking was reliable and all things considered,\nresponsiveness quite good for a 100MHz CPU and code that was not likely\nto have been performance tuned. The multimedia subsystem worked much\nbetter than I expected. Many things were much improved compared to\nIntel OS/2 -- internationalization, graphics subsystem, updated console\nAPI and so on. The system seemed to have enough raw power,\neven if it wasn\'t harnessed too well. Boot time was rather long but\nonce up and running, the system was snappy (with some exceptions,\nnotably the CD-ROM driver). To reach true production quality, the OS\nwould have needed at least additional six months of intense\ndevelopment, probably more. \n \nHow useful is OS/2 PPC? Not very at the moment. In fact, it is almost completely\nuseless. It only runs on three or four models of rather rare IBM\nmachines and supports almost no additional devices. The OS is clearly\nunfinished and not entirely stable. Worst of all, there are about zero\napplications. Because OS/2 PPC was never truly in use, PowerPC versions\nof OS/2 applications were never sold (at least to my knowledge),\nalthough several OS/2 ISVs ported their applications to OS/2 PPC as\nevidenced by the application sampler. Porting wasn\'t very difficult and\ntools for building PowerPC applications were available, but since there\nwas no demand for them, there was little point in porting. Now here is the interesting thing. IBM has long said it can\'t open source OS/2 for intel because there is some MS code in there somewhere and nobody knows where, but MS knows there is some and a lawsuit would be in the offing. But that isn\'t true of OS/2 for PPC. All the pieces of OS/2 that MS worked on at all were completely replaced for the PPC version, and a number of people at IBM have hinted they\'re unhappy with Linux and IBM\'s abandonment of AIX, which is, after all, a better Unix than Linux. Other interesting points - the JFS Unix file system from AIX has recently been ported to OS/2 as well as Linux, and Posix support introduced (needed for all those useful little weirdly named Unix utilities like grep, tar, nprobe, tcpdump and netstat, odd things to do for a product you\'re publicly claiming is end of life. You can get Posix on Windows (GNU Cygwin) but because the file system is not Unix-y it\'s odd and frustrating to use (within the Posix shells you don\'t see a C:\\ drive even though you\'re on it, sort of ... and any Unix-y paths you do create don\'t show up from Windows). OS/2 for PPC has been ported to true 64 bit-ness including the API\'s, not just a recompile with a 64 bit compiler (Unixes other than Solaris) or even worse a 64->32 bit conversion layer (Windows). Rumours abound about IBM releasing an open source 64 bit version of what used to be OS/2 for PPC, with the IBM Power4 and IA64 platforms initially at a release state. But who needs another open source OS to add to Linux and OpenSolaris? Especially one that isn\'t, and was never intended to be, a unix variant.\n",1] ); //–> On the other hand a large portion of the system worked well. The user interface and graphics subsystem in general didn’t exhibit any anomalies. Multitasking was reliable and all things considered, responsiveness quite good for a 100MHz CPU and code that was not likely to have been performance tuned. The multimedia subsystem worked much better than I expected. Many things were much improved compared to Intel OS/2 — internationalization, graphics subsystem, updated console API and so on. The system seemed to have enough raw power, even if it wasn’t harnessed too well. Boot time was rather long but once up and running, the system was snappy (with some exceptions, notably the CD-ROM driver). To reach true production quality, the OS would have needed at least additional six months of intense development, probably more. How useful is OS/2 PPC? Not very at the moment. In fact, it is almost completely useless. It only runs on three or four models of rather rare IBM machines and supports almost no additional devices. The OS is clearly unfinished and not entirely stable. Worst of all, there are about zero applications. Because OS/2 PPC was never truly in use, PowerPC versions of OS/2 applications were never sold (at least to my knowledge), although several OS/2 ISVs ported their applications to OS/2 PPC as evidenced by the application sampler. Porting wasn’t very difficult and tools for building PowerPC applications were available, but since there was no demand for them, there was little point in porting. Now here is the interesting thing. IBM has long said it can’t open source OS/2 for intel because there is some MS code in there somewhere and nobody knows where, but MS knows there is some and a lawsuit would be in the offing. But that isn’t true of OS/2 for PPC. All the pieces of OS/2 that MS worked on at all were completely replaced for the PPC version, and a number of people at IBM have hinted they’re unhappy with Linux and IBM’s abandonment of AIX, which is, after all, a better Unix than Linux. Other interesting points – the JFS Unix file system from AIX has recently been ported to OS/2 as well as Linux, and Posix support introduced (needed for all those useful little weirdly named Unix utilities like grep, tar, nprobe, tcpdump and netstat, odd things to do for a product you’re publicly claiming is end of life. You can get Posix on Windows (GNU Cygwin) but because the file system is not Unix-y it’s odd and frustrating to use (within the Posix shells you don’t see a C:\ drive even though you’re on it, sort of … and any Unix-y paths you do create don’t show up from Windows). OS/2 for PPC has been ported to true 64 bit-ness including the API’s, not just a recompile with a 64 bit compiler (Unixes other than Solaris) or even worse a 64->32 bit conversion layer (Windows). Rumours abound about IBM releasing an open source 64 bit version of what used to be OS/2 for PPC, with the IBM Power4 and IA64 platforms initially at a release state. But who needs another open source OS to add to Linux and OpenSolaris? Especially one that isn’t, and was never intended to be, a unix variant. <!– D(["mb"," Sun\'s solution is, of course, Java. But Java programs are interpreted code (only Java can understand it, not the processor as in compiled code) running in a Java virtual machine running in another virtual machine (the OS application container) causing a further set of issues: \n Sun’s solution is, of course, Java. But Java programs are interpreted code (only Java can understand it, not the processor as in compiled code) running in a Java virtual machine running in another virtual machine (the OS application container) causing a further set of issues:
\n
\n
\n\n
OS/2 for PowerPC Impressions
OS/2 for PowerPC Impressions
But to ilustrate the crucial point:
But to ilustrate the crucial point:
\n
So what would OS/2 - call it microkernel Open Source/2 instead of Operating System/2 - bring to the table? ",1] ); //–>
So what would OS/2 – call it microkernel Open Source/2 instead of Operating System/2 – bring to the table? <!– D(["mb","
\n
\n
