This is probably close to the mark. Here are some new features for Vista:
The Multimedia Class Scheduler Service: basically a service that juggles thread priorities keeping "important" ones (read: audio playback) near the top:
The I/O system in Vista also has an idea of different priority packets. Therefore the disk read for the next MP3 frame is probably a higher priority than the read for the next network packet.
This comment is being posted from Firefox, which I love. But I have to call bull on this. Despite being superior to IE in almost every way Firefox is left with a market share of, maybe, 15%.
95% of users are content to just run what comes with the OS. It's a testiment to how good Firefox is (or maybe how poor IE is) that it has more than a 5% market share.
The great thing about linux is that, even when you have a run-away process chewing through memory, you can always kill -9 it and it will go away, even if that process is X-Windows/KDE/something big. As compared to Windows, where you can end task a process many times before it decides it will finally exit.
The problem with task manager is that it does not enable the privileges it needs to kill any process... this can lead to "end process" messages being ignored (access denied) for processes that you don't own. This includes stuff that is running as SYSTEM (even when you are Administrator).
The solution? There's a kill.exe utility in the windows resource kit that includes a -f switch... this does much the same thing as kill -9 in unix. The only time this will fail to terminate a process immediately (assuming you run it as admin) is when the kernel has a handle to the process still open (pending I/O operation etc). In this case, the I/O operations are cancelled and the process will disappear when they are done cancelling.
Another solution is to write code to acquire SeDebugName privilege (which will allow you to open a handle to any process on the machine) and then call TerminateProcess yourself.
I hate to be a MS apologist (I don't even work there anymore!) but...
Question: why did the testers use a call of clock_getres() in the ABI test for Linux and a SetFilePointer call for Windows? In my opinion, it would make more sense to me to measure a system call with the same semantic on both systems. Also note: SetFilePointer is in kernel32.dll which then calls ntdll.dll to make the kernel transition... I would like to see something that calls NtSetFileInformation in ntdll.dll directly -- I bet it will solve this ~200 cycle discrepency.
Question: what does Linux do with the x86 debug registers on a context swap? NT saves/restores them. Does it have any logic for V86 mode threads in the context swap? NT does.
Excuses made, ~200 and ~500 cycles are nothing when your CPU is running at 2,000,000,000 cycles per second. The point is that both NT and Linux are very fast (and highly optimized) when it comes to these operations. The only interesting metric in that table is the "Create and Start a Process" line which, as I said in the grandparent, is also not an apples to apples test.
Where on page 31 does it say that FreeBSD and Linux outperform Windows XP? You do realize that fewer CPU cycles is better, right? The only "basic operation" that Windows XP gets hammered in is "Create and Start Process".
I was not able to find the section that describes what kind of a process they are talking about. The price of starting a native process in NT is _very_ cheap. The price of starting a win32 or console mode process depends largely on what DLLs the process is linked against, how many instructions the DLL's init routines consume, and what kind of app-compat patching the loader has to do for these DLLs.
I don't know how dynamic libraries work under FreeBSD/Linux (i.e. do they have init routines that can add to the cost of process creation?) I suspect, however, that neither FreeBSD nor Linux are doing anything about appcompat (i.e. loading an earlier version of library foo because an app compat database told them to). What I'm basically saying here is this is not an apples to apples test.
The NT loader is pretty bloated but if the goal is to spin up a process very quickly rest assured it can be done in NT by creating a native app or by managing the DLL dependencies of the image... I do not think this is a valid statistic.
1. Companies are short sited because shareholders are short sited.
2. You can't have tons of government oversite and still expect a companies to foot large research bills. You brought up Bell Labs/AT&T. They invented UNIX, C, the transister etc... and then the US government stepped in and broke them up. What have they done since? Whether you like to admit it or not, Microsoft is currently spending a lot of money on research. If 75% of the people here had their way, though, Microsoft would be broken up and fined for being bastards... So you can't have your cake and eat it too.
Re:Google GLAT ( Google Labs Aptitude Test )
on
Google's Math Puzzle
·
· Score: 2, Informative
For #17 first I thought "it will never happen again". Then I thought "if I was really smart I'd prove this mathematically". Then I thought "I can write a 4 line C program to see..." Turns out I was wrong. If you're curious:
The NT kernel only supports up to 32 or 64 CPUs, IIRC.
The NT kernel currently supports up to 64 cpus currently, AFAIK.
I think it's because the scheduler has one centralised list of CPUs to dispatch threads to, and it quickly becomes a bottleneck for performance. When you have too many threads to dispatch to too many CPUs, this list is completely locked.
This is incorrect. This used to be the dispatcher design but recent versions of windows (starting with server2003 maybe?) have a ready queue per processor for the reasons you mentioned and to break up the dispatcher lock.
I could be completely wrong here, though, correct me if you know better. So my guess is that MS will have to redo the scheduler of the NT microkernel. I don't know about the VM subsystem...
Well you're not wrong, just outdated. FWIW, the reason that NT supports only 64 cpus currently, I think, is because of the concept of processor affinity and the use of a machine word sized bitvector as an affinity mask. At one bit per processor you get up to 64 cpus (32 on x86). If you're not afraid to break some existing system calls (or, more likely, add an Ex version of the call) and change some internal data structures then this is an easy problem to fix... maybe.
You mean the "edge" of a monopolistic company selling the dev tools and licenses at a loss so that they can gain market share and crowd out competitors? Not to mention the FUD-machine hard at work?
Selling dev tools and licenses at a loss? If the price of the tools was the only issue wouldn't embedded linux w/ free gcc be a more attractive choice? I've heard plenty of FUD but never regarding WinCE... Hmm... sounds like typical anti-MS bias to me.
-- They knew about it, and management wouldn't let them do shit about it.
Also, keep in mind that having a running firewall is going to break a lot of apps and cause a lot of pain. I predict the number of calls to MS phone support (and to XYZ company's phone support) will explode after this service pack rolls out.
Suddenly gamers won't be able to host multiplayer games, for one. People's distributed file sharing clients won't let them share anything. etc...
I suspect that this anticipated user pain is the reason the ICF was not on by default at XP ship time.
Buggy code with buffer overflows is harder to exploit if the stack is not executable -- you can't jump directly into the buffer you just filled with code (you can, however, use "return into libc" attacks, but this is another story).
However, the problem with no-executable stacks is that you cannot create them easily with memory protection alone. This is because if a page on ia32 is readible then it is executable too. This is memory protection -- i.e. the permission bits for regions of memory in the page tables.
What you are talking about is segmentation which is something else. In protected mode whenever you address memory you go through a segment selector like ds, cs, es, ss, etc... Just like in real mode the way a virtual address is formed is by segment+offset.
So when the machine is switched to protected mode the OS has to set up these segments for you in what's called the Global Descriptor Table (GDT). This thing is just a data structure in memory that the OS can use to tell the chip:
Each segment's starting address
Each segment's size
Each segment's permissions
Windows (and, AFAIK, Linux w/o any tricky patches) set up all segments to start at virtual address 0 and extend 4Gb in size. That way no matter what segment you use to address memory you always see a flat 4Gb address space. In this model segments, in essence, disappear and you are left able to address memory with just the "offset" part.
FWIW, I think the way some of these cool no-execute stack patches work is by breaking this "flat 4Gb" model. You see, unlike the execute bit on memory permissions, the execute bit on segment permissions actually works. So you can set up read/write segments that are not executable. Well, if you feel like splitting your address space and reserving some of it to be "stack space" and other to be "code/data space" then you can create no-executable stacks. The downsides here are pretty apparent:
You have to split the address space
Any code that was compiled to "omit stack frame" and reuse the esp register as "just another register" gets broken because the ss segment selector no longer is the same as the cs, ds, es selectors
I don't know much about the other ways people have managed to get no-exec stacks. It looks like Microsoft did it with new chip features... the new AMD hammer (and Intel itanium) chips actually pay attention to the execute bit in the memory page permissions. I heard that the next P4's will too. I think Linux has a few patches that work with the cache somehow. But I don't understand these fully.
...Once there are less than or equal to five or six men on the board. Meaning computers play perfect chess in late endgames AND play very good chess in search trees that start with 7-8 men on the board because a lot of these lines end up as database lookups after a couple of search ply. So again I think the human should be able to consult endgame databases when they want to in a match.
One difference is that while the opening books were developed by human beings the endgame databases were developer by retrograde analysis by computers. This is an area of chess knowledge that we have our silicon friends to thank for. (interesting note: the "50-moves without progress is a draw" rule is an artifact of the days before endgame databases. There are some endgames like KBBKN or KQKRR where the stronger side wins but it takes a hell of a lot of moves to do it -- more than 50).
Interesting point. One thing about computer chess is that the programs have access to an opening move database based on good opening lines developed over the years by human grandmasters. Computer "opening books" are basically encoded versions of traditional books like Encyclopedia of Chess Openings (ECO), Nunn's (NCO), etc... So to allow the computer program access to this material while requiring the human memorize it seems unfair to me -- the human should have access to literature.
Moreover computers also use endgame databases once there are
I don't know if that's what you mean by a human "cyborg"... more like a human with some books and a laptop.
Another interesting thing would be "Advanced Chess" (google it if you're curious). It's where the "human" grandmaster is augmented by computer programs. So when thinking about his move he can play out some interesting lines vs. computer opponents before officially playing that move in the game. Of course, give Kasparov access to a laptop version of Fritz (even while he's playing a 4cpu custom version) and I'd put huge money on him finding a gaping hole and trouncing the machine.
Computers are really good at chess but, as someone who knows a little about this subject, I think the (world's best) humans are still clearly superior in this game. Although it's getting much closer.
I'm sure you already found this out by reading the intel manual but MCE = machine check exception. It's a hardware generated exception like a NMI. I think MCE happens when a parity error is detected on the memory bus so my first suspician would be your motherboard or memory. But I also seem to remember other ways for that exception to be raised (unfortunately my good books are on loan to a coworker).
Not that I'd recommend it, but you can handle one of these exceptions and effectively ignore it. Of course this raises the possibility of data corruption. A little linux hacking should do the trick. BTW there's a reg key to disable the bugcheck in NT and as far as I know Win9x ignores the exception altogether (excellent plan there).
IRQL is "Interrupt Request Level". This is a DWORD in the NT kernel that cooresponds to a system state and determines what can preempt the currently running code. For example, raising the IRQL causes different priority device IRQs (interrupts) from the PICs to be masked off and ignored until the IRQL is lowered again. But the IRQL is not just to mask off interrupts, the NT kernel uses it for synchronization, communication between different CPUs on MP machines, to determine whether DPCs can run, to determine whether its ok to run user mode code, etc...
Any code running in kernel mode (x86 ring 0) on NT (drivers or the kernel) can change the IRQL by making a call. Code typically raises the IRQL when it needs to do something critical and cannot afford to be preempted. The IRQL has to be at a certain level to acquire certain system locks, etc. So with all this raising of the IRQL people have to remember to put it back before they return.
Invariably what happens is that someone forgets to lower the IRQL after they have raised it... maybe on an error path or something. They leave it raised, returned to whoever called them etc... and eventually you get to code that requires that the IRQL be below some level. For example, you try to acquire a spinlock, take a page fault, try to allocate memory (pool), try to schedule the next user mode job etc... All of these actions have code that basically asserts that the IRQL is where it should be. When it's not, the machine is bugchecked and you get the bluescreen.
This kind of bugcheck is not ususally caused by hardware, it's almost always software related. Someone raised the IRQL and forgot to lower it. There are ways to find out who, basically by logging all calls to KeRaiseIrql, KeLowerIrql and some other routines that change the IRQL as a side effect.
The U.S. has something crazy like 5%+ of the national population in jail currently. This is more than any other country in the world -- close to the sum of all the prisoners in all other countries in the world.
Right now the most common type of offense individuals in jail is a drug-related offense. I'd argue that addicts need treatment more than incarceration to change their lives... and before anyone argues that treatment costs the state too much consider that it costs $77,000 per year to keep someone in jail.
Now as if we didn't already have enough jail overcrowing and enough people behind bars who are nonviolent people and victims of overharsh legislation we'll start throwing people in jail for copying bits from one place to another. God, this is an outrage. Let me tell you something else: if a rich white kid with no past offenses is busted swapping music or movies at Princeton he'll get a slap on the wrist. But if a poor hispanic high-school drop out "loser" gets busted and the DA is looking for a reason to take him off the street anyway, the "loser" will get fucked.
The USA is moving from a democratic republic to a oligarchy where all the power rests in the hands of the rich and well connected. Slowly the rights of the individual are being eroded in the name of fighting terrorism. Slowly the rights of the big corporation are being increased. The rich get more tax cuts and no inheritance tax while the poor lose their jobs. The only reason that Congress is interested in creating IP law like this is because the RIAA and MPAA are rich and well connected.
People are so apathetic and the change is so gradual that I'm convinced no one will realize what's going on or care until it's too late.
Futurepower(R) asks: "Microsoft Windows 2000 and Windows XP have crippled file systems. The file system cannot copy some of the files that are necessary to the operating system.
While the system is running several processes have locks in place on files. Moreover some data on your disk (e.g. the boot sector) need to be copied to the same sector on the target drive. This isn't a "file" so you couldn't do it no matter what filesystem you used. Even under unix you'd have to use something like dd. It seem to me based on the first line of your question that you have unreasonable expectations and a negative opinion of Microsoft.
Microsoft's advice is to reinstall the operating system and all programs every time you want to move to a new or backup computer.
Which makes sense if you take into consideration that a lot of work detecting hardware happens during the install. Despite this I have moved hard drives with XP on them between machines and had no problem booting... the system detects a ton of device changes but works.
Copying each sector of a hard drive bypasses Microsoft's copy protection by which Microsoft punishes all users, even if they are honest.
This is just wrong. If it was this easy to defeat windows activation then everyone would do it. The way WPA works is it builds a fingerprint of your system based on 10 terms derived from the system hardware. If more than a few of these change it makes you reactivate. So by mirroring the disk sector by sector then plopping it in another machine you in effect change a lot of the hardware terms in the WPA equation and it forces you to reactivate windows.
I don't have an answer to your question except this: it would be trivial to write a program to copy sector by sector, a "dd" for windows. So easy that I am sure it has been done. In case it hasn't, here's how to do it: MSDN article
I see your point but a similar case can be made for NT. A lot of Windows security flaws are in code like Outlook, Outlook Express, IE, the RPC service, etc... Windows ships with all of these things (except Outlook) so a bug in one of them is a "bug in Windows". But Linus likes to define linux as a kernel. If you take a look at the NT kernel and the number of security flaws in it... I think you find MS is doing ok.
The problem is bloat. Shipping the kitchen sink along with the OS -- indeed "integrating" webbrowser libraries etc... into the base Windows "distribution" means that if the quality of this userland code is poor you have a "bug in the OS".
But to hear people complain about Outlook Express or IE bugs and say they are "NT bugs" or "Windows bugs" bothers me... think of it like someone calling a bug in Mozilla a bug in "linux". Windows is a distribution where a lot of userland has been written to make it easy to use but without good security. That said, there's no getting around this or excusing it. Especially the RPC bug that caused Blaster -- there's a good case for calling that part of the OS since it was a integral OS service. But the NT kernel is very solid code and if you ignore "3rd party" apps in a linux distribution (like mozilla, mutt, the kde stuff etc) don't be surprised when I want to distance NT from the all stuff that comes with it.
In fact in a recent USNews article (about the country's most overpaid CEOs) Gates was listed as the #1 most underpaid CEO. I think me makes something like $350k / year.
Yes, video drivers run in kernel space as do network drivers, disk drivers, the window manager and the GDI code. This didn't used to be the case: a design change was made between 3.51 and 4.0 to move the GDI code and window manager into the kernel. There's somewhat thourough discussion of this in "Inside Windows 2000" if you're interested. It's a book published by MS so maybe you'll question it's objectiveness... but let me quote the conclusion of the discussion:
So in summary, moving the window manager and the GDI from user mode to kernel mode has provided improved performance without any significant decrease in system stability or reliablity.
I work with NT kernel crashes and I can tell you that bugchecks in the GDI code are pretty rare... in my opinion this "without any significant decrease" is not a load of shit. Most bluescreens come from driver code.
I don't know anything about mozilla, opera, konquerer, netscape or whatever but they probably put rendering code in shared libraries too. I mean, it's a good design if you want to reuse the same code to do a help system, run MSDN, run the Visual Studio environment (god I hate this thing), and run the explorer code.
With regard to your linksys driver, that's just poor driver design. That really sucks. But I have a laptop with an intel centrino wireless card that works great when running as non-admin on XP so it's not a limitation of windows.
I don't mean to be defending windows here -- there are some bad design choices and definitely things to fix... but I don't think an excessive amount of code runs in kernel mode and in the 2k/XP timeframe a lot of work went into making it easy to run as a non-administrator which were the two points that the original post was attacking.
Slashdot Mirror
This is probably close to the mark. Here are some new features for Vista:
. aspx
s px
The Multimedia Class Scheduler Service: basically a service that juggles thread priorities keeping "important" ones (read: audio playback) near the top:
http://msdn2.microsoft.com/en-us/library/ms684247
The I/O system in Vista also has an idea of different priority packets. Therefore the disk read for the next MP3 frame is probably a higher priority than
the read for the next network packet.
http://www.microsoft.com/whdc/driver/priorityio.m
This is complete speculation on my part but I could see how these thing might affect machine performance during audio playback.
This comment is being posted from Firefox, which I love. But I have to call bull on this. Despite being superior to IE in almost every way Firefox is left with a market share of, maybe, 15%.
95% of users are content to just run what comes with the OS. It's a testiment to how good Firefox is (or maybe how poor IE is) that it has more than a 5% market share.
The problem with task manager is that it does not enable the privileges it needs to kill any process... this can lead to "end process" messages being ignored (access denied) for processes that you don't own. This includes stuff that is running as SYSTEM (even when you are Administrator).
The solution? There's a kill.exe utility in the windows resource kit that includes a -f switch... this does much the same thing as kill -9 in unix. The only time this will fail to terminate a process immediately (assuming you run it as admin) is when the kernel has a handle to the process still open (pending I/O operation etc). In this case, the I/O operations are cancelled and the process will disappear when they are done cancelling.
Another solution is to write code to acquire SeDebugName privilege (which will allow you to open a handle to any process on the machine) and then call TerminateProcess yourself.
Perhaps you missed the news:
/ 21/1133223&tid=142&tid=137
http://hardware.slashdot.org/article.pl?sid=05/11
I hate to be a MS apologist (I don't even work there anymore!) but...
Question: why did the testers use a call of clock_getres() in the ABI test for Linux and a SetFilePointer call for Windows? In my opinion, it would make more sense to me to measure a system call with the same semantic on both systems. Also note: SetFilePointer is in kernel32.dll which then calls ntdll.dll to make the kernel transition... I would like to see something that calls NtSetFileInformation in ntdll.dll directly -- I bet it will solve this ~200 cycle discrepency.
Question: what does Linux do with the x86 debug registers on a context swap? NT saves/restores them. Does it have any logic for V86 mode threads in the context swap? NT does.
Excuses made, ~200 and ~500 cycles are nothing when your CPU is running at 2,000,000,000 cycles per second. The point is that both NT and Linux are very fast (and highly optimized) when it comes to these operations. The only interesting metric in that table is the "Create and Start a Process" line which, as I said in the grandparent, is also not an apples to apples test.
Where on page 31 does it say that FreeBSD and Linux outperform Windows XP? You do realize that fewer CPU cycles is better, right? The only "basic operation" that Windows XP gets hammered in is "Create and Start Process".
I was not able to find the section that describes what kind of a process they are talking about. The price of starting a native process in NT is _very_ cheap. The price of starting a win32 or console mode process depends largely on what DLLs the process is linked against, how many instructions the DLL's init routines consume, and what kind of app-compat patching the loader has to do for these DLLs.
I don't know how dynamic libraries work under FreeBSD/Linux (i.e. do they have init routines that can add to the cost of process creation?) I suspect, however, that neither FreeBSD nor Linux are doing anything about appcompat (i.e. loading an earlier version of library foo because an app compat database told them to). What I'm basically saying here is this is not an apples to apples test.
The NT loader is pretty bloated but if the goal is to spin up a process very quickly rest assured it can be done in NT by creating a native app or by managing the DLL dependencies of the image... I do not think this is a valid statistic.
You can do this on freebsd with ipfw, apache and a couple of perl scripts. Here's a little guide I wrote back when I did this: http://wannabe.guru.org/scott/hobbies/wireless.htm l
Scott
1. Companies are short sited because shareholders are short sited.
2. You can't have tons of government oversite and still expect a companies to foot large research bills. You brought up Bell Labs/AT&T. They invented UNIX, C, the transister etc... and then the US government stepped in and broke them up. What have they done since? Whether you like to admit it or not, Microsoft is currently spending a lot of money on research. If 75% of the people here had their way, though, Microsoft would be broken up and fined for being bastards... So you can't have your cake and eat it too.
For #17 first I thought "it will never happen again". Then I thought "if I was really smart I'd prove this mathematically". Then I thought "I can write a 4 line C program to see..." Turns out I was wrong. If you're curious:
1 == 1
199981 == 199981
199982 == 199982
199983 == 199983
199984 == 199984
199985 == 199985
199986 == 199986
199987 == 199987
199988 == 199988
199989 == 199989
199990 == 199990
200000 == 200000
200001 == 200001
1599981 == 1599981
1599982 == 1599982
1599983 == 1599983
1599984 == 1599984
1599985 == 1599985
1599986 == 1599986
1599987 == 1599987
1599988 == 1599988
1599989 == 1599989
1599990 == 1599990
2600000 == 2600000
2600001 == 2600001
13199998 == 13199998
35000000 == 35000000
35000001 == 35000001
35199981 == 35199981
35199982 == 35199982
35199983 == 35199983
35199984 == 35199984
35199985 == 35199985
35199986 == 35199986
35199987 == 35199987
35199988 == 35199988
35199989 == 35199989
35199990 == 35199990
35200000 == 35200000
35200001 == 35200001
117463825 == 117463825
500000000 == 500000000
500000001 == 500000001
500199981 == 500199981
500199982 == 500199982
500199983 == 500199983
500199984 == 500199984
500199985 == 500199985
500199986 == 500199986
500199987 == 500199987
500199988 == 500199988
500199989 == 500199989
500199990 == 500199990
500200000 == 500200000
500200001 == 500200001
501599981 == 501599981
501599982 == 501599982
501599983 == 501599983
501599984 == 501599984
501599985 == 501599985
501599986 == 501599986
501599987 == 501599987
501599988 == 501599988
501599989 == 501599989
501599990 == 501599990
502600000 == 502600000
502600001 == 502600001
The NT kernel currently supports up to 64 cpus currently, AFAIK.
This is incorrect. This used to be the dispatcher design but recent versions of windows (starting with server2003 maybe?) have a ready queue per processor for the reasons you mentioned and to break up the dispatcher lock.
Well you're not wrong, just outdated. FWIW, the reason that NT supports only 64 cpus currently, I think, is because of the concept of processor affinity and the use of a machine word sized bitvector as an affinity mask. At one bit per processor you get up to 64 cpus (32 on x86). If you're not afraid to break some existing system calls (or, more likely, add an Ex version of the call) and change some internal data structures then this is an easy problem to fix... maybe.
Upgrade.
Selling dev tools and licenses at a loss? If the price of the tools was the only issue wouldn't embedded linux w/ free gcc be a more attractive choice? I've heard plenty of FUD but never regarding WinCE... Hmm... sounds like typical anti-MS bias to me.
Also, keep in mind that having a running firewall is going to break a lot of apps and cause a lot of pain. I predict the number of calls to MS phone support (and to XYZ company's phone support) will explode after this service pack rolls out.
Suddenly gamers won't be able to host multiplayer games, for one. People's distributed file sharing clients won't let them share anything. etc...
I suspect that this anticipated user pain is the reason the ICF was not on by default at XP ship time.
Buggy code with buffer overflows is harder to exploit if the stack is not executable -- you can't jump directly into the buffer you just filled with code (you can, however, use "return into libc" attacks, but this is another story).
However, the problem with no-executable stacks is that you cannot create them easily with memory protection alone. This is because if a page on ia32 is readible then it is executable too. This is memory protection -- i.e. the permission bits for regions of memory in the page tables.
What you are talking about is segmentation which is something else. In protected mode whenever you address memory you go through a segment selector like ds, cs, es, ss, etc... Just like in real mode the way a virtual address is formed is by segment+offset.
So when the machine is switched to protected mode the OS has to set up these segments for you in what's called the Global Descriptor Table (GDT). This thing is just a data structure in memory that the OS can use to tell the chip:
Windows (and, AFAIK, Linux w/o any tricky patches) set up all segments to start at virtual address 0 and extend 4Gb in size. That way no matter what segment you use to address memory you always see a flat 4Gb address space. In this model segments, in essence, disappear and you are left able to address memory with just the "offset" part.
FWIW, I think the way some of these cool no-execute stack patches work is by breaking this "flat 4Gb" model. You see, unlike the execute bit on memory permissions, the execute bit on segment permissions actually works. So you can set up read/write segments that are not executable. Well, if you feel like splitting your address space and reserving some of it to be "stack space" and other to be "code/data space" then you can create no-executable stacks. The downsides here are pretty apparent:
I don't know much about the other ways people have managed to get no-exec stacks. It looks like Microsoft did it with new chip features... the new AMD hammer (and Intel itanium) chips actually pay attention to the execute bit in the memory page permissions. I heard that the next P4's will too. I think Linux has a few patches that work with the cache somehow. But I don't understand these fully.
One difference is that while the opening books were developed by human beings the endgame databases were developer by retrograde analysis by computers. This is an area of chess knowledge that we have our silicon friends to thank for. (interesting note: the "50-moves without progress is a draw" rule is an artifact of the days before endgame databases. There are some endgames like KBBKN or KQKRR where the stronger side wins but it takes a hell of a lot of moves to do it -- more than 50).
Interesting point. One thing about computer chess is that the programs have access to an opening move database based on good opening lines developed over the years by human grandmasters. Computer "opening books" are basically encoded versions of traditional books like Encyclopedia of Chess Openings (ECO), Nunn's (NCO), etc... So to allow the computer program access to this material while requiring the human memorize it seems unfair to me -- the human should have access to literature.
Moreover computers also use endgame databases once there are I don't know if that's what you mean by a human "cyborg"... more like a human with some books and a laptop.
Another interesting thing would be "Advanced Chess" (google it if you're curious). It's where the "human" grandmaster is augmented by computer programs. So when thinking about his move he can play out some interesting lines vs. computer opponents before officially playing that move in the game. Of course, give Kasparov access to a laptop version of Fritz (even while he's playing a 4cpu custom version) and I'd put huge money on him finding a gaping hole and trouncing the machine.
Computers are really good at chess but, as someone who knows a little about this subject, I think the (world's best) humans are still clearly superior in this game. Although it's getting much closer.
Not that I'd recommend it, but you can handle one of these exceptions and effectively ignore it. Of course this raises the possibility of data corruption. A little linux hacking should do the trick. BTW there's a reg key to disable the bugcheck in NT and as far as I know Win9x ignores the exception altogether (excellent plan there).
Good luck tracking this down.
Any code running in kernel mode (x86 ring 0) on NT (drivers or the kernel) can change the IRQL by making a call. Code typically raises the IRQL when it needs to do something critical and cannot afford to be preempted. The IRQL has to be at a certain level to acquire certain system locks, etc. So with all this raising of the IRQL people have to remember to put it back before they return.
Invariably what happens is that someone forgets to lower the IRQL after they have raised it... maybe on an error path or something. They leave it raised, returned to whoever called them etc... and eventually you get to code that requires that the IRQL be below some level. For example, you try to acquire a spinlock, take a page fault, try to allocate memory (pool), try to schedule the next user mode job etc... All of these actions have code that basically asserts that the IRQL is where it should be. When it's not, the machine is bugchecked and you get the bluescreen.
This kind of bugcheck is not ususally caused by hardware, it's almost always software related. Someone raised the IRQL and forgot to lower it. There are ways to find out who, basically by logging all calls to KeRaiseIrql, KeLowerIrql and some other routines that change the IRQL as a side effect.
<RANT>
The U.S. has something crazy like 5%+ of the national population in jail currently. This is more than any other country in the world -- close to the sum of all the prisoners in all other countries in the world.
Right now the most common type of offense individuals in jail is a drug-related offense. I'd argue that addicts need treatment more than incarceration to change their lives... and before anyone argues that treatment costs the state too much consider that it costs $77,000 per year to keep someone in jail.
Now as if we didn't already have enough jail overcrowing and enough people behind bars who are nonviolent people and victims of overharsh legislation we'll start throwing people in jail for copying bits from one place to another. God, this is an outrage. Let me tell you something else: if a rich white kid with no past offenses is busted swapping music or movies at Princeton he'll get a slap on the wrist. But if a poor hispanic high-school drop out "loser" gets busted and the DA is looking for a reason to take him off the street anyway, the "loser" will get fucked.
The USA is moving from a democratic republic to a oligarchy where all the power rests in the hands of the rich and well connected. Slowly the rights of the individual are being eroded in the name of fighting terrorism. Slowly the rights of the big corporation are being increased. The rich get more tax cuts and no inheritance tax while the poor lose their jobs. The only reason that Congress is interested in creating IP law like this is because the RIAA and MPAA are rich and well connected.
People are so apathetic and the change is so gradual that I'm convinced no one will realize what's going on or care until it's too late.
</RANT>
While the system is running several processes have locks in place on files. Moreover some data on your disk (e.g. the boot sector) need to be copied to the same sector on the target drive. This isn't a "file" so you couldn't do it no matter what filesystem you used. Even under unix you'd have to use something like dd. It seem to me based on the first line of your question that you have unreasonable expectations and a negative opinion of Microsoft.
Microsoft's advice is to reinstall the operating system and all programs every time you want to move to a new or backup computer.
Which makes sense if you take into consideration that a lot of work detecting hardware happens during the install. Despite this I have moved hard drives with XP on them between machines and had no problem booting... the system detects a ton of device changes but works.
Copying each sector of a hard drive bypasses Microsoft's copy protection by which Microsoft punishes all users, even if they are honest.
This is just wrong. If it was this easy to defeat windows activation then everyone would do it. The way WPA works is it builds a fingerprint of your system based on 10 terms derived from the system hardware. If more than a few of these change it makes you reactivate. So by mirroring the disk sector by sector then plopping it in another machine you in effect change a lot of the hardware terms in the WPA equation and it forces you to reactivate windows.
I don't have an answer to your question except this: it would be trivial to write a program to copy sector by sector, a "dd" for windows. So easy that I am sure it has been done. In case it hasn't, here's how to do it: MSDN article
You apparently don't know the difference between a kernel and usermode shared libraries (DLLs). The only thing you got right there was the GDI.
The problem is bloat. Shipping the kitchen sink along with the OS -- indeed "integrating" webbrowser libraries etc... into the base Windows "distribution" means that if the quality of this userland code is poor you have a "bug in the OS".
But to hear people complain about Outlook Express or IE bugs and say they are "NT bugs" or "Windows bugs" bothers me... think of it like someone calling a bug in Mozilla a bug in "linux". Windows is a distribution where a lot of userland has been written to make it easy to use but without good security. That said, there's no getting around this or excusing it. Especially the RPC bug that caused Blaster -- there's a good case for calling that part of the OS since it was a integral OS service. But the NT kernel is very solid code and if you ignore "3rd party" apps in a linux distribution (like mozilla, mutt, the kde stuff etc) don't be surprised when I want to distance NT from the all stuff that comes with it.
Of course now that MSFT is paying a dividend... even something like $0.12 per share equals a HUGE payout to Gates since he owns so much stock.
In fact in a recent USNews article (about the country's most overpaid CEOs) Gates was listed as the #1 most underpaid CEO. I think me makes something like $350k / year.
Yes, video drivers run in kernel space as do network drivers, disk drivers, the window manager and the GDI code. This didn't used to be the case: a design change was made between 3.51 and 4.0 to move the GDI code and window manager into the kernel. There's somewhat thourough discussion of this in "Inside Windows 2000" if you're interested. It's a book published by MS so maybe you'll question it's objectiveness... but let me quote the conclusion of the discussion:
I work with NT kernel crashes and I can tell you that bugchecks in the GDI code are pretty rare... in my opinion this "without any significant decrease" is not a load of shit. Most bluescreens come from driver code.
I don't know anything about mozilla, opera, konquerer, netscape or whatever but they probably put rendering code in shared libraries too. I mean, it's a good design if you want to reuse the same code to do a help system, run MSDN, run the Visual Studio environment (god I hate this thing), and run the explorer code.
With regard to your linksys driver, that's just poor driver design. That really sucks. But I have a laptop with an intel centrino wireless card that works great when running as non-admin on XP so it's not a limitation of windows.
I don't mean to be defending windows here -- there are some bad design choices and definitely things to fix... but I don't think an excessive amount of code runs in kernel mode and in the 2k/XP timeframe a lot of work went into making it easy to run as a non-administrator which were the two points that the original post was attacking.