Most of the BSOD crashes in Windows are caused by 3rd party drivers - primarily graphics and printer drivers.
For Vista, Microsoft undertook a massive re-architecture and rewrite of the video and printer driver architectures, enabling all code that didn't need to live in the kernel in order to communicate directly with hardware to be run outside the kernel in the user-mode driver infrastructure.
This means that the majority of video/printer driver code runs OUTSIDE the kernel and has already resulted in a massive reduction in the number of BSOD on Vista.
Of course, this means that drivers for video cards and printers needed to be rewritten. Whilst there were initially many issues with the video drivers in particular as the OEM's were getting used to working with the new driver model, most of those issues are now nailed. If you're still seeing stability/perf issues, try updating your drivers to the latest supported version and you should see your issues disappear.
HOWEVER, these driver architecture changes do not apply to proprietary drivers written by a third party (like those from Apple) - if those drivers corrupt memory, overwrite system structures, deadlock, etc., then there's nothing that ANY commercial OS can do to prevent a core-dump/BSOD.
Debugging most threaded/multi-process code is hard. It's not threading per-se that makes this hard - it's the nature of the beast - concurrent programming is hard.
There are many efforts across the industry that are working on making it easier to write and debug concurrent code - an incredibly important activity considering that most new PC's will have at least 8 cores by the end of next year!
"Microsoft have moved to X11-like window systems" Erm, no! Windows UI is nothing like X11. Nothing at all. Nada. Zip.
And, no, the Windows world is not giving up threads for processes.
The important thing to remember with Windows is that the kernel schedules threads, not processes. Processes define a collection of threads all of which have access to the same virtual memory space and can thus share data easily and quickly (no cross-process marshalling required).
Processes, therefore, are inherently more costly to create and destroy than threads (have to do all the CPU & MMU config, etc) and so should be used sparingly.
The downside here is that if one thread (running, for example, the code in one web page) crashes, it's likely that the process will terminate and take down all the other threads in the process.
The way to insulate yourself from this? Parition your apps to run different "logical threads" in separate processes - this way, if one thread/process dies, it won't affect any other processes. Clever partitioning (i.e. running all web pages with no or carefully verfied JScript in one process) can help mitigate the cost of process creation.
Give me a break. XP's networking stack was NOT the panacea. XP's network stack was not able to adaptively adjust its TCP window size based on network latencies etc. Also, it wasn't built to cleanly support IPv6. Vista's new network stack does both of these, plus adds support for SMB 3.0 which DRAMATICALLY improves the performance of copying files to/from Vista/Server2008 machines. I nearly fell over the first time I saw my Vista machine saturate it's network socket whilst copying files to another Vista box.
Whilst there were indeed some unfortunate bugs in Vista RTM's network stack, SP1 has nailed a huge number of these issues and it's network performance is now AWESOME.
Microsoft also took the time to adjust how SuperFetch and the File Indexers worked, reducing the brutal disk pounding that Vista RTM delivered to users' hard drives and which accounted for the vast majority of percieved performance issues. SP1 is now smooth, fast and enormously more usable for practically all desktop uses.
Server 2008 is a wonderful improvement over the already hugely respectable Server 2003.
Both Vista and Server share much common code. Server, of course, has extra features that Vista client doesn't need (e.g. DNS, DHCP, WINS, AD, WDS, etc. services), but the core kernel and the vast majority of the rest of the core OS are the same code.
Since Server 2008 has been tuned, issues fixed and features improved in the 18 months since the Vista team had to down tools on new feature implementations, they've done a great deal of work to improve perf and stability.
So before bitchslapping VistaSP1/Server2008, why not take them out for a drive - I think you'll be pleasantly surprised.
Slashdot Mirror
Most of the BSOD crashes in Windows are caused by 3rd party drivers - primarily graphics and printer drivers.
For Vista, Microsoft undertook a massive re-architecture and rewrite of the video and printer driver architectures, enabling all code that didn't need to live in the kernel in order to communicate directly with hardware to be run outside the kernel in the user-mode driver infrastructure.
This means that the majority of video/printer driver code runs OUTSIDE the kernel and has already resulted in a massive reduction in the number of BSOD on Vista.
Of course, this means that drivers for video cards and printers needed to be rewritten. Whilst there were initially many issues with the video drivers in particular as the OEM's were getting used to working with the new driver model, most of those issues are now nailed. If you're still seeing stability/perf issues, try updating your drivers to the latest supported version and you should see your issues disappear.
HOWEVER, these driver architecture changes do not apply to proprietary drivers written by a third party (like those from Apple) - if those drivers corrupt memory, overwrite system structures, deadlock, etc., then there's nothing that ANY commercial OS can do to prevent a core-dump/BSOD.
And debugging threads is easy
Debugging most threaded/multi-process code is hard. It's not threading per-se that makes this hard - it's the nature of the beast - concurrent programming is hard.
There are many efforts across the industry that are working on making it easier to write and debug concurrent code - an incredibly important activity considering that most new PC's will have at least 8 cores by the end of next year!
"Microsoft have moved to X11-like window systems"
Erm, no! Windows UI is nothing like X11. Nothing at all. Nada. Zip.
And, no, the Windows world is not giving up threads for processes.
The important thing to remember with Windows is that the kernel schedules threads, not processes. Processes define a collection of threads all of which have access to the same virtual memory space and can thus share data easily and quickly (no cross-process marshalling required).
Processes, therefore, are inherently more costly to create and destroy than threads (have to do all the CPU & MMU config, etc) and so should be used sparingly.
The downside here is that if one thread (running, for example, the code in one web page) crashes, it's likely that the process will terminate and take down all the other threads in the process.
The way to insulate yourself from this? Parition your apps to run different "logical threads" in separate processes - this way, if one thread/process dies, it won't affect any other processes. Clever partitioning (i.e. running all web pages with no or carefully verfied JScript in one process) can help mitigate the cost of process creation.
Give me a break. XP's networking stack was NOT the panacea. XP's network stack was not able to adaptively adjust its TCP window size based on network latencies etc. Also, it wasn't built to cleanly support IPv6. Vista's new network stack does both of these, plus adds support for SMB 3.0 which DRAMATICALLY improves the performance of copying files to/from Vista/Server2008 machines. I nearly fell over the first time I saw my Vista machine saturate it's network socket whilst copying files to another Vista box. Whilst there were indeed some unfortunate bugs in Vista RTM's network stack, SP1 has nailed a huge number of these issues and it's network performance is now AWESOME. Microsoft also took the time to adjust how SuperFetch and the File Indexers worked, reducing the brutal disk pounding that Vista RTM delivered to users' hard drives and which accounted for the vast majority of percieved performance issues. SP1 is now smooth, fast and enormously more usable for practically all desktop uses. Server 2008 is a wonderful improvement over the already hugely respectable Server 2003. Both Vista and Server share much common code. Server, of course, has extra features that Vista client doesn't need (e.g. DNS, DHCP, WINS, AD, WDS, etc. services), but the core kernel and the vast majority of the rest of the core OS are the same code. Since Server 2008 has been tuned, issues fixed and features improved in the 18 months since the Vista team had to down tools on new feature implementations, they've done a great deal of work to improve perf and stability. So before bitchslapping VistaSP1/Server2008, why not take them out for a drive - I think you'll be pleasantly surprised.