In retrospect, Windows gets a LOT WRONG
|
| Author | Content |
|---|---|
| phsolide Dec 21, 2008 2:00 PM EDT |
It's my belief that you can trace almost all problems that Windows faces to some basic (bad) design decisions. 1. carriage-return/line-feed for end of line. This causes no end of problems, and its the root of the really stupid distinction between "text" and "binary" files. 2. Default exclusive access to files. This is really what causes Windows to require all those reboots for patch installation, I believe. Any "patch" is just a DLL replacement or something like, and the DLL is very likely open, and therefor locked. Can't replace it without going through a reboot, which stages DLL files for replacmement. 3. File name "extentions". The worst aspect of this is that an executable has a specific file name extention, it's not a permission on the file. This, in combination with the rather loose set of extentions that make a file executable (.pif, .scr, .emf, even MSFT doesn't know them all) has caused much of the virus problem that MS-DOS, and now Windows has suffered. It also enables the social engineering that has taken the place of viruses as the main plague of Windows. Naming a file "Something.jpeg.exe" means that it appears as "Something.jpeg" to most Windows users - they click hoping to see the image, and it gets executed instead. 4. A silly set of file permissions. I confess, I'm a unix and linux guy from way back, but Windows permissions don't make any sense at all. They're not regular in the slightest. This probably causes a lot of the "always run as admin" behavior. 5. Stupid file system. The on-disk layout of NTFS is clearly borrowed from ODS-11, the VMS file system. But MSFT didn't learn the lesson that DEC did: you must have a defragmenter running. So, the file system gets slow. Heck, SGI had an extent-allocation based file system in 1989, and they provided a defragmenter as part of the basic system. 6. Dumb process and thread model: fork/exec is clearly far more efficient than the "spawn" model used in Windows. 7. Lack of a "window manager" as a seperate process. This leads to "locked up" windows that won't move, and can't be closed, when they quit responding to events. 8. Silly windowing model: MDI just leads to a plague of modal pop-ups. Yech. Totally inefficient to users. 9. Hiding the real system calls under multiple layers of "abstraction". Inefficiencies abound, causing them to do dangerous security tradeoffs like move GDI into the OS kernel. That's just what occurs to me off the top of my head. I'm sure other things are basically wrong. |
| tuxchick Dec 21, 2008 2:43 PM EDT |
Wow, that would make a wonderful LXer Feature. *hint nudge* |
| Sander_Marechal Dec 21, 2008 8:20 PM EDT |
What TC said. Submit it here (http://lxer.com/module/newswire/stories/) or e-mail editors@ to post it. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!