You have to compare similar performance and processes. Alphas, like any RISC, are much more efficient than x86, no matter what Apple and Intel tell us.
What's particularly ironic about the old CISC vs RISC wars, is that it was RISC that held the promise of quick ramping and ultra-high clock speeds...
RISC was never about high IPC (or "efficiency" if you prefer), RISC was about high clock speeds and lots of registers.
No, the problem is that most of the market was running Windows 9X, which was not remotely forward-looking in any shape or form.
That's because it was only ever meant to be a temporary, throw-away piece of software meant for transitioning away from DOS and DOS-based Windows. The original plan was for Windows 98 (and later) to never even exist, but people just wouldn't stop writing software that broke under NT. It didn't need to be "forward looking" because it was only ever supposed to exist for a few years.
Thus, while many developers were using NT Workstation because it didn't fall over when debugging, loading the IDE, sitting there for an hour doing nothing, etc., market realities meant that they still had to target Win9X, despite the fact that many of them loathed it with a passion. And guess what? Nearly five years after the release of XP, a lot of us still have to target sodding Win9X, because significant numbers of people are still running the blasted thing.
There's no reason you can't write software for Windows 98 that works fine on NT as a non-Admin user. Windows 9x has supported per-user profiles and similar since the OSR2 release of Windows 95 in 1997 (certainly it can't actually restrict cross-user access, but that's no reason for not storing everything per-user in the appropriate place).
"But it has to run on Windows 9x" hasn't been a real excuse for software that doesn't play well with NT for a _very_ long time.
You don't need root on a Mac to do this - only admin and admin is not root. My root on my Mac is disabled and I do just fine.
No, the root account can't login - that doesn't mean code can't run as root.
Whenever you type in your "admin password", the subsequent code is running as root.
Or, in other words, you do "need" [0] root to be able to install software.
[0] That said, strictly speaking you _don't_ need root to install software, because the "admin" group (which the average OS X user account is a member of) has write permissions to/Applications - so it's quite possible for an app install to work (if the current user is an admin) without having to raise its privileges to root by prompting for an admin user. Most just do it regardless, however.
The roots of that lie in the past of Windows as an extension to MS-DOS, where things like a proper distiction between admin and user did not exist.
No current version of Windows was ever an "extension to MS-DOS".
As a result, lots of software was written by developers who could assume their creations would have admin-like access and did not bother to plan for a more restricted future.
And they've had no justification for not "planning for a more restricted future" since about 1996.
Including some sloppiness by Microsoft itself, consider Internet Explorer being linked deeply into the OS.
Internet Explorer is no more deeply linked into Windows than khtml is into KDE or glibc is into Linux. It's the equivalent of a shared library, nothing more.
Now, Microsoft tries to get away from that sloppy model but has to do it slowly, lest they annoy too many customers by making their applications unusable. I expect that it will take another five years until Windows is really cleaned out.
The "model" of Windows isn't likely to change dramatically any time soon, nor does it need to.
Let's see. In order to get the GUI to perform at a reasonable speed, they had to integrate it into the kernel.
Actually they ran it in _kernel space_, there's a difference.
Not to mention this is hardly an unreasonable step to get decent performance out of hardware in the era of 33Mhz 486s with ISA-bus video cards. What OS are you thinking of that did it with a better design then (or now, come to think of it) ?
In order to get the Web Services (IIS) to perform at a reasonable speed, they had to integrate it into the kernel.
No, they moved one small part of IIS - the HTTP listener - into kernel _space_. Not the whole thing, and certainly not "integrated into the kernel".
And it wasn't to "perform at a reasonable speed", it was to perform at a *high* speed.
It appears that in order to get certain types of applications to run with any kind of acceptible response times, that it has to be dropped into the kernel.
False.
That would appear to be one area that shows jury-rigging (or cobbling together) at least.
Hardly. A perfectly reasonable tradeoff between the theory and design of a microkernel OS and real-life requirements.
Odd - it seems to point out the issues with applications having to be placed into the kernel to get decent response times out of them.
Well I can't read the first article, but the conclusions you've managed to draw - where they aren't outright wrong - are extremely questionable.
The second article - if you ignore the first dozen or so lines of dodgy comments and move onto the material from People With A Clue - doesn't really talk about anything relevant to this discussion.
You might care to note, however, from Cutler's discussion of the design goals of NT, that high performance was not a criteria. Hence the need for minor deviations from the original design to get high levels of performance from certain components.
I'll agree to that statement - with one exception - Millions of people managed to use them in production for one application per server. ie - if you wanted a PDC, a file server, a print server, an Exchange server - you needed to build 4 seperate windows servers. That was per Microsoft's recommendations btw.
That's preferred practice in any environment that isn't mini or mainframe.
Their OS couldn't run responsively (ie switching execution threads) with multiple heavy use applications running on it.
Compared to what ? On what hardware ? Running which applications ?
Nowhere near as much (I'm assuming here by "Linux" you mean "people writing open source software for Linux).
Sure you are more likely to have something break in Linux after a patch, but usually a few hours or a day later you have a patch for the program that got broken so it works properly again [...]
While Dave Cutler designed a nice, highly-modular system in Windows NT, the newest versions of that OS are a far cry from Cutler's original design. Everything is tightly integrated and various system components do many many different things these days. So when changing one component, Microsoft programmers have to way that change against the rest of the system and all of the software that relies on that component.
I don't think "modular" and "integrated" mean what you think they mean.
Combined with truly standards-based interfaces between components, [...]
What standards are you thinking of ? Pipes and ASCII text ?
[...] this means that patching a particular component is far less likely to break lots and lots of other things.
You think ? Try breaking glibc to see how little impact it has. Even less commonly used (relative to glibc) components like qt or gtk++, if broken, would bring down thousands of applications in their wake.
And if someone who wrote an application wrote it in such a way that it depends on the buggy behaviour -- well, shame on them.
This sort of attitude - while common in the OSS world - is not sustainable in the commercial world.
I used to work for a *NIX vendor where the usual procedure was to offer a workaround to plug up the security hole. The patch was then developed and sent off for testing from where it would sometimes return for a rework because it caused unexpected problems in some other part of the OS.
How long ago ? What were your userbase demographics like ?
With all that crap, isn't it time you thought about another operating system?
Seems to me he's following the same procedures any sensible person would _regardless_ of the OS - run as a limited user, avoid buggy software and don't execute code from questionable sources.
You have never dealt with the FOSS software world have you?
Seeing how my job is a sysadmin, I get to deal with it every day.
If you had you would know your statement is total CRAP. The premise is FOSS can be reused, extended and IMPROVED by the joint work of the community. It's not at all about breaking things.
I never said it _was- about "breaking things", I said the OSS community's solution to backwards compatibility is generally to ignore it ("because they can just [patch and] recompile again"). Example A: the multitudes of Firefox plugins that break with every release. Example B: every new kernel release breaking existing hardware drivers.
No financial consequences?
Yes. This is why so few people in the OSS community care, becaue most of them work under two assumptions:
1) People using their software are getting it for nothing, so if it breaks then they haven't really lost anything
2) Everyone else thinks like they do and thus are only using open source - so if their fancy new app A.0 requires library B.2 and most users only have B.1, it's no sweat because they can just download the new library B.2 and install it. Likewise the developers of Library B.1 don't care if their upgrade B.2 breaks a bunch of existing software, because the "OSS community" will patch the software and the end users can just download and install the latest version.
Ie: There are no financial consequences for their fuckups and bad habits. This sort of attitude and approach is *rife* within the OSS community and probably the single biggest reason for its slow take-up rate and low level of support amongst commercial vendors.
Novell, RedHat, Sun don't have to worry about consequences of the open source OSes (SUSE, RHEL, and Solaris) and software (JES) they sell? They most certainly do if they want to stay in business!
Yes they do, which is why they expend so much money and effort trying to keep OSS code written by the typical cowboys stable. Novell, Sun, Red Hat et al are not representative of the OSS community, they're the exceptions to the rule. If *only* the rest of the OSS community followed the practices and standards of commercial operations like Sun, Novell, Red Hat, Microsoft or IBM, the world would be a better place.
When I was a CS Student many moons ago, the IBM OS360 and the VAX/VMS code was what we studied in our OS classes. That is at least as complex as Windows.
I doubt it. No GUI, for starters, and that's before even getting into things like the 16 bit compatibility layers.
However, the basic concepts of OSes can be studied using most any multi-tasking OS as an example.
Indeed they can. Your point ?
There are lots of reasons to see the source code of something you are interfacing too.
Yes, and almost all of them are going to result in you writing worse code.
Optimization of the interface comes to mind. If the interface is called 1000 times a minute then saving time in the code, and space on the stack/memory by sending only the minimum of data can be useful. Knowing if the routine you are calling is changing the data you send it via parameters, knowing if the routine blocks, knowing if it calls 7 other routines. The more you know the better code you can write. Instead of trusting the API to be right, you can look at the code and KNOW it is right.
So you're suggesting that optimising your code based not on the documented and supported behaviour of an API, but how one specific implementation of it behaves, is a good idea ? Or are you suggesting that writing an application that relies on your modifications to someone else's code to run is a good idea ?
Windows NT was NOT designed from the ground up to be a multi-user OS. It was to be more network aware and to support the full 32 bit model on the Intel chips. It did include some enchanced security concepts but it was still able to run older Windows programs so it was NOT a blank sheet
Perhaps you have me confused with the parent to this sub-thread.
Quite possibly. But since you go on to agree with him, it all works out in the end.
I was just providing reading material that shows a few minor facts.
Trouble is, it doesn't show any relevant (or disputed) facts.
NT is poorly designed.
Why ?
In fact it wasn't designed (from the ground up) at all. It borrowed(depending on your use of the term borrowed) heavily from VMS, [...]
NT was designed and written from scratch by the same team who designed VMS when Microsoft gave them a blank cheque after hiring them awat from DEC. It's hardly surprising they have very similar architecture.
[...] and then was jury-rigged to float a GUI on top of it.
What "jury rigging" are you talking about ? Why would any remotely well-written OS even need any sort of "jury rigging" just to run a GUI ?
With the problems the OS had from the initial release, as well as all subsequent Windows OS releases, you can tell that NONE of the Windows OS releases were ready for production use. They may have been written, and then later used for production, but none of them were actually ready for production when released.
Funny, millions of people managed to use them in "production".
Rather deceptive message if Windows (3.2?) was loaded on top of DR DOS.
Actually it was only displayed in _beta_ versions of Windows if it detected a non-Microsoft DOS (not just DRDOS) running. No shipping version of Windows displayed the warning.
If you can't see any valid technical reasons why something like Windows 3.x - which relied on and modified internal, in-memory data structures of DOS while it was running - would need to know exactly what the characterisics of the DOS it was running on top of were, I don't think you're trying very hard.
There is a rather thick book of PC interrupts. Microsoft is hardly the only one using undocuments system features.
The "rather thick book" part would suggest they _are_ documented.
I would be extremely surprised if with windows, everything used was documented and documented correctly and that documentation was accessible externally.
So would I, but it's a long way from the odd bit of undocumented API usage here and there, probably in legacy code that's been floating around for 15 years, to the "Microsoft use undocumented APIs so their software works better than everyone elses" meme.
As I said, I am waiting for even a single example of a Microsoft application using an undocumented API to gain any sort of functional advantage over competitors.
Now, whether any of it or not is factual, I cannot determine with any certainty, but there are certainly some clues to be found, and some items that make you go Hmmmm.
You have provided zero evidence to support your claims that:
* Windows NT is poorly designed.
* Windows NT was written as a "test bed for new technology"
* Windows NT wasn't written for production use
There is no argument Windows NT and VMS have very similar architectures. They were both designed by the same development team. But that's completely irrelevant to the claims you have made.
I don't understand.. lots of FOSS has extension/plugin architectures and have to deal with the same issues..
No, they don't, because the OSS solution is to _not_ try to deal with the issue and just break software.
however, I don't see FOSS developers catering to individuals/companies that elect NOT TO PROGRAM to established APIs.
Yes. That's because they don't have any financial consequences to worry about. The lack of any real efforts towards binary compatibility in the OSS world is well known, particularly with regards to Linux (the kernel).
It seems like even companies such as Apple tend to have the same view point.. this seems like a Microsoft-ism.. I'm guessing its due in part to the fact that they themselves utilize many undocumented internals.
Cite some specific examples.
Thats crap. First, if this code was available, it could be utilized by thousands of CS students as a learning tool (and thus additioanl eye-balls checking out the code).
Ignoring for a second that many educational institutions have access to the Windows source code, how many CS students do you think are going to be able to gain a meaningful and in-context grasp of the Windows source code ?
In addition to this, there are LOTS of companies that develop for Windows. If something doesn't function properly, don't you think that these individuals would LOVE to get into the source to see whats going on?
Also ignoring that companies can access the Windows source if they're prepared to pay for it, there's no reason for decent developers to need access to the source when they have a documented API to use.
Sure, it might be a very small portion of the source, but nevertheless, being able to get in there to analyze/understand/adapt and report bugs goes a long way.
It also encourages the use of undocumented/deprecated APIs, leading on to the requirement of ugly compatibility hacks in future versions of the OS to avoid braking existing software.
Needless to say, Windows was designed as a non-networked, single user system.
False. Windows NT was designed from the ground up to be a networked, multiuser OS.
Unsurprisingly, given your basic assumption is wrong, your conclusions are flawed.
Do you really think some Microsoft munchkin will resist the opportunity to use some specialized knowledge or hook into the system to make him or herself look better to his or her supervisors?
I'm pretty sure he wouldn't risk his job.
Third party software tends to be a wee bit more paranoid about having the rug pulled out from under them, so the scope of what an exploit would be able to do tends to be rather smaller.
Say what ? Third party apps tend to be the _worst_ offenders in terms of using undocumented APIs and ignoring best practices. There are thousands of ugly hacks and workarounds Microsoft have in place so that broken software continues to run on current versions of Windows.
Any DLL shared between Microsof apps that is not know/used by third-party apps is a refutation of your argument.
So list them.
I am waiting for even a single example of a Microsoft application using an undocumented API to gain any sort of functional advantage over its competitors.
If these programs don't act as gateways to some of the highest levels of the OS how could a "Standard User" account (with no write access to most of the HD) load software that loads several system services (running as "SYSTEM") on a fully patched 2000 SP4 desktop, write endless entries in the registry so every time "ANY" folder/.exe is opened the programs are re-installed again??
it can't.
I have personally witnessed this on more than a few occasions and there was NO download/open dialog, NO warning, NO Nothing being generated to turn a working machine 5 minutes later in to Spyware/Adware/Pop-up HELL eating every available CPU/MEM resource and downloading/installing everything on the Internet it could connect and get it's hands on!
Microsoft made the choice to tie things closely to the OS. In particular, their Netscape killing plan was to essentially make IE part of the OS.,P>For the entertainment of the crowd, canyou please expound on what "part of the OS" means to you.
Of course that is progress but the real problem with Windows is the fact that it carries a burden of bad design decision at a fundamental level made for all sorts of business and marketing reasons.
Which was ?
Why does a process like Microsoft Internet Explorer (Which is mainly a bigger gateway for malware than Firefox because it is badly written not becaue it is a Microsoft product) have to run with admin privileges?
It doesn't.
Come to think of it, why the hell does the normal Windows user even have to have Admin privileges for day to day work to begin with?
They don't if they're using properly written software.
Unfortunately MS has since learned the hard way that thinking ahead sometimes pays but now they are also learning that back-pedaling is hard work.
The design of NT was exceptionally forward-thinking. The problem is the lack of such foresight (or even just simple common sense) on behalf of application developers.
Their codebase is OLD, not to mention poorly designed. NT was written as kind of a test bed for new technology. It wasn't originally designed to be a production system.
That's might long bow you're drawing there, considering NT's design is probably one of it's strongest features and it was specifically written to replace the other OSes of the day (DOS, Windows, OS/2).
Do you have even the tiniest shred of evidence to support your claims ?
The PPC macs are not really obsolete for several more years [...]
p.The G4-based Macs have already been obselete for a couple of years - they just haven't been replaced yet.
I can't stand the 'lifestyle trap' that Australians think they have a God-given right to. Australia never, ever belonged to whitey.
Nice to see your racist colours shining through.
To my Australian compatriates, I say, get the hell out of town and live a little.. your lifestyle is the problem. The world needs you to leave.
Huh ? One of the big problems in Australia is there are _too many_ skilled people leaving the country because the wages are relatively low and taxation is relatively high.
Actually this is pervasive in Australia...you need reference letters from people who have known you for 2 years to get a bank account, a mortage, opening a business, whatnot.
Rubbish. For the first you need 100 points of ID (for the non-natives, a passport and birth certificate are worth about 50 or so each, drivers license about 30, credit card about 10). For the second you need 100 points of ID and the last few months worth of paychecks. The third I can't comment on.
It's been *ridiculously* easy to get a mortgage in Australia for the last 5 - 8 years (something that has the potential to come back and bite the banks _hard_ if the economy goes south). Heck, there are places who'll give you a mortgate if you just tell them you're self-employed and earning enough.
To rent a place, you need to give the past 2 or 3 addresses you've been.
Maybe if you're an unemployed nineteen year old who looks like he just walked out of a hippy commune. I moved to Sydney about 3 years ago and knew no-one, but since I had a letter from my employer stating I was starting full time work the following week and dressed neatly when I went looking, I was moving into a new place in a matter of days - and I'd never rented before in my life.
Finally, examine the tax situation before you move in any case!
This is good advice. Taxation here is relatively high, even taking into accounts the services benefits it delivers. OTOH, outside the rat-race insanity of Sydney or Melbourne, it's a really nice, laid-back place to live.
Slashdot Mirror
What's particularly ironic about the old CISC vs RISC wars, is that it was RISC that held the promise of quick ramping and ultra-high clock speeds...
RISC was never about high IPC (or "efficiency" if you prefer), RISC was about high clock speeds and lots of registers.
How many security problems has Windows 2003 had ?
I guess the XP firewall is on by default since SP2. I can't think of anything else, however.
Most of the system has been recompiled to thwart buffer-overflow style attacks.
Still, just what do you propose they do to "fix" all the Windows XP machines out there ?
That's because it was only ever meant to be a temporary, throw-away piece of software meant for transitioning away from DOS and DOS-based Windows. The original plan was for Windows 98 (and later) to never even exist, but people just wouldn't stop writing software that broke under NT. It didn't need to be "forward looking" because it was only ever supposed to exist for a few years.
Thus, while many developers were using NT Workstation because it didn't fall over when debugging, loading the IDE, sitting there for an hour doing nothing, etc., market realities meant that they still had to target Win9X, despite the fact that many of them loathed it with a passion. And guess what? Nearly five years after the release of XP, a lot of us still have to target sodding Win9X, because significant numbers of people are still running the blasted thing.
There's no reason you can't write software for Windows 98 that works fine on NT as a non-Admin user. Windows 9x has supported per-user profiles and similar since the OSR2 release of Windows 95 in 1997 (certainly it can't actually restrict cross-user access, but that's no reason for not storing everything per-user in the appropriate place).
"But it has to run on Windows 9x" hasn't been a real excuse for software that doesn't play well with NT for a _very_ long time.
No, the root account can't login - that doesn't mean code can't run as root.
Whenever you type in your "admin password", the subsequent code is running as root.
Or, in other words, you do "need" [0] root to be able to install software.
[0] That said, strictly speaking you _don't_ need root to install software, because the "admin" group (which the average OS X user account is a member of) has write permissions to /Applications - so it's quite possible for an app install to work (if the current user is an admin) without having to raise its privileges to root by prompting for an admin user. Most just do it regardless, however.
No current version of Windows was ever an "extension to MS-DOS".
As a result, lots of software was written by developers who could assume their creations would have admin-like access and did not bother to plan for a more restricted future.
And they've had no justification for not "planning for a more restricted future" since about 1996.
Including some sloppiness by Microsoft itself, consider Internet Explorer being linked deeply into the OS.
Internet Explorer is no more deeply linked into Windows than khtml is into KDE or glibc is into Linux. It's the equivalent of a shared library, nothing more.
Now, Microsoft tries to get away from that sloppy model but has to do it slowly, lest they annoy too many customers by making their applications unusable. I expect that it will take another five years until Windows is really cleaned out.
The "model" of Windows isn't likely to change dramatically any time soon, nor does it need to.
Actually they ran it in _kernel space_, there's a difference.
Not to mention this is hardly an unreasonable step to get decent performance out of hardware in the era of 33Mhz 486s with ISA-bus video cards. What OS are you thinking of that did it with a better design then (or now, come to think of it) ?
In order to get the Web Services (IIS) to perform at a reasonable speed, they had to integrate it into the kernel.
No, they moved one small part of IIS - the HTTP listener - into kernel _space_. Not the whole thing, and certainly not "integrated into the kernel".
And it wasn't to "perform at a reasonable speed", it was to perform at a *high* speed.
It appears that in order to get certain types of applications to run with any kind of acceptible response times, that it has to be dropped into the kernel.
False.
That would appear to be one area that shows jury-rigging (or cobbling together) at least.
Hardly. A perfectly reasonable tradeoff between the theory and design of a microkernel OS and real-life requirements.
Odd - it seems to point out the issues with applications having to be placed into the kernel to get decent response times out of them.
Well I can't read the first article, but the conclusions you've managed to draw - where they aren't outright wrong - are extremely questionable.
The second article - if you ignore the first dozen or so lines of dodgy comments and move onto the material from People With A Clue - doesn't really talk about anything relevant to this discussion.
You might care to note, however, from Cutler's discussion of the design goals of NT, that high performance was not a criteria. Hence the need for minor deviations from the original design to get high levels of performance from certain components.
I'll agree to that statement - with one exception - Millions of people managed to use them in production for one application per server. ie - if you wanted a PDC, a file server, a print server, an Exchange server - you needed to build 4 seperate windows servers. That was per Microsoft's recommendations btw.
That's preferred practice in any environment that isn't mini or mainframe.
Their OS couldn't run responsively (ie switching execution threads) with multiple heavy use applications running on it.
Compared to what ? On what hardware ? Running which applications ?
Nowhere near as much (I'm assuming here by "Linux" you mean "people writing open source software for Linux).
Sure you are more likely to have something break in Linux after a patch, but usually a few hours or a day later you have a patch for the program that got broken so it works properly again [...]
And that's the problem it produces.
I don't think "modular" and "integrated" mean what you think they mean.
Combined with truly standards-based interfaces between components, [...]
What standards are you thinking of ? Pipes and ASCII text ?
[...] this means that patching a particular component is far less likely to break lots and lots of other things.
You think ? Try breaking glibc to see how little impact it has. Even less commonly used (relative to glibc) components like qt or gtk++, if broken, would bring down thousands of applications in their wake.
And if someone who wrote an application wrote it in such a way that it depends on the buggy behaviour -- well, shame on them.
This sort of attitude - while common in the OSS world - is not sustainable in the commercial world.
How long ago ? What were your userbase demographics like ?
No, the problem is it takes time.
Much like you can't produce a baby in a month just by getting 9 women in the same room.
Seems to me he's following the same procedures any sensible person would _regardless_ of the OS - run as a limited user, avoid buggy software and don't execute code from questionable sources.
Seeing how my job is a sysadmin, I get to deal with it every day.
If you had you would know your statement is total CRAP. The premise is FOSS can be reused, extended and IMPROVED by the joint work of the community. It's not at all about breaking things.
I never said it _was- about "breaking things", I said the OSS community's solution to backwards compatibility is generally to ignore it ("because they can just [patch and] recompile again"). Example A: the multitudes of Firefox plugins that break with every release. Example B: every new kernel release breaking existing hardware drivers.
No financial consequences?
Yes. This is why so few people in the OSS community care, becaue most of them work under two assumptions:
1) People using their software are getting it for nothing, so if it breaks then they haven't really lost anything
2) Everyone else thinks like they do and thus are only using open source - so if their fancy new app A.0 requires library B.2 and most users only have B.1, it's no sweat because they can just download the new library B.2 and install it. Likewise the developers of Library B.1 don't care if their upgrade B.2 breaks a bunch of existing software, because the "OSS community" will patch the software and the end users can just download and install the latest version.
Ie: There are no financial consequences for their fuckups and bad habits. This sort of attitude and approach is *rife* within the OSS community and probably the single biggest reason for its slow take-up rate and low level of support amongst commercial vendors.
Novell, RedHat, Sun don't have to worry about consequences of the open source OSes (SUSE, RHEL, and Solaris) and software (JES) they sell? They most certainly do if they want to stay in business!
Yes they do, which is why they expend so much money and effort trying to keep OSS code written by the typical cowboys stable. Novell, Sun, Red Hat et al are not representative of the OSS community, they're the exceptions to the rule. If *only* the rest of the OSS community followed the practices and standards of commercial operations like Sun, Novell, Red Hat, Microsoft or IBM, the world would be a better place.
When I was a CS Student many moons ago, the IBM OS360 and the VAX/VMS code was what we studied in our OS classes. That is at least as complex as Windows.
I doubt it. No GUI, for starters, and that's before even getting into things like the 16 bit compatibility layers.
However, the basic concepts of OSes can be studied using most any multi-tasking OS as an example.
Indeed they can. Your point ?
There are lots of reasons to see the source code of something you are interfacing too.
Yes, and almost all of them are going to result in you writing worse code.
Optimization of the interface comes to mind. If the interface is called 1000 times a minute then saving time in the code, and space on the stack/memory by sending only the minimum of data can be useful. Knowing if the routine you are calling is changing the data you send it via parameters, knowing if the routine blocks, knowing if it calls 7 other routines. The more you know the better code you can write. Instead of trusting the API to be right, you can look at the code and KNOW it is right.
So you're suggesting that optimising your code based not on the documented and supported behaviour of an API, but how one specific implementation of it behaves, is a good idea ? Or are you suggesting that writing an application that relies on your modifications to someone else's code to run is a good idea ?
Windows NT was NOT designed from the ground up to be a multi-user OS. It was to be more network aware and to support the full 32 bit model on the Intel chips. It did include some enchanced security concepts but it was still able to run older Windows programs so it was NOT a blank sheet
Quite possibly. But since you go on to agree with him, it all works out in the end.
I was just providing reading material that shows a few minor facts.
Trouble is, it doesn't show any relevant (or disputed) facts.
NT is poorly designed.
Why ?
In fact it wasn't designed (from the ground up) at all. It borrowed(depending on your use of the term borrowed) heavily from VMS, [...]
NT was designed and written from scratch by the same team who designed VMS when Microsoft gave them a blank cheque after hiring them awat from DEC. It's hardly surprising they have very similar architecture.
[...] and then was jury-rigged to float a GUI on top of it.
What "jury rigging" are you talking about ? Why would any remotely well-written OS even need any sort of "jury rigging" just to run a GUI ?
With the problems the OS had from the initial release, as well as all subsequent Windows OS releases, you can tell that NONE of the Windows OS releases were ready for production use. They may have been written, and then later used for production, but none of them were actually ready for production when released.
Funny, millions of people managed to use them in "production".
Actually it was only displayed in _beta_ versions of Windows if it detected a non-Microsoft DOS (not just DRDOS) running. No shipping version of Windows displayed the warning.
If you can't see any valid technical reasons why something like Windows 3.x - which relied on and modified internal, in-memory data structures of DOS while it was running - would need to know exactly what the characterisics of the DOS it was running on top of were, I don't think you're trying very hard.
There is a rather thick book of PC interrupts. Microsoft is hardly the only one using undocuments system features.
The "rather thick book" part would suggest they _are_ documented.
I would be extremely surprised if with windows, everything used was documented and documented correctly and that documentation was accessible externally.
So would I, but it's a long way from the odd bit of undocumented API usage here and there, probably in legacy code that's been floating around for 15 years, to the "Microsoft use undocumented APIs so their software works better than everyone elses" meme.
As I said, I am waiting for even a single example of a Microsoft application using an undocumented API to gain any sort of functional advantage over competitors.
You have provided zero evidence to support your claims that:
* Windows NT is poorly designed.
* Windows NT was written as a "test bed for new technology"
* Windows NT wasn't written for production use
There is no argument Windows NT and VMS have very similar architectures. They were both designed by the same development team. But that's completely irrelevant to the claims you have made.
No, they don't, because the OSS solution is to _not_ try to deal with the issue and just break software.
however, I don't see FOSS developers catering to individuals/companies that elect NOT TO PROGRAM to established APIs.
Yes. That's because they don't have any financial consequences to worry about. The lack of any real efforts towards binary compatibility in the OSS world is well known, particularly with regards to Linux (the kernel).
It seems like even companies such as Apple tend to have the same view point.. this seems like a Microsoft-ism.. I'm guessing its due in part to the fact that they themselves utilize many undocumented internals.
Cite some specific examples.
Thats crap. First, if this code was available, it could be utilized by thousands of CS students as a learning tool (and thus additioanl eye-balls checking out the code).
Ignoring for a second that many educational institutions have access to the Windows source code, how many CS students do you think are going to be able to gain a meaningful and in-context grasp of the Windows source code ?
In addition to this, there are LOTS of companies that develop for Windows. If something doesn't function properly, don't you think that these individuals would LOVE to get into the source to see whats going on?
Also ignoring that companies can access the Windows source if they're prepared to pay for it, there's no reason for decent developers to need access to the source when they have a documented API to use.
Sure, it might be a very small portion of the source, but nevertheless, being able to get in there to analyze/understand/adapt and report bugs goes a long way.
It also encourages the use of undocumented/deprecated APIs, leading on to the requirement of ugly compatibility hacks in future versions of the OS to avoid braking existing software.
Needless to say, Windows was designed as a non-networked, single user system.
False. Windows NT was designed from the ground up to be a networked, multiuser OS.
Unsurprisingly, given your basic assumption is wrong, your conclusions are flawed.
Right. I guess that's why Slashdot is littered with people complaining about the latest hotfix or service pack breaking all their software.
2) They don't submit their code for review by the public.
There is little evidence this philosophical issue makes any difference.
3) They don't follow security best practices, like turning off services by default.
There's not much listening after a default Windows 2003 install.
4) They make their OS less secure by obfuscating design to make it difficult for competitors.
Evidence ? Examples ?
5) They use propriety data formats.
More philosophy.
6) They alter the OS to make it work with their programs instead of designing a solid OS so that anyone can make programs run with it.
Evidence ? Examples ?
I'm pretty sure he wouldn't risk his job.
Third party software tends to be a wee bit more paranoid about having the rug pulled out from under them, so the scope of what an exploit would be able to do tends to be rather smaller.
Say what ? Third party apps tend to be the _worst_ offenders in terms of using undocumented APIs and ignoring best practices. There are thousands of ugly hacks and workarounds Microsoft have in place so that broken software continues to run on current versions of Windows.
Any DLL shared between Microsof apps that is not know/used by third-party apps is a refutation of your argument.
So list them.
I am waiting for even a single example of a Microsoft application using an undocumented API to gain any sort of functional advantage over its competitors.
it can't.
I have personally witnessed this on more than a few occasions and there was NO download/open dialog, NO warning, NO Nothing being generated to turn a working machine 5 minutes later in to Spyware/Adware/Pop-up HELL eating every available CPU/MEM resource and downloading/installing everything on the Internet it could connect and get it's hands on!
Show me some links to these sites.
Microsoft made the choice to tie things closely to the OS. In particular, their Netscape killing plan was to essentially make IE part of the OS. ,P>For the entertainment of the crowd, canyou please expound on what "part of the OS" means to you.
Which was ?
Why does a process like Microsoft Internet Explorer (Which is mainly a bigger gateway for malware than Firefox because it is badly written not becaue it is a Microsoft product) have to run with admin privileges?
It doesn't.
Come to think of it, why the hell does the normal Windows user even have to have Admin privileges for day to day work to begin with?
They don't if they're using properly written software.
Unfortunately MS has since learned the hard way that thinking ahead sometimes pays but now they are also learning that back-pedaling is hard work.
The design of NT was exceptionally forward-thinking. The problem is the lack of such foresight (or even just simple common sense) on behalf of application developers.
That's might long bow you're drawing there, considering NT's design is probably one of it's strongest features and it was specifically written to replace the other OSes of the day (DOS, Windows, OS/2).
Do you have even the tiniest shred of evidence to support your claims ?
The PPC macs are not really obsolete for several more years [...] p.The G4-based Macs have already been obselete for a couple of years - they just haven't been replaced yet.
Nice to see your racist colours shining through.
To my Australian compatriates, I say, get the hell out of town and live a little .. your lifestyle is the problem. The world needs you to leave.
Huh ? One of the big problems in Australia is there are _too many_ skilled people leaving the country because the wages are relatively low and taxation is relatively high.
Rubbish. For the first you need 100 points of ID (for the non-natives, a passport and birth certificate are worth about 50 or so each, drivers license about 30, credit card about 10). For the second you need 100 points of ID and the last few months worth of paychecks. The third I can't comment on.
It's been *ridiculously* easy to get a mortgage in Australia for the last 5 - 8 years (something that has the potential to come back and bite the banks _hard_ if the economy goes south). Heck, there are places who'll give you a mortgate if you just tell them you're self-employed and earning enough.
To rent a place, you need to give the past 2 or 3 addresses you've been.
Maybe if you're an unemployed nineteen year old who looks like he just walked out of a hippy commune. I moved to Sydney about 3 years ago and knew no-one, but since I had a letter from my employer stating I was starting full time work the following week and dressed neatly when I went looking, I was moving into a new place in a matter of days - and I'd never rented before in my life.
Finally, examine the tax situation before you move in any case!
This is good advice. Taxation here is relatively high, even taking into accounts the services benefits it delivers. OTOH, outside the rat-race insanity of Sydney or Melbourne, it's a really nice, laid-back place to live.