There are some problems with specific cards (particulary NVIDIA cards.) However, the NT series really DOES perform faster. Even for simple programs like mine NT 4.0 is usually 10-20% faster than Win9x.
Fix the bloody kernel and volia, the problem is gone. It's the truth. All hardware vendors give up working on drivers eventually. Even OSS hardware drivers will not get updated when they get really old, simply because there are bigger fish to fry. Having a stable driver API is a big help here. Really, though, NVIDIA is really good about old hardware. I have an original TNT and they're still giving upgraded drivers for it.
The C++ network kit is simply a wrapper for the BSD-based API. The are moving networking into the kernel now, and the API will still be C based (because there is no C++ allowed in the kernel.) The network kit will still be a wrapper for the C based functions.
There is a GCC-IA64. There is a IA64 Linux kernel. Where have you been? Though I agree, that Intel may have a problem. However, it isn't has hard as you make it out to be. The main problem's with the difference in architecture are supposed to be addressed by the compiler. Intel's idea is that the compiler should do a huge amount of optimization, and free up those resources on the chip. I doubt GCC is doing a very good job of optimizing IA64 code, so that's out as a viable IA64 compiler. Chances are that Intel will release it's own compiler (like they have with x86) which will cover most of the hardware differences. Also, this compiler will optimize binaries correctly to work well with EPIC and the whole VLIW thing. By using this compiler, most of the architectural differences should be hidden. Since the big OS on IA64 (Montery) is being custom written, that shouldn't have such a bad time getting out, and other software should be easily ported if they are in fact portable applications.
Actually, the cool thing in Itanium is not the 64bit-ness (that is just kind of requisite for a next-gen proc) but the fact that the architecture scales to 8 pipelines. EPIC allows all 8 pipelines to stay filled (which BTW is probably the reason why the Itanium demos have been less than impressive, it is simply hard as hell to optimize for an 8-way proc.) AMD kind of misses that point. Of course, Sledgehammer also has a new-improved FPU, so that's the other big thing. But 64 bit is, as you said, a checkbox item. And it also isn't the main purpose of the new architectures. The media is taking it as such (because it is easier to understand 64 bit than parallel pipes) but the main purpose of 64 bit is so the developers don't feel stupid for introducing an 8-way 32bit proc.
As far as I recall, the Saturn chips don't hold a candle to the Dragonball procs in the TI8x (and the Gameboy. Interesting tidbit, the TI8x has a processor that is 6 MHz while the one in the GB is only 4 MHz, both are speced to run higher)
Inheritance and polymorphism may not be the only features of C++, but they are the important ones. First, templates are a fairly good idea, but they often get one into trouble. A lot of people use templates when they really shouldn't. Also, templates and inheritance overlap a little bit, and the uses of each should be more clear.
The reason that the kernel, support, netowork and storage kits are non-OO are because it makes more sense that way. That's a big thing in a well designed API. YOu have a unifying concept, but don't use it in places where it really doesn't make sense. It really doesn't make sense to have an object simply for translation loading purposes. You could put them into an object, but then you end up with an object that has members that have no other relation aside from the fact that they are in the support kit. For more important than that, though, is the fact that many functions in those kits need to be accessible from kernel drivers, where C++ isn't really allowed.
4 years ago, BeOS was in developers preview. As I remember it, it didn't have a lot of technologies back then. For an example of the BeOS APIs, take a look at
http://www-classic.be.com/documentation/be_book/ index.html.
The thing is that there are too many eostoric features in C++ that would be better left out. Why the hell is new implemented with exceptions? Is there any sane reason for doing tis? Why the hell do references exist. It's like Microsoft, which defines LPSOMETHING as SOMETHING*. People should be clear when the thing they are using is a pointer. The best way to use C++ is really as C with classes. for example, in an API, use it for overloadable functions, single inheritance, and not having to typedef structs. Otherwise, it is too insanely compicated to use. (For a good example of C++ gone bad, take a look at MFC) Although, not all C++ interfaces are crappy. Take a look at Be's. It actually makes sense, they use standard C functions when it makes sense, and there are no multply inherited templated virtual base classes.
Huh? I didn't even USE the word BeOS in my post! BeOS is entirely irrelevant here. Not to mention the fact that it doesn't even HAVE an object model (yet)
Freedom for developers != Freedom for users to chose. Freedom for users requires that the developers adopt strong standards. All the most user friendly OSs have had strong central policies. By using these strong central policies, apps can interact with each other much better, and "cool" features are opened up. For example, by forcing all developers to use the native toolkit for GUI apps, all BeOS apps are automatically scriptible. By having a standard method for translating foreign file formats, all BeOS applications benifet when new translators are added. Central features are critical and rarely hinder to developer as long as they are well designed. Take Windows. There are 3 different toolkits, native Win32, MFC, and OWL. All use the same backend services, but are simply different programming models. They allow the developer to chose which model they like, yet still allow integratin of apps using the different models. MFC apps are just as integrated into the system as Win32 and OWL apps.
In fact, less developer freedom (to a point) == MORE user freedom. For example, I hate GNOME. It's not religious or anything, it just rubs me the wrong way. However, I'm forced to use it (for some of its apps) or else use KDE and live with two libraries loaded. I could use the KDE versions, but why? If the two used the same backend, I'd have the freedom to choose which desktop environment I wanted without being a slave to the developer who chose to use GTK instead of Qt! Why can't my GNOME and KDE apps communicate well? The best IDE on Linux is KDevelop, and the best graphics software is GIMP. However, they are two different models, so they don't cooperate with each other. Say I like Gnumeric better than KSpread. However, I prefer KWord to AbiWord. Will the two interoperate? No.
UNIX actually had the right idea origninally, but the DEs ruined it. When all apps used the native X protocols, then you could just switch widget sets, and apps would get updated. You could switch window managers, and all apps would still work with each other. What was required simply an extension to the native X protocols. Living with one system object model is surely a good trade for allow the user more flexibility. However, the DE guys thought they were OS designers, and now we have two OSs (incompatible ones) running on top of Linux.
You said MS implements most components in VB. They don't. You said that high level languages like Python should be the basis for a UNIX object model. It shouldn't. And yes, Python is slow. Take a look at some of the Phython based web-browsers.
The 90/10 rule coming from a UNIX guy? The same people who decided it would be a good idea to use a very feature rich, powerful, bloated, network transparent model like CORBA in a desktop object model? I mean you're using some seriously heavy duty stuff just to embed an HTML renderer into your filemanger!
What do numerical codes have to do with this? (And what is a numerical code?) I don't see how you can argue that abstraction is good for performance. For example, if you based a file system on CORBA, it would always be slower than the same FS based direct system calls. Less abstraction usually leads to more performance. Not only are there fewer layers that software has to deal with, but making the interface close to the way hardware works leads to designs that take better advantage of hardware. A great example of this is OpenGL. In OpenGL, state changes are very clearly seperated from other commands. Because state changes are expensive for hardware to do, it is important that the API's reflect this. Another good example is DirectSound. By keeping you aware of exactly how the sounds are being played (streaming or in-buffer) and whether the hardware or software is doing the mixing, it forces designers to create programs that reflect the limitations of the hardware. You can't argue that fact that DirectX is faster than the normal Windows APIs simply because it is much less abstract from how the hardware works.
Second, you argue that abstraction faccilitates good design. That is entirely untrue. Good design is whatever runs fastest on a given piece of hardware. By abstracting too much, you lose the "feel" of the hardware. A car analogy is good here. Performance drivers hate cars that "abstract" away the feel of the road, because such cars simply cannot be driven at full potential.
Third, you say that the idea of "brute force, low level code" is dying. I would like to pick apart that concept. Less abstraction doesn't lead to brute-force code, and low level code is not necessarily (in fact it is rarely) brute-force. People who code at the lowest levels tend to realize that good design is the biggest part of performance, and design appropriatly. Good design is good design regardless of how much abstraction there is. Less abstraction simply makes a given design faster, and allows more innovation in the design used.
By your arguement, one could say that retained mode's in 3D (which are highly abstracted) would be faster than immediate modes. This is simply untrue. You try doing Quake in retained mode. It will never happen. Also, high abstraction usually leads to a lot of design decisions being made by the creator of the API. Another BAD idea. The people writing the code will 99% of the time have much better design ideas than the people writing the API. The best thing to do is make the APIs as low level as possible, so people can implement good designs. These designs will almost always be faster than the abstracted ones, and the lack of layers between the application and the hardware will just increase the performance of a good design.
You take abstraction from a UNIX point of view. Not the best people to consult when performance is concerned. The best people to consult are game developers. Games are probably the most highly tuned pieces of software running on PCs, because they have to do so much on so limited resources. Game programers almost always prefer less abstraction. When Windows came out (with more abstractions) they continued programming for DOS. They didn't actually get on Windows until DirectX came out, which allowed them close access to hardware. On Sega's Dreamcast, most developers ditched Windows CE (which wasn't slow, it used DirectX) in favor of the "to the metal" Sega OS. On PSX, game developers trick the hardware to do things it wasn't designed to do. The result are programs that really take 100% advantage of hardware, and by far outstrip what application designers can do. The evangalist behind DirectX said, "It is incredible that Internet Explorer can visibly refresh just drawing a page with a few pictures on it, when the guys at id are spraying whole worlds with tons of AI-driven monsters on the screen at 30fps." (Paraphrased, don't have the actual article in front of me.)
Re:Used it, played with it, worked with it.
on
Looking Back At NeXT
·
· Score: 2
Okay, each person needs a home directory. The system has to manage between users. There are permissions to deal with, access limitations, the requirement that a lot of commands require root, etc. If the model was hugely simplified, (no ownership restrictions, only home-directory restrictions, all applications run at any level, etc) and it didn't add overhead to the system (no checking for access privliges on hardware) it might fly. But otherwise, it would probably be too much complexity for too little gain.
Your whole point is based on the freedom of the developer. That is not the best way to do anything of software. There should be a single, flexible, powerful model, and all developers should be required to program to it. I really don't give a rat's ass if that means I have to program for a certain toolkit (from a developer's point of view) if it means that all applications use the full power of the system toolkit and interact well together (User's POV). Compared to Microsoft components on Linux is still a pipe-dream. Where on windows most modern apps use OLE and COM and take advantage of the features they provide (not only objects, but scripting, and network transparency) and applications extensivly use the component technologies, you've got the current GNOME/KDE situation where there are different object models, no-one uses them to their full potential, and all the really important apps don't work well together. I want to be able to take a spread sheet from StarOffice and embed it into a GIMP picture which is embedded into a StarOffice document. Since neither app really takes advantage of the component model I can't do that. Also, implementing objects in high level languages would be insane. MS doesn't use Visual Basic for most components, the easiest language to use COM from is C++. Python would be terrible slow. Components should be lean, mean, fast, network transparent objects from which to build applications. Only if they meet these criteria (lean, fast and pervasive) will they succeed.
The main thing is that in UNIX, too much policy is bad. Overall the lack of policy is done to overkill propertions in UNIX, but it is still a good idea. Also, performance comes first. Do you realize how god-aweful slow a CORBA based filesystem would be? The thing is the more you abstract, the more performance you lose. Up to a certain point it's a good idea, but beyond that it's not such a good idea. The component interface you mention is already implemented to some degree on OLE. As the designers put it, "OLE is 2/3rds of an operating system." However, using to it's full potential is a very performance robbing proposition.
Bloat!=Flexibility. You wouldn't believe how overbloated GNOME and KDE are. From my experiance, BeOS has a fairly complete application framework, with a lot of consitancy. It is also the lightest major OS available on x86 (with the exception of QNX Neutrino). (Out of *BSD, *NIX, Windows, etc) The major problem is that GNOME and KDE suffer from huge feature bloat. GNOME implements a file system, uses CORBA (trying to kill a fly with a Buick there) for objects, and in general puts in a lot of stuff 99% of people don't need. Consistancy does not have to be accompanied by huge overbloat. I just has to be designed with some sense of what would be better if left out.
That is redundant. For a product like the NeXT machine, failing by definition means no market penetration. Again saying that Intel's products are sucessful because they have deep market penetration (that sound strangely erotic...) is redundant. Something causes them to have deep market penetration and that is why they are succesful. For example, good marketing causes them to be sucessful.
Also, Intel survives on technical merit. The competing product are more expensive, and until recently, Intel had the highest performance in the x86 arena.
Re:Used it, played with it, worked with it.
on
Looking Back At NeXT
·
· Score: 2
Well, that really isn't multi-user. That's multiple profiles. Windows 98 has the same concept, that there are different logins, they each have access to certain apps, and they each have their own preferences, etc. That really doesn't take much OS support. However, multi-user is much more complex. It means that applications now can be in either system or local scope, it means that multiple people and use the system at the same time, it means the system must manage multiple people, it makes administration harder, it makes software installation harder, etc. Profiles probably are a very important. I wouldn't say it's a "must" but they are very important. However, multi-user adds a lot of complexity that really isn't needed if you just want to be able to have individual logins and preferences.
Re:Used it, played with it, worked with it.
on
Looking Back At NeXT
·
· Score: 2
Well in it's defense, the BeOS GUI takes time to get used to. Initially, I was appalled by the yellow title bars, but hey, it grows on you. Still pissed off by the poor right-click support though. As for themes, they kick ass. The main thing is that themes don't change the UI, they change the look. I personally don't like the default NeXT theme (or at least the default Window Maker theme) because it is too dark for my taste. Theming allows you to change the colors, the shapes, "the look" but retains the parts that make a GUI efficiant and functional (menus, placement, hotkeys, right clicking, object orientation, etc.)
Bill G. Has written lots of products for *NIX. As far as I can remember, COM is already available on UNIX, and various Micrsoft backend products have been ported to UNIX.
>>>>>>>>>
Sorry for the double post,/. paused while submitting and I thought it hadn't gone through.
>>>>>>>>>>
Hello? It's called a LOADER? It's like saying Linux is a LILO program! You don't seem to understand the whole Windows architecture here. Points...
A) You have to differentiate the two types of DOS. Ones is virtualized DOS running in a VM. In this state, the machine is in Vx86 protected mode. Then there is real mode DOS. In this state, the macine is in real mode with DOS running nativly on the hardware.
B) A Windows machine boots first into DOS for various compatibility reasons. It then loads win.com, which kicks DOS out of memory and into a VM.
C) Windows 9x isn't a DOS program. Neither, in fact, is Windows 3.1. Windows 3.1 was generally an OS of its own, except it used DOS services for major things. For example, Win 3.1 did its own memory management, process management, etc. While all of this was going on, the system was running in protected mode. However, for many things, it made calls to DOS. For example, the file system (Until Windows for Workgroups 3.1) was real mode DOS. Thus, whenever filesystem operations had to be done, the machine had to switch out of protected mode, into real mode, and run the DOS file system routines. Also, Win3.1 used the services of DOS to do a lot of HW access. Thus, it was only partially running on top of DOS. Win95 DOESN'T run on top of DOS. The parts of Win 3.1 that used to call DOS was largely replaced by protected mode Win95 modules. Win95 still occasionally goes into real mode DOS to do some things, but 99% of the time it is running on its own.
D) Win9x is a DOS application just as much as Linux is a DOS application. It does its own hardware management, it does it's own process management, etc. It doesn't even run DOS in the position of the OS. For most tasks, DOS runs in a virtual machine ON TOP OF Win9x. The only time real-mode native DOS is run is for those instances I mentioned, during boot, and when you reboot into DOS.
E) You mention all these tricks you THINK MS did, but you miss the point. MS removed DOS entirely. No longer does ME support real mode drivers, because there isn't real mode DOS to support those drivers. It doesn't support programs that need "real" DOS, because it doesn't exist anymore. They only thing there is the VM DOS. It doesn't boot into DOS first, because there ISNT A DOS TO BOOT INTO!
Hello? It's called a LOADER? It's like saying Linux is a LILO program! A Win95 machine initially boots into DOS. This is for various backwards compatibility reasons. It then puts the system into protected mode and runs DOS in a virtual machine. You say that Window is just a DOS application. This is entirely false. Think of it this way. If Windows was a DOS application, then the machine couldn't be running in protected mode most of the time. DOS is a real mode operating system. It cannot be run in protected mode without using virtual x86 mode. Thus, in order for Win9x to run on top of DOS, you'd have to have a VM running directly on the hardware, DOS running on top of that, and Win9x running on top of that. That's a silly concept. Read up on Win9x. Win9x runs directly on the hardware. It is NOT a DOS application. They run DOS on a VM. The only time your system touches DOS is when your booting up, or when you reboot into DOS. All the other times, and DOS access is done through a VM. You mention all these tricks YOU think MS did, but you don't look at the obvious point. MS got rid of real mode DOS. There is no way to boot into DOS because there IS no DOS that can run without a VM. Straight DOS is gone. Not here anymore. MS hasn't disabled it, it has gotten rid of it entirely.
Slashdot Mirror
There are some problems with specific cards (particulary NVIDIA cards.) However, the NT series really DOES perform faster. Even for simple programs like mine NT 4.0 is usually 10-20% faster than Win9x.
Fix the bloody kernel and volia, the problem is gone. It's the truth. All hardware vendors give up working on drivers eventually. Even OSS hardware drivers will not get updated when they get really old, simply because there are bigger fish to fry. Having a stable driver API is a big help here. Really, though, NVIDIA is really good about old hardware. I have an original TNT and they're still giving upgraded drivers for it.
The C++ network kit is simply a wrapper for the BSD-based API. The are moving networking into the kernel now, and the API will still be C based (because there is no C++ allowed in the kernel.) The network kit will still be a wrapper for the C based functions.
Ahh, I see. My mistake
There is a GCC-IA64. There is a IA64 Linux kernel. Where have you been? Though I agree, that Intel may have a problem. However, it isn't has hard as you make it out to be. The main problem's with the difference in architecture are supposed to be addressed by the compiler. Intel's idea is that the compiler should do a huge amount of optimization, and free up those resources on the chip. I doubt GCC is doing a very good job of optimizing IA64 code, so that's out as a viable IA64 compiler. Chances are that Intel will release it's own compiler (like they have with x86) which will cover most of the hardware differences. Also, this compiler will optimize binaries correctly to work well with EPIC and the whole VLIW thing. By using this compiler, most of the architectural differences should be hidden. Since the big OS on IA64 (Montery) is being custom written, that shouldn't have such a bad time getting out, and other software should be easily ported if they are in fact portable applications.
There is also a PCI-X planned that will push over 1GB/sec. (64bit, 133MHz)
Actually, the cool thing in Itanium is not the 64bit-ness (that is just kind of requisite for a next-gen proc) but the fact that the architecture scales to 8 pipelines. EPIC allows all 8 pipelines to stay filled (which BTW is probably the reason why the Itanium demos have been less than impressive, it is simply hard as hell to optimize for an 8-way proc.) AMD kind of misses that point. Of course, Sledgehammer also has a new-improved FPU, so that's the other big thing. But 64 bit is, as you said, a checkbox item. And it also isn't the main purpose of the new architectures. The media is taking it as such (because it is easier to understand 64 bit than parallel pipes) but the main purpose of 64 bit is so the developers don't feel stupid for introducing an 8-way 32bit proc.
As far as I recall, the Saturn chips don't hold a candle to the Dragonball procs in the TI8x (and the Gameboy. Interesting tidbit, the TI8x has a processor that is 6 MHz while the one in the GB is only 4 MHz, both are speced to run higher)
This ARM connection may be backed up by the fact that Intel owns ARM now.
Inheritance and polymorphism may not be the only features of C++, but they are the important ones. First, templates are a fairly good idea, but they often get one into trouble. A lot of people use templates when they really shouldn't. Also, templates and inheritance overlap a little bit, and the uses of each should be more clear.
The reason that the kernel, support, netowork and storage kits are non-OO are because it makes more sense that way. That's a big thing in a well designed API. YOu have a unifying concept, but don't use it in places where it really doesn't make sense. It really doesn't make sense to have an object simply for translation loading purposes. You could put them into an object, but then you end up with an object that has members that have no other relation aside from the fact that they are in the support kit. For more important than that, though, is the fact that many functions in those kits need to be accessible from kernel drivers, where C++ isn't really allowed.
4 years ago, BeOS was in developers preview. As I remember it, it didn't have a lot of technologies back then. For an example of the BeOS APIs, take a look at/ index.html.
http://www-classic.be.com/documentation/be_book
The thing is that there are too many eostoric features in C++ that would be better left out. Why the hell is new implemented with exceptions? Is there any sane reason for doing tis? Why the hell do references exist. It's like Microsoft, which defines LPSOMETHING as SOMETHING*. People should be clear when the thing they are using is a pointer. The best way to use C++ is really as C with classes. for example, in an API, use it for overloadable functions, single inheritance, and not having to typedef structs. Otherwise, it is too insanely compicated to use. (For a good example of C++ gone bad, take a look at MFC) Although, not all C++ interfaces are crappy. Take a look at Be's. It actually makes sense, they use standard C functions when it makes sense, and there are no multply inherited templated virtual base classes.
Huh? I didn't even USE the word BeOS in my post! BeOS is entirely irrelevant here. Not to mention the fact that it doesn't even HAVE an object model (yet)
Freedom for developers != Freedom for users to chose. Freedom for users requires that the developers adopt strong standards. All the most user friendly OSs have had strong central policies. By using these strong central policies, apps can interact with each other much better, and "cool" features are opened up. For example, by forcing all developers to use the native toolkit for GUI apps, all BeOS apps are automatically scriptible. By having a standard method for translating foreign file formats, all BeOS applications benifet when new translators are added. Central features are critical and rarely hinder to developer as long as they are well designed. Take Windows. There are 3 different toolkits, native Win32, MFC, and OWL. All use the same backend services, but are simply different programming models. They allow the developer to chose which model they like, yet still allow integratin of apps using the different models. MFC apps are just as integrated into the system as Win32 and OWL apps.
In fact, less developer freedom (to a point) == MORE user freedom. For example, I hate GNOME. It's not religious or anything, it just rubs me the wrong way. However, I'm forced to use it (for some of its apps) or else use KDE and live with two libraries loaded. I could use the KDE versions, but why? If the two used the same backend, I'd have the freedom to choose which desktop environment I wanted without being a slave to the developer who chose to use GTK instead of Qt! Why can't my GNOME and KDE apps communicate well? The best IDE on Linux is KDevelop, and the best graphics software is GIMP. However, they are two different models, so they don't cooperate with each other. Say I like Gnumeric better than KSpread. However, I prefer KWord to AbiWord. Will the two interoperate? No.
UNIX actually had the right idea origninally, but the DEs ruined it. When all apps used the native X protocols, then you could just switch widget sets, and apps would get updated. You could switch window managers, and all apps would still work with each other. What was required simply an extension to the native X protocols. Living with one system object model is surely a good trade for allow the user more flexibility. However, the DE guys thought they were OS designers, and now we have two OSs (incompatible ones) running on top of Linux.
You said MS implements most components in VB. They don't. You said that high level languages like Python should be the basis for a UNIX object model. It shouldn't. And yes, Python is slow. Take a look at some of the Phython based web-browsers.
The 90/10 rule coming from a UNIX guy? The same people who decided it would be a good idea to use a very feature rich, powerful, bloated, network transparent model like CORBA in a desktop object model? I mean you're using some seriously heavy duty stuff just to embed an HTML renderer into your filemanger!
What do numerical codes have to do with this? (And what is a numerical code?) I don't see how you can argue that abstraction is good for performance. For example, if you based a file system on CORBA, it would always be slower than the same FS based direct system calls. Less abstraction usually leads to more performance. Not only are there fewer layers that software has to deal with, but making the interface close to the way hardware works leads to designs that take better advantage of hardware. A great example of this is OpenGL. In OpenGL, state changes are very clearly seperated from other commands. Because state changes are expensive for hardware to do, it is important that the API's reflect this. Another good example is DirectSound. By keeping you aware of exactly how the sounds are being played (streaming or in-buffer) and whether the hardware or software is doing the mixing, it forces designers to create programs that reflect the limitations of the hardware. You can't argue that fact that DirectX is faster than the normal Windows APIs simply because it is much less abstract from how the hardware works.
Second, you argue that abstraction faccilitates good design. That is entirely untrue. Good design is whatever runs fastest on a given piece of hardware. By abstracting too much, you lose the "feel" of the hardware. A car analogy is good here. Performance drivers hate cars that "abstract" away the feel of the road, because such cars simply cannot be driven at full potential.
Third, you say that the idea of "brute force, low level code" is dying. I would like to pick apart that concept. Less abstraction doesn't lead to brute-force code, and low level code is not necessarily (in fact it is rarely) brute-force. People who code at the lowest levels tend to realize that good design is the biggest part of performance, and design appropriatly. Good design is good design regardless of how much abstraction there is. Less abstraction simply makes a given design faster, and allows more innovation in the design used.
By your arguement, one could say that retained mode's in 3D (which are highly abstracted) would be faster than immediate modes. This is simply untrue. You try doing Quake in retained mode. It will never happen. Also, high abstraction usually leads to a lot of design decisions being made by the creator of the API. Another BAD idea. The people writing the code will 99% of the time have much better design ideas than the people writing the API. The best thing to do is make the APIs as low level as possible, so people can implement good designs. These designs will almost always be faster than the abstracted ones, and the lack of layers between the application and the hardware will just increase the performance of a good design.
You take abstraction from a UNIX point of view. Not the best people to consult when performance is concerned. The best people to consult are game developers. Games are probably the most highly tuned pieces of software running on PCs, because they have to do so much on so limited resources. Game programers almost always prefer less abstraction. When Windows came out (with more abstractions) they continued programming for DOS. They didn't actually get on Windows until DirectX came out, which allowed them close access to hardware. On Sega's Dreamcast, most developers ditched Windows CE (which wasn't slow, it used DirectX) in favor of the "to the metal" Sega OS. On PSX, game developers trick the hardware to do things it wasn't designed to do. The result are programs that really take 100% advantage of hardware, and by far outstrip what application designers can do. The evangalist behind DirectX said, "It is incredible that Internet Explorer can visibly refresh just drawing a page with a few pictures on it, when the guys at id are spraying whole worlds with tons of AI-driven monsters on the screen at 30fps." (Paraphrased, don't have the actual article in front of me.)
Okay, each person needs a home directory. The system has to manage between users. There are permissions to deal with, access limitations, the requirement that a lot of commands require root, etc. If the model was hugely simplified, (no ownership restrictions, only home-directory restrictions, all applications run at any level, etc) and it didn't add overhead to the system (no checking for access privliges on hardware) it might fly. But otherwise, it would probably be too much complexity for too little gain.
Your whole point is based on the freedom of the developer. That is not the best way to do anything of software. There should be a single, flexible, powerful model, and all developers should be required to program to it. I really don't give a rat's ass if that means I have to program for a certain toolkit (from a developer's point of view) if it means that all applications use the full power of the system toolkit and interact well together (User's POV). Compared to Microsoft components on Linux is still a pipe-dream. Where on windows most modern apps use OLE and COM and take advantage of the features they provide (not only objects, but scripting, and network transparency) and applications extensivly use the component technologies, you've got the current GNOME/KDE situation where there are different object models, no-one uses them to their full potential, and all the really important apps don't work well together. I want to be able to take a spread sheet from StarOffice and embed it into a GIMP picture which is embedded into a StarOffice document. Since neither app really takes advantage of the component model I can't do that. Also, implementing objects in high level languages would be insane. MS doesn't use Visual Basic for most components, the easiest language to use COM from is C++. Python would be terrible slow. Components should be lean, mean, fast, network transparent objects from which to build applications. Only if they meet these criteria (lean, fast and pervasive) will they succeed.
The main thing is that in UNIX, too much policy is bad. Overall the lack of policy is done to overkill propertions in UNIX, but it is still a good idea. Also, performance comes first. Do you realize how god-aweful slow a CORBA based filesystem would be? The thing is the more you abstract, the more performance you lose. Up to a certain point it's a good idea, but beyond that it's not such a good idea. The component interface you mention is already implemented to some degree on OLE. As the designers put it, "OLE is 2/3rds of an operating system." However, using to it's full potential is a very performance robbing proposition.
Bloat!=Flexibility. You wouldn't believe how overbloated GNOME and KDE are. From my experiance, BeOS has a fairly complete application framework, with a lot of consitancy. It is also the lightest major OS available on x86 (with the exception of QNX Neutrino). (Out of *BSD, *NIX, Windows, etc) The major problem is that GNOME and KDE suffer from huge feature bloat. GNOME implements a file system, uses CORBA (trying to kill a fly with a Buick there) for objects, and in general puts in a lot of stuff 99% of people don't need. Consistancy does not have to be accompanied by huge overbloat. I just has to be designed with some sense of what would be better if left out.
That is redundant. For a product like the NeXT machine, failing by definition means no market penetration. Again saying that Intel's products are sucessful because they have deep market penetration (that sound strangely erotic...) is redundant. Something causes them to have deep market penetration and that is why they are succesful. For example, good marketing causes them to be sucessful.
Also, Intel survives on technical merit. The competing product are more expensive, and until recently, Intel had the highest performance in the x86 arena.
Well, that really isn't multi-user. That's multiple profiles. Windows 98 has the same concept, that there are different logins, they each have access to certain apps, and they each have their own preferences, etc. That really doesn't take much OS support. However, multi-user is much more complex. It means that applications now can be in either system or local scope, it means that multiple people and use the system at the same time, it means the system must manage multiple people, it makes administration harder, it makes software installation harder, etc. Profiles probably are a very important. I wouldn't say it's a "must" but they are very important. However, multi-user adds a lot of complexity that really isn't needed if you just want to be able to have individual logins and preferences.
Well in it's defense, the BeOS GUI takes time to get used to. Initially, I was appalled by the yellow title bars, but hey, it grows on you. Still pissed off by the poor right-click support though. As for themes, they kick ass. The main thing is that themes don't change the UI, they change the look. I personally don't like the default NeXT theme (or at least the default Window Maker theme) because it is too dark for my taste. Theming allows you to change the colors, the shapes, "the look" but retains the parts that make a GUI efficiant and functional (menus, placement, hotkeys, right clicking, object orientation, etc.)
As I remember, they were pretty big for 3D and graphics.
Bill G. Has written lots of products for *NIX. As far as I can remember, COM is already available on UNIX, and various Micrsoft backend products have been ported to UNIX.
>>>>>>>>> /. paused while submitting and I thought it hadn't gone through.
Sorry for the double post,
>>>>>>>>>>
Hello? It's called a LOADER? It's like saying Linux is a LILO program! You don't seem to understand the whole Windows architecture here. Points...
A) You have to differentiate the two types of DOS. Ones is virtualized DOS running in a VM. In this state, the machine is in Vx86 protected mode. Then there is real mode DOS. In this state, the macine is in real mode with DOS running nativly on the hardware.
B) A Windows machine boots first into DOS for various compatibility reasons. It then loads win.com, which kicks DOS out of memory and into a VM.
C) Windows 9x isn't a DOS program. Neither, in fact, is Windows 3.1. Windows 3.1 was generally an OS of its own, except it used DOS services for major things. For example, Win 3.1 did its own memory management, process management, etc. While all of this was going on, the system was running in protected mode. However, for many things, it made calls to DOS. For example, the file system (Until Windows for Workgroups 3.1) was real mode DOS. Thus, whenever filesystem operations had to be done, the machine had to switch out of protected mode, into real mode, and run the DOS file system routines. Also, Win3.1 used the services of DOS to do a lot of HW access. Thus, it was only partially running on top of DOS. Win95 DOESN'T run on top of DOS. The parts of Win 3.1 that used to call DOS was largely replaced by protected mode Win95 modules. Win95 still occasionally goes into real mode DOS to do some things, but 99% of the time it is running on its own.
D) Win9x is a DOS application just as much as Linux is a DOS application. It does its own hardware management, it does it's own process management, etc. It doesn't even run DOS in the position of the OS. For most tasks, DOS runs in a virtual machine ON TOP OF Win9x. The only time real-mode native DOS is run is for those instances I mentioned, during boot, and when you reboot into DOS.
E) You mention all these tricks you THINK MS did, but you miss the point. MS removed DOS entirely. No longer does ME support real mode drivers, because there isn't real mode DOS to support those drivers. It doesn't support programs that need "real" DOS, because it doesn't exist anymore. They only thing there is the VM DOS. It doesn't boot into DOS first, because there ISNT A DOS TO BOOT INTO!
Hello? It's called a LOADER? It's like saying Linux is a LILO program! A Win95 machine initially boots into DOS. This is for various backwards compatibility reasons. It then puts the system into protected mode and runs DOS in a virtual machine. You say that Window is just a DOS application. This is entirely false. Think of it this way. If Windows was a DOS application, then the machine couldn't be running in protected mode most of the time. DOS is a real mode operating system. It cannot be run in protected mode without using virtual x86 mode. Thus, in order for Win9x to run on top of DOS, you'd have to have a VM running directly on the hardware, DOS running on top of that, and Win9x running on top of that. That's a silly concept. Read up on Win9x. Win9x runs directly on the hardware. It is NOT a DOS application. They run DOS on a VM. The only time your system touches DOS is when your booting up, or when you reboot into DOS. All the other times, and DOS access is done through a VM. You mention all these tricks YOU think MS did, but you don't look at the obvious point. MS got rid of real mode DOS. There is no way to boot into DOS because there IS no DOS that can run without a VM. Straight DOS is gone. Not here anymore. MS hasn't disabled it, it has gotten rid of it entirely.