All that is stupid. People don't give a damn if the widgets on different platforms looks the same, because people tend to use one platform, and are used to THOSE widgets. The Mozilla guys may think they're doing something cool by making all widgets look the same, but they're not. They are hurting the user experiance for each person's native platform. Like I said a few posts back, its a question of wether your app deserves a custom user interface. If you're doing a massive rendering package like Truespace, then yeah, the efficiancy of a custom UI will outweigh the learning curve. For almost all other apps however, (even office apps) sticking to the standard UI makes life easier for the USER. And Mozilla doesn't even have a more efficient interface, just a different one. The problem is that the Mozilla guys are engineering for themselves as opposed to their users. Nobody gives a damn if hitting the back button executes a java script. Nobody cares that the whole thing is XUL extendible. Leave that kind of stuff to the SITE designers (in a well designed site, the browser UI should be transparent.) However, people DO care that it is taking 40 meg of RAM and is ass-slow. People don't use a web browser for the hell of it, they use it to browse web sites. Give me a large window, small button toolbar, and some decent bookmarking systems, and then get the hell out of my way!
Problematically, X does a lot of that too these days. Most of graphics laden stuff done by modern systems like Qt and GNOME often use shared memory, and in the end X ends up just pumping pixels back to the server. Of course, there would be a really easy way to prevent this all. Switch to a disjointed client/server model. For example, BeOS uses a message passing model. Client apps send requests to the display server. It is damn fast on a local machine (mainly because message passing is pretty efficient and highly optimized) and theoretically, the display server could be replaced by one that shunts the calls to a remote server over the network. Thus, you get two hops for a local system, and three for a remote one. True, the local server would have to be replaced by a remote one and the system restarted, but most remote display machines operate in one mode for a long time, so that is not really a problem.
Nobdy gives a damn about the program authors. Programmers are mere servents to the USER. That's right, the USER is the most important part of the equation. This is no way detracts from the programmer. Car makers take pride in designing cars that people like and work hard in making them easy to use. Most authors also like it when people like their work. The problem with the *nix user experiance is that it is too concerned with programmers. In the end, the power to totally customize the interface is useless. Sure, some programs can benifet from an unusual interface, but most can't. You may think your interface ideas are just peachy, but in the end, they are a pain in the ass to the user. I like the way Windows does it. Most software has a similar interface. If your software really DESERVES a unique interface (like Truespace's which works wonderfully for the package, and since it is a major application, the quirks are worth learning) then you can take the time to code it. However, most software doesn't deserve a custom interface, because the increase in efficiency is by far offset by the learning curve. Who gives a damn if my AIM client has a perfectly tuned, custom interface?
I love it when people throw around the fact that the system waits for the user. When I am running 3D Studio, the system is certianly NOT waiting for the user. It is busting a gut to redraw the screen. I don't want my windowing system taking up 40MB of RAM that COULD be going to my rendering package. I don't want my GUI sucking up CPU cycles that should be going to my renderer. Or if I am background rendering, I don't want the GUI to steal those cycles. Sure I could run TWM, or turn the GUI off when I'm rendering, but damn it, I'm not blind! As a graphics person I LIKE pretty pictures. I can tell you that Windows does a lot more with hardware than Linux plus X can. To get the same features as Win95, you have to run Linux + X 4.0 + KDE 1.91 (sure you could use TWM, but it doesn't have anything like COM, or embedding, or the cool features in Win95) A 486/33 will run Win95 decently, but will puke on the equivilant Linux configuration. Sure, you can pare Linux down, but why bother competing if you can't compete with an equal feature set?
Very little of QNX is written in assembler. The bloody thing runs on almost as many architectures as Linux, without the 50 million (exaggerated of course) coders that Linux has. Without a portable code base, that wouldn't be possible. A lot of OSs do that. For example, BeOS can fit into less than a 16 meg permanent disc (sans some features of course) its just that the code base is really small, (around 1.5 M lines) not any assembler tricks or anything (most of BeOS is C and C++)
Actually the 9-3 drivers have been released by NVIDIA, and they are actually pretty stable. BeOS doesnt support GeForce-based cards as NVIDIA refuses to give them specs. You can get color VESA support, but that's about it. (And yes, I do support NVIDIA's desicion to not give BeOS drivers. Kind of senseless to try to support and OS that actually has less users than Linux. Also, the BeOS driver model is quite a bit different from Linux or Windows, so I suspect that they really don't want to go to the trouble to make real BeOS drivers. However, I do question their judgement on not giving BeOS the specs under NDA. Since all NVIDIA cards have a similar driver interface (courtesy of the universal NVIDIA driver architecture) it should be short work for Be to cook up drivers based on the existing TNT driver source.
Its silly to ever use manufactuer supplied drivers. Most often they are just nVidia's reference drivers with some cosmetic hacks. (And NVIDIA's default look is a lot nicer looking at that.) Additionally, the reference drivers tend to be much higher quality, and more importantly, they come out a month or two before the manufactuerers get it into their driver builds. I used to stick with standard drivers, but then realized I was eternally 2 or 3 driver builds behind. Thus, every possible driver on my computer is now reference.
Now after Microsoft goes on their Jihad against warezers trying to take down all illegal copies of their programs, you can consult these archives to find some choice applications.
NT was designed with a driver architecture. WDM is not it. Even if all NT driver development have shifted over to WDM, it is still not the optimal driver architecture for NT. The architecture that was originally designed to support the original driver API is not easily changed, thus WDM is sort of a bolt-on API for both Win98 and NT. Same thing with DirectX. DirectX is also a bolt-on API to NT, and thus will never be as good as an API around which the NT architecture is designed. Its probably less of an issue for DirectX, because it really just shoves the OS out of the way, but a non-native driver API can cause some performance problems. Maybe the new WDM model is MSs move to make NT a little more general. However, the NT 3.x architecture is still mostly present in Windows 2000. That architecture was designed mostly for performance, thus any discussion of the Windows 2K architecture should still make sense if you talk about the NT 3.x docs. Also, Win32 calls aren't wrappers. Win32 applications make Win32 calls to a user-space Win32 server. The server then communicates with the kernel and kernel level subsystems (via the NT native API and message passing) to implement these calls.
I don't know about you, but astronomy IS often about the telescope. A lot of astronomers really love their field, and for feel just as exited about a cool telescope as computer nerds feel about a cool computer. In any field, there will be a bond between man and tool. A carpenter takes care of his saws and chisels, a race car has a bond with is car, an athelete cherishes certian pieces of equiptment. Computing is just like any other field in that respect. Sure, there are carpenters who could care less about the tools and the profession and simply does it for a job, but in all fields, a great many people actually like what they do, and liking the equiptment that they use is often a part of it. So yes, a lot of computing may become more about the net than the computer itself, but a large number of computer users will still care about the elegance of the environment they're using, and the niftyness of the latest hardware or software. These people aren't necessarily only the nerds. In all computing areas there are people who simply like an OS or a system of its elegance. NeXT users are smitten by its elegance, MacOS users love its creative aspect, and BeOS users tend to be quite obsessive about their OS. Even Windows users can get attached to the raw power of DirectX.
Okay, now you're into debatable territory here. From my point of view, NT is a microkernel. Yes it runs most services in user space, and the servers in NT are conglomerated into the executive. However, they are still seperate entities, and communicate by message passing. In my opinion, taht constitutes a microkernel. Having high-performance I/O is a good thing. I think you misunderstand me, I really do like NT, in fact I use it about as often as I use BeOS. I was responding to your comment that NT was designed to be extendible over being high-performance. As for my backing up that NT is tuned more for performance than flexibility, I kind of explained that in the next paragraph, (running services in kernel mode, DirectX in the HAL, etc.) Even if WDM is the "official" driver API for NT, it is still not the native API. Win32 is the official API for NT, however it is not the native API. If you really want to see your applications perform as well as they can you'd use standard NT drivers, and the NT Native API. Neither are sanctioned by MS, but this is a technical discussion, not a political one. The truth is, that MS had to heavily endorse WDM because it needed drivers for NT. Even if it isn't the fastest way to do it on NT, that's the one they had to support. And I think the whole point of the WDM is that drivers should be cross compatible, except for video drivers (which aren't written to the WDM.) I think integrating DirectX into the HAL is a good idea. However, it is quite a complex system for something in the HAL, and does introduce bugs and make the system less "clean" from an acedemic point of view. I was using this point to support my assertion that NT is more tuned for performance then generality. Instead of adding a more general HAL bypass system, they chose to simply allow DirectX to pass through. NT does run a lot of services in kernel mode. In other microkernel OSs, there is no executive. Stuff that is in the NT executive (like I/O managers, etc) traditionally run in user mode. However, by running these in kernel mode, NT gains a performance increase. Also, that is one reason why NT blurs the lines between a monolithic and micro kernel. And I'm pretty sure NT is a microkernel. NT was designed as a microkernel, and its subsystems communicate by passing messages. (If it walks and quacks like a microkernel...) However, the design concessions (for performance) that MS made, made it much more of the "macrokernel" that MS holds it is today. However, if you read the documentation from NT 3.0 or 3.1, you'll see that it is billed as a microkernel.
No matter what your intent is, you write for Windows first. Whatever thing you use, the system that the program was one first will be the better port. Thus, if you care about your customers you write to Windows because your customers (statistically) all use Windows. If you care about selling software, you write to Windows, because (again) your customers are using Windows.
You don't:) Without basing the system API on something like COM (like DirecX does) it isn't really feasible to upgrade the API. However, I think the UNIX way to avoid it is to simply add a new API. Take a look at all the baggage APIs in Linux. You have POSIX, you have some SystemV APIs you have X, you have GNOME, you have Motif, you have KDE, you have TK, TCL, ncurses, ad nauseum.
Actually it wouldn't. DirectX in Windows 2000 is unadultered, bonafied, wholesome, god-given, 100% pure DirectX. Without the superlatives it means that DirectX on Win2K bypasses the HAL so it works similarly to the one in Win9x. However, Linux doesn't offer this kind of direct access so those games that depend on it won't run.
Maybe because Office is better than all the native applications? Office is better than Applix, AbiWord, etc, and most parts of it are better than WordPerfect Suite (except word.)
He's kind of saying that it is useless to feel strongly about *software* And that guy doesn't seem to feel THAT strongly, since he is running a windows machine at all. You have to be pragmatic about these things. If you feel so strongly about not running Windows, then I'm sure you have the willpower to simply not play Diablo 2.
Let's see. Most MacOS users are smarter than you'll ever be judging by the stupidity of your comment. And as for MacOS itself, when another operating system comes near to the power of MacOS for destktop publishing and art, then please let me know. Meanwhile, I think the MacOS users will be sitting there enjoying an inredible imaging engine (Display PDF) with color matching, flexibility and special effects that other OSs can't touch.
Okay, if you optimize your card (aside from just outright reporting false numbers) so that it runs Quake and Unreal faster, then you just sped up 90% of the games out there that similar algorithms. Even if you just speed up QuakeII, you've sped up all the games based on that engine. Manufacturers can't do that because it requires optimizing the whole driver, which is actually legitimate! Also, real world benchmarks are harder to fudge. If you do something to a driver that makes Quake run faster, than chances are that driver also makes all the other 3D games run faster. That's even more relevant for serving. I proposed a benchmark where the test emulates real-world conditions. IE, the script reflects how a person would actually use the system. If vendors do something to optimize for it, then they'd be optimizing real world usage. That's a good thing.
I was kind of kidding about that;) I was talking about stuff like what Megabyte did with their Voodoo2 card. They wrote drivers that accelerated part of the Direct3D geometry pipeline. However, no games at the time actually used the geometry pipeline, except (curiously!) WinBench3D! The cheats don't really cause stability faults. More often, they are sections in the driver that detect certain types of benchmark code, and then optimize for it. Or they do what NEC did with PowerVR. At some point, the PowerVR drivers simply detected WinBench and returned artificial numbers! I was kind of pointing out that it is hard to cheat on benchmarks like Quake.
NT "runs all its servers in kernel space"? Do you mean drivers? Services? Services are not run in kernel space, althougth they can be set with a high priority. All drivers are run in kernel space, though. >>>>>>>> NT is a microkernel operating system. In microkernel OSs, servers are processes that provide system services such as networking, I/O, graphics, RPC, etc. In some cases, servers even provide memory management. In most microkernel OSs, these servers are in user space. However, in NT, they run in kernel mode. It's true that drivers run in kernel space, but so do the subsystems that load the drivers. This is a significant difference to most microkernels which have servers and large parts of drivers in userspace. BeOS for example has all servers in userspace, and most drivers are loaded by the kernel. IBM's experimental WorkPlace OS, on the other hand, put drivers mostly in userspace and even put services such as paging in user space. This tended to have a performance hit, and NT avoids it by running servers in kernel mode, even though that is riskier.
"The kernel has a lot of design concessions that faccilitate a really high I/O rate." Really? Have you looked at the code for network and storage? >>>>>>>> No, but I have looked at design documents that detail the NT architecture. NT was designed for VERY high performance I/O.
I have written network and storage drivers for NT4/ Win2k and is not designed to be fast. Check out the DDK. Both storage and network use a miniport model (SCSI Miniport and NDIS Miniport) with a port driver doing much of the work. To make matters worse, Win2k use WDM for its drivers. WDM tends to add an additional driver object to the layered model. Both miniport and WDM are designed to be very general and take control away from the driver developer. A call to read a few bytes from the disk goes through so many layers. First, the file system drivers, then class.sys, then disk.sys, then scsiport.sys, then vendorscsiminiport.sys, then hardware. There can also be any number of filter drivers in the mix. WDM allows upper and lower filters for each FDO (Functional Device Object). We got a nice performance boost by not using the SCSIMiniport/Class driver interface. Win2k is not designed to be fast as much as extendable and general. >>>>>>>>>> Win2K is definately not designed to be extendible and general. While WDM may add a lot of overhead to the driver interface, that is not NT's native driver model. Microsoft added WDM to allow drivers for Win98 to work on NT. Also, you cannot deny that the architecture is tuned more to high performance than generality. A lot of critics of NT complained that the architecture was "academically dirty." Meaning that a lot of design desicions resulted in a faster but less clean system. For example, Windows 2K has DirectX class integrated into the HAL. Very unclean. NT also runs all services in kernel mode. Again, unclean. The NT microkernel globs up a lot of services that should be in the servers, which furthers performance, but makes the microkernel less general and less extendible. It runs the windowing system in kernel space! How general and extendible is THAT? NT does have a lot of management overhead, true. But it is also designed for raw performance. If you're not changing anything (ie. simply streaming data of a disk while not doing anything else) it is really fast.
That could also be a problem. Processes take more time to start than a thread does. Also, it still doesn't mitigate the fact that the TCP/IP stack is single threaded so THAT can stall.
First, let me say, that benchmarks like this are useless. I'm not against benchmarking, mind you, but what I AM against is artificialy benchmarks. For example, in testing 3D cards, ZDN still uses an artificial benchmark called WinBench3D. Of course, manufacturers with no morals (ATI, Megabyte, Intel) can optimize for these types of benchmarks, and thus seem faster than they are. However, if you do a real world benchmark, like say test the FPS in Quake, you're results are actually valid. If a manufacturer cheats so their card runs actual games faster, then thats actually a good thing. What I'd like to see is a real world server benchmark. Maybe set up a COM+ simulation where actual COM+ applications (for example a database) does actual requests on the server, then measure how many clients the server can handle. Or do something like have the server serve up a database and have scripted clients access the database in a real manner. Those are the kinds of benchmarks that really work, but unfortuenatly, they take actual work. As for NT beating Linux, remember that NT is designed to run stuff like this. Though NT is a microkernel, it rusn all its servers in kernel space (though Linux does as well, I think). Also, the kernel has a lot of design concessions that faccilitate a really high I/O rate. There not so good for doing real world tasks, because the OS tends to step on its own toes, but if you testing raw performance, NT usually wins. But these performance enhancements take their toll on stability and ability to handle high loads. For example, in Windows2K, DirectX has some interface calls implemented into the hardware abstraction layer, which really speeds up performance, but at the cost of stability. That said, WindowsNT really IS a decent OS, and some parts are simply better designed than their conterparts in Linux. For the desktop, (if you have the RAM), W2K is perfectly stable (because most desktop users reboot at least once every few days) and nicely supports media. Also, Win2K has a good multi-threaded TCP/IP stack that was rewritten from NT4. Despite its faults (ahem bloat) it does actually have some features that the Linux guys would be wise to look into. (ahem, COM) W2K is nowhere near being the end-all be all of OSs, but neither is Linux. They both have their flaws, and NT has actually improved enough that W2K actually has some uses in the server role! Anything doing small transactions that doesn't need to be particularly stable (for example DNS) would be served well by NT which responds well to little transactions like this.
For those who are complaining about them using an "old" version of Linux, get over it. The 2.4 kernel is not only still experimental, it is not in any distro yet. As for the system software being at 6.1, again it doesn't really matter because RedHat 6.2 (The latest from the "Linux company," at least as far as the mainstream is concerned) only contains a few tweeks, and is really not much of an upgrade.
Slashdot Mirror
All that is stupid. People don't give a damn if the widgets on different platforms looks the same, because people tend to use one platform, and are used to THOSE widgets. The Mozilla guys may think they're doing something cool by making all widgets look the same, but they're not. They are hurting the user experiance for each person's native platform. Like I said a few posts back, its a question of wether your app deserves a custom user interface. If you're doing a massive rendering package like Truespace, then yeah, the efficiancy of a custom UI will outweigh the learning curve. For almost all other apps however, (even office apps) sticking to the standard UI makes life easier for the USER. And Mozilla doesn't even have a more efficient interface, just a different one. The problem is that the Mozilla guys are engineering for themselves as opposed to their users. Nobody gives a damn if hitting the back button executes a java script. Nobody cares that the whole thing is XUL extendible. Leave that kind of stuff to the SITE designers (in a well designed site, the browser UI should be transparent.) However, people DO care that it is taking 40 meg of RAM and is ass-slow. People don't use a web browser for the hell of it, they use it to browse web sites. Give me a large window, small button toolbar, and some decent bookmarking systems, and then get the hell out of my way!
Problematically, X does a lot of that too these days. Most of graphics laden stuff done by modern systems like Qt and GNOME often use shared memory, and in the end X ends up just pumping pixels back to the server. Of course, there would be a really easy way to prevent this all. Switch to a disjointed client/server model. For example, BeOS uses a message passing model. Client apps send requests to the display server. It is damn fast on a local machine (mainly because message passing is pretty efficient and highly optimized) and theoretically, the display server could be replaced by one that shunts the calls to a remote server over the network. Thus, you get two hops for a local system, and three for a remote one. True, the local server would have to be replaced by a remote one and the system restarted, but most remote display machines operate in one mode for a long time, so that is not really a problem.
Nobdy gives a damn about the program authors. Programmers are mere servents to the USER. That's right, the USER is the most important part of the equation. This is no way detracts from the programmer. Car makers take pride in designing cars that people like and work hard in making them easy to use. Most authors also like it when people like their work. The problem with the *nix user experiance is that it is too concerned with programmers. In the end, the power to totally customize the interface is useless. Sure, some programs can benifet from an unusual interface, but most can't. You may think your interface ideas are just peachy, but in the end, they are a pain in the ass to the user. I like the way Windows does it. Most software has a similar interface. If your software really DESERVES a unique interface (like Truespace's which works wonderfully for the package, and since it is a major application, the quirks are worth learning) then you can take the time to code it. However, most software doesn't deserve a custom interface, because the increase in efficiency is by far offset by the learning curve. Who gives a damn if my AIM client has a perfectly tuned, custom interface?
I love it when people throw around the fact that the system waits for the user. When I am running 3D Studio, the system is certianly NOT waiting for the user. It is busting a gut to redraw the screen. I don't want my windowing system taking up 40MB of RAM that COULD be going to my rendering package. I don't want my GUI sucking up CPU cycles that should be going to my renderer. Or if I am background rendering, I don't want the GUI to steal those cycles. Sure I could run TWM, or turn the GUI off when I'm rendering, but damn it, I'm not blind! As a graphics person I LIKE pretty pictures. I can tell you that Windows does a lot more with hardware than Linux plus X can. To get the same features as Win95, you have to run Linux + X 4.0 + KDE 1.91 (sure you could use TWM, but it doesn't have anything like COM, or embedding, or the cool features in Win95) A 486/33 will run Win95 decently, but will puke on the equivilant Linux configuration. Sure, you can pare Linux down, but why bother competing if you can't compete with an equal feature set?
QNX is available on... MIPS, PowerPC, and x86.
Very little of QNX is written in assembler. The bloody thing runs on almost as many architectures as Linux, without the 50 million (exaggerated of course) coders that Linux has. Without a portable code base, that wouldn't be possible. A lot of OSs do that. For example, BeOS can fit into less than a 16 meg permanent disc (sans some features of course) its just that the code base is really small, (around 1.5 M lines) not any assembler tricks or anything (most of BeOS is C and C++)
Actually the 9-3 drivers have been released by NVIDIA, and they are actually pretty stable. BeOS doesnt support GeForce-based cards as NVIDIA refuses to give them specs. You can get color VESA support, but that's about it. (And yes, I do support NVIDIA's desicion to not give BeOS drivers. Kind of senseless to try to support and OS that actually has less users than Linux. Also, the BeOS driver model is quite a bit different from Linux or Windows, so I suspect that they really don't want to go to the trouble to make real BeOS drivers. However, I do question their judgement on not giving BeOS the specs under NDA. Since all NVIDIA cards have a similar driver interface (courtesy of the universal NVIDIA driver architecture) it should be short work for Be to cook up drivers based on the existing TNT driver source.
Its silly to ever use manufactuer supplied drivers. Most often they are just nVidia's reference drivers with some cosmetic hacks. (And NVIDIA's default look is a lot nicer looking at that.) Additionally, the reference drivers tend to be much higher quality, and more importantly, they come out a month or two before the manufactuerers get it into their driver builds. I used to stick with standard drivers, but then realized I was eternally 2 or 3 driver builds behind. Thus, every possible driver on my computer is now reference.
Now after Microsoft goes on their Jihad against warezers trying to take down all illegal copies of their programs, you can consult these archives to find some choice applications.
NT was designed with a driver architecture. WDM is not it. Even if all NT driver development have shifted over to WDM, it is still not the optimal driver architecture for NT. The architecture that was originally designed to support the original driver API is not easily changed, thus WDM is sort of a bolt-on API for both Win98 and NT. Same thing with DirectX. DirectX is also a bolt-on API to NT, and thus will never be as good as an API around which the NT architecture is designed. Its probably less of an issue for DirectX, because it really just shoves the OS out of the way, but a non-native driver API can cause some performance problems. Maybe the new WDM model is MSs move to make NT a little more general. However, the NT 3.x architecture is still mostly present in Windows 2000. That architecture was designed mostly for performance, thus any discussion of the Windows 2K architecture should still make sense if you talk about the NT 3.x docs. Also, Win32 calls aren't wrappers. Win32 applications make Win32 calls to a user-space Win32 server. The server then communicates with the kernel and kernel level subsystems (via the NT native API and message passing) to implement these calls.
I don't know about you, but astronomy IS often about the telescope. A lot of astronomers really love their field, and for feel just as exited about a cool telescope as computer nerds feel about a cool computer. In any field, there will be a bond between man and tool. A carpenter takes care of his saws and chisels, a race car has a bond with is car, an athelete cherishes certian pieces of equiptment. Computing is just like any other field in that respect. Sure, there are carpenters who could care less about the tools and the profession and simply does it for a job, but in all fields, a great many people actually like what they do, and liking the equiptment that they use is often a part of it. So yes, a lot of computing may become more about the net than the computer itself, but a large number of computer users will still care about the elegance of the environment they're using, and the niftyness of the latest hardware or software. These people aren't necessarily only the nerds. In all computing areas there are people who simply like an OS or a system of its elegance. NeXT users are smitten by its elegance, MacOS users love its creative aspect, and BeOS users tend to be quite obsessive about their OS. Even Windows users can get attached to the raw power of DirectX.
Okay, now you're into debatable territory here. From my point of view, NT is a microkernel. Yes it runs most services in user space, and the servers in NT are conglomerated into the executive. However, they are still seperate entities, and communicate by message passing. In my opinion, taht constitutes a microkernel.
Having high-performance I/O is a good thing. I think you misunderstand me, I really do like NT, in fact I use it about as often as I use BeOS. I was responding to your comment that NT was designed to be extendible over being high-performance. As for my backing up that NT is tuned more for performance than flexibility, I kind of explained that in the next paragraph, (running services in kernel mode, DirectX in the HAL, etc.) Even if WDM is the "official" driver API for NT, it is still not the native API. Win32 is the official API for NT, however it is not the native API. If you really want to see your applications perform as well as they can you'd use standard NT drivers, and the NT Native API. Neither are sanctioned by MS, but this is a technical discussion, not a political one. The truth is, that MS had to heavily endorse WDM because it needed drivers for NT. Even if it isn't the fastest way to do it on NT, that's the one they had to support. And I think the whole point of the WDM is that drivers should be cross compatible, except for video drivers (which aren't written to the WDM.) I think integrating DirectX into the HAL is a good idea. However, it is quite a complex system for something in the HAL, and does introduce bugs and make the system less "clean" from an acedemic point of view. I was using this point to support my assertion that NT is more tuned for performance then generality. Instead of adding a more general HAL bypass system, they chose to simply allow DirectX to pass through. NT does run a lot of services in kernel mode. In other microkernel OSs, there is no executive. Stuff that is in the NT executive (like I/O managers, etc) traditionally run in user mode. However, by running these in kernel mode, NT gains a performance increase. Also, that is one reason why NT blurs the lines between a monolithic and micro kernel. And I'm pretty sure NT is a microkernel. NT was designed as a microkernel, and its subsystems communicate by passing messages. (If it walks and quacks like a microkernel...) However, the design concessions (for performance) that MS made, made it much more of the "macrokernel" that MS holds it is today. However, if you read the documentation from NT 3.0 or 3.1, you'll see that it is billed as a microkernel.
No matter what your intent is, you write for Windows first. Whatever thing you use, the system that the program was one first will be the better port. Thus, if you care about your customers you write to Windows because your customers (statistically) all use Windows. If you care about selling software, you write to Windows, because (again) your customers are using Windows.
You don't :) Without basing the system API on something like COM (like DirecX does) it isn't really feasible to upgrade the API. However, I think the UNIX way to avoid it is to simply add a new API. Take a look at all the baggage APIs in Linux. You have POSIX, you have some SystemV APIs you have X, you have GNOME, you have Motif, you have KDE, you have TK, TCL, ncurses, ad nauseum.
Actually it wouldn't. DirectX in Windows 2000 is unadultered, bonafied, wholesome, god-given, 100% pure DirectX. Without the superlatives it means that DirectX on Win2K bypasses the HAL so it works similarly to the one in Win9x. However, Linux doesn't offer this kind of direct access so those games that depend on it won't run.
Maybe because Office is better than all the native applications? Office is better than Applix, AbiWord, etc, and most parts of it are better than WordPerfect Suite (except word.)
He's kind of saying that it is useless to feel strongly about *software* And that guy doesn't seem to feel THAT strongly, since he is running a windows machine at all. You have to be pragmatic about these things. If you feel so strongly about not running Windows, then I'm sure you have the willpower to simply not play Diablo 2.
Let's see. Most MacOS users are smarter than you'll ever be judging by the stupidity of your comment. And as for MacOS itself, when another operating system comes near to the power of MacOS for destktop publishing and art, then please let me know. Meanwhile, I think the MacOS users will be sitting there enjoying an inredible imaging engine (Display PDF) with color matching, flexibility and special effects that other OSs can't touch.
Okay, if you optimize your card (aside from just outright reporting false numbers) so that it runs Quake and Unreal faster, then you just sped up 90% of the games out there that similar algorithms. Even if you just speed up QuakeII, you've sped up all the games based on that engine. Manufacturers can't do that because it requires optimizing the whole driver, which is actually legitimate! Also, real world benchmarks are harder to fudge. If you do something to a driver that makes Quake run faster, than chances are that driver also makes all the other 3D games run faster. That's even more relevant for serving. I proposed a benchmark where the test emulates real-world conditions. IE, the script reflects how a person would actually use the system. If vendors do something to optimize for it, then they'd be optimizing real world usage. That's a good thing.
I was kind of kidding about that ;) I was talking about stuff like what Megabyte did with their Voodoo2 card. They wrote drivers that accelerated part of the Direct3D geometry pipeline. However, no games at the time actually used the geometry pipeline, except (curiously!) WinBench3D! The cheats don't really cause stability faults. More often, they are sections in the driver that detect certain types of benchmark code, and then optimize for it. Or they do what NEC did with PowerVR. At some point, the PowerVR drivers simply detected WinBench and returned artificial numbers! I was kind of pointing out that it is hard to cheat on benchmarks like Quake.
NT "runs all its servers in kernel space"? Do you mean drivers? Services? Services are not run in
kernel space, althougth they can be set with a high priority. All drivers are run in kernel space,
though.
>>>>>>>>
NT is a microkernel operating system. In microkernel OSs, servers are processes that provide system services such as networking, I/O, graphics, RPC, etc. In some cases, servers even provide memory management. In most microkernel OSs, these servers are in user space. However, in NT, they run in kernel mode. It's true that drivers run in kernel space, but so do the subsystems that load the drivers. This is a significant difference to most microkernels which have servers and large parts of drivers in userspace. BeOS for example has all servers in userspace, and most drivers are loaded by the kernel. IBM's experimental WorkPlace OS, on the other hand, put drivers mostly in userspace and even put services such as paging in user space. This tended to have a performance hit, and NT avoids it by running servers in kernel mode, even though that is riskier.
"The kernel has a lot of design concessions that faccilitate a really high I/O rate." Really? Have you
looked at the code for network and storage?
>>>>>>>>
No, but I have looked at design documents that detail the NT architecture. NT was designed for VERY high performance I/O.
I have written network and storage drivers for NT4/
Win2k and is not designed to be fast. Check out the DDK. Both storage and network use a miniport
model (SCSI Miniport and NDIS Miniport) with a port driver doing much of the work. To make
matters worse, Win2k use WDM for its drivers. WDM tends to add an additional driver object to
the layered model. Both miniport and WDM are designed to be very general and take control away
from the driver developer. A call to read a few bytes from the disk goes through so many layers.
First, the file system drivers, then class.sys, then disk.sys, then scsiport.sys, then
vendorscsiminiport.sys, then hardware. There can also be any number of filter drivers in the mix.
WDM allows upper and lower filters for each FDO (Functional Device Object). We got a nice
performance boost by not using the SCSIMiniport/Class driver interface. Win2k is not designed to
be fast as much as extendable and general.
>>>>>>>>>>
Win2K is definately not designed to be extendible and general. While WDM may add a lot of overhead to the driver interface, that is not NT's native driver model. Microsoft added WDM to allow drivers for Win98 to work on NT. Also, you cannot deny that the architecture is tuned more to high performance than generality. A lot of critics of NT complained that the architecture was "academically dirty." Meaning that a lot of design desicions resulted in a faster but less clean system. For example, Windows 2K has DirectX class integrated into the HAL. Very unclean. NT also runs all services in kernel mode. Again, unclean. The NT microkernel globs up a lot of services that should be in the servers, which furthers performance, but makes the microkernel less general and less extendible. It runs the windowing system in kernel space! How general and extendible is THAT? NT does have a lot of management overhead, true. But it is also designed for raw performance. If you're not changing anything (ie. simply streaming data of a disk while not doing anything else) it is really fast.
That could also be a problem. Processes take more time to start than a thread does. Also, it still doesn't mitigate the fact that the TCP/IP stack is single threaded so THAT can stall.
Okay, I get it, thank you very much for the explanation.
First, let me say, that benchmarks like this are useless. I'm not against benchmarking, mind you, but what I AM against is artificialy benchmarks. For example, in testing 3D cards, ZDN still uses an artificial benchmark called WinBench3D. Of course, manufacturers with no morals (ATI, Megabyte, Intel) can optimize for these types of benchmarks, and thus seem faster than they are. However, if you do a real world benchmark, like say test the FPS in Quake, you're results are actually valid. If a manufacturer cheats so their card runs actual games faster, then thats actually a good thing. What I'd like to see is a real world server benchmark. Maybe set up a COM+ simulation where actual COM+ applications (for example a database) does actual requests on the server, then measure how many clients the server can handle. Or do something like have the server serve up a database and have scripted clients access the database in a real manner. Those are the kinds of benchmarks that really work, but unfortuenatly, they take actual work. As for NT beating Linux, remember that NT is designed to run stuff like this. Though NT is a microkernel, it rusn all its servers in kernel space (though Linux does as well, I think). Also, the kernel has a lot of design concessions that faccilitate a really high I/O rate. There not so good for doing real world tasks, because the OS tends to step on its own toes, but if you testing raw performance, NT usually wins. But these performance enhancements take their toll on stability and ability to handle high loads. For example, in Windows2K, DirectX has some interface calls implemented into the hardware abstraction layer, which really speeds up performance, but at the cost of stability. That said, WindowsNT really IS a decent OS, and some parts are simply better designed than their conterparts in Linux. For the desktop, (if you have the RAM), W2K is perfectly stable (because most desktop users reboot at least once every few days) and nicely supports media. Also, Win2K has a good multi-threaded TCP/IP stack that was rewritten from NT4. Despite its faults (ahem bloat) it does actually have some features that the Linux guys would be wise to look into. (ahem, COM) W2K is nowhere near being the end-all be all of OSs, but neither is Linux. They both have their flaws, and NT has actually improved enough that W2K actually has some uses in the server role! Anything doing small transactions that doesn't need to be particularly stable (for example DNS) would be served well by NT which responds well to little transactions like this.
For those who are complaining about them using an "old" version of Linux, get over it. The 2.4 kernel is not only still experimental, it is not in any distro yet. As for the system software being at 6.1, again it doesn't really matter because RedHat 6.2 (The latest from the "Linux company," at least as far as the mainstream is concerned) only contains a few tweeks, and is really not much of an upgrade.