Tidig Windows NT hade grafiken separerad från Kerneln. Han som designade NT från början, var ju han bakom OpenVMS (där upptider på decennier rapporteras). Men det gav för låga prestanda så MS stoppade in grafiken i Kernel. Så, en bugg i nån graffedrivis kunde krascha datorn.
Det står om sånt, här:
http://www.vanwensveen.nl/rants/micr...IhateMS_2.html
"Windows is quite fragile, and the operating system can get corrupted quite easily. This happens most often during the installation of updates, service packs, drivers or application software, and the problem exists in all versions of Windows so far. The heart of the problem lies in the fact that Windows can't (or rather, is designed not to) separate application and operating system code and settings. Code gets mixed up when applications install portions of themselves between files that belong to the operating system (occasionally replacing them in the process). Settings are written to a central registry that also stores vital OS settings. The registry database is basically insecure, and settings that are vital to the OS or to other applications are easily corrupted.
Even more problems are caused by the limitations of Windows' DLL subsystem. A good multi-tasking and/or multi-user OS utilizes a principle called code sharing. Code sharing means that if an application is running n times at once, the code segment that contains the program code (which is called the static segment) is loaded into memory only once, to be used by n different processes which are therefore instances of the same application. Apparently Microsoft had heard about something called code sharing, but obviously didn't really understand the concept and the benefits, or they didn't bother with the whole idea. Whatever the reason, they went and used DLLs instead. DLL files contain Dynamic Link Libraries and are intended to contain libary functions only. Windows doesn't share the static (code) segment - if you run 10 instances of Word, the bulk of the code will be loaded into memory 10 times. Only a fraction of the code, e.g. library functions, has been moved to DLLs and may be shared.
...
Designing an OS to deliberately mix up system and application code fits Microsoft's strategy of product bundling and integration. (See below.) But the results are obvious: each file operation that involves executable code puts the entire OS and its applications at risk, and application errors often mean OS errors (and crashes) as well. This leads to ridiculous 'issues' such as Outlook Express that may crash Windows NT 4.0, if NT is a 'high encryption' version with the locale set to 'France'. Replying to a message may crash the entire system, a problem which has been traced to one of the DLLs that comes with Outlook. (Are you still with me?)
In a well-designed and robustly coded OS something like this could never happen. The first design criterion for any OS is that the system, the applications, and (in a multi-user environment) the users all be separated and protected from each other. Not only does no version of Windows do that by default, it actively prevents you from setting things up that way. The DLL fiasco is just the tip of the iceberg. You can't maintain or adequately restore OS integrity, you can't maintain version control, and you can't prevent applications and users from interfering with each other and the system, either by accident or on"
En annan lustig grej är att eftersom MS förrut alltid skulle vara bakåtkompatibla, så hårdkodade de i t.ex. Windows95 att "om Civilization kördes, så var det ok att återanvända minne som man precis avallokerat (vilket Civilization i dosversionen gjorde!)". Och det var massa såna hacks i Windows. "Om det är detta program som körs, så är det ok att...".
Nu med Vista har MS gått ifrån det, att alltid bevara bakåtkompatibilitet. Finns en lång intressant artikel om det. (Men MS suger på bakåtkompatibilitet. Sun Solaris GARANTERAR bakåtkompatibilitet - och de lyckas)
