Unfortunately, this advice won't be usable to some developers. For folks who are writing Active X controls, you're inherently forced to do exactly this: create a DLL which contains code.
However, for those of us who are not trying to create reusable binaries for use in an environment that requires Active X - which I suspect is still quite a significant audience, DLLs should simply never be used for anything other than localized resources.
The reason is simple: DLLs create DLL hell.
There are multiple layers to the issue of DLL hell, various different unfortunate outcomes and scenarios, all of which should be enough in and of themselves to dissuade you from using them in the first place. But when taken together, it blows my mind that anyone still thinks its a good idea to build them, and use them, ever (unless they're absolutely required by the technology in question).
The only reason they exist, is to create a common library that can be drawn upon by many clients at runtime, thus reducing the memory footprint of all of the running applications that rely upon that common code, since only one copy need be loaded by the OS, and then simply mapped into the address space of each client that was linked against it.
But, the thing is, that was a reasonable need in 1990, when Windows 3.0 was released. Memory was indeed very limited, and even the delay of having to load from disk a separate copy of the DLL for each process was a significant performance hit for the OS. DOS compilers & linkers had been using similar techniques for a few years, to squeeze extra usage out of the very limited address space afforded to the 16 bit programs of the day - such as Borland's Turbo Pascal which was able to map various units into a single shared memory section, swapping out which unit was loaded into that section dynamically, at the control of the parent software. This was a clever way to make larger programs than previously possible, and Microsoft's creation of a built-in model to support that in Windows 3.0 made perfect sense.
However, Its 2009. Nearly two decades later. Memory is dirt cheap. Machines regularly come with 4GB or more. Every single process in the machine can easily afford to have its own copy of every library that it needs to function, and still afford vast amounts of ram to data and disk cache and every other function the machine needs to operate well.
And over the years it has been proven time and time again that software which relies on external DLLs for code is far more fragile than those which do not. Microsoft has even had to retool the OS to explicitly account for the myriad issues surrounding DLLs (side-by-side assemblies), and the reality that software can't easily share common DLLs in practice because of subtle (and sometimes not-so-subtle) incompatibilities between versions of a common DLL. One DLL uses one STL library, and expects map<int> to have a certain size and structure, while another DLL was built using slightly different libraries or compiler or linker options that resulted in a map<int> that is not binary compatible with the other one. Suddenly, moving data between the main program and one or the other of these DLLs can lead to slicing, or to invalid memory access, or simply data corruption at the lowest possible levels, which inevitably leads to bad data or (if you're lucky) crashed applications.
The motivation to use DLLs makes no sense. It has no place in a modern computer. Its a nice theory, a fine vision, but one which in practice is a pile of paper cuts that adds up to a lacerated face... the lacerated face of your customer, bleeding all over and wondering why in the 9 hells they every bought your software!
Simply create static libraries, and link against those. It still gives you a simple way to create and maintain common code amongst multiple projects. It gives you the advantages of writing common code once, and debugging it to the benefit of all client programs. And when you fix or update some aspect of your library, you're updating or fixing every client program that relies upon it. But you're not creating a scenario where testing your software on one system is totally arbitrary and unrelated to how it might perform on another system due to different versions of a common DLL. How can you feel confident that your software is debugged if you don't even know if its the same software you're running on two different machines because whole chunks of your code may be different between the two depending on what other software was loaded on one vs. the other! And how can you rest easy knowing that depending on what other software your customer installs after yours, your software may stop working at any time - suddenly using a new version of a common DLL that you haven't tested against, and may well exhibit new and difficult to diagnose or even recognize bugs.
Again, the motivation for DLLs is long, long antiquated. Its a hang-over from an age long gone. Only the absolutely most anal-retentive amongst us would think that it has any place in today's world of software design and distribution.
DLLs are still great for dynamically loading different resources - dialogs, fonts, etc., at runtime. But they have absolutely no business loading code at runtime. Computers are already complicated enough, and already rely upon too many variables - such as the patch level of the OS itself, and the state of the registry, and so on, with out needlessly adding additional moving parts in the form of core-code that your app needs to run varying over time or machine that you're installed on.
Do yourself and your customers a favor: insulate yourself from DLL Hell - simply do not ever use DLLs for code that you write, and always supply compatible versions of 3rd party DLLs in your application's executable folder with your installs, so that your software will choose those over any other installation's copy of the DLL, and your software therefore will continue to run as correctly a year from now as it did when it was first installed.
Showing posts with label Windows. Show all posts
Showing posts with label Windows. Show all posts
Thursday, June 25, 2009
Friday, May 15, 2009
Anti-Pattern: Windows Registry
So Microsoft, back in Windows 3.x days, discovered that lots of software, when it installed or ran, needed someplace to store its persistent configuration data. And every bit of software had implemented its own way to do this. Usually using a unique flat file of some sort, and they often stored that file in the root folder, or sometimes in C:\Windows, or sometimes in their application's installation folder C:\MyProg.
So, I'm sure that they thought: hey, we can provide an OS level solution that will help developers by giving them a higher level API to use, so that they don't have to waste time reinventing the wheel, and creating their own "read configuration data" and "save configuration data" functions for every piece of software that comes out for Windows, and we can at the same time clean up the file system a little and help organize our customers computers by placing all of this data into a hive of configuration data. Heck, we'll need one ourselves, for all of our software (Microsoft's), as well as for the OS itself, so we'll kill like a thousand birds with one stone and everyone will be the better for it.
Its a well-intentioned, and good-in-theory idea. One that, at the time, I too thought was a "good thing"(tm).
However, over time it became increasingly obvious what the down-sides and limitations are to such an approach to the problem. First, there is the issue of fixing data when a configuration setting is bad / broken / wrong. This happens to software on occasion: say it recalls its last used window position from run to run, but you've had to downgrade your monitor while your good one is out to be repaired, and as a consequence, the window for this application is off the side of the screen and cannot be accessed. So you tell your customers: hey, just delete this setting from your configuration data, and everything will be fine! The application will initialize to defaults again, and all is well. But... the user needs to make this change to the very same registry that holds all of the variables that allows Windows to boot and run correctly! How often have users inadvertently changed the wrong setting, or otherwise made their machines broken or unbootable due to mis-edits in the registry!
Its just a bad idea to put application data (user-data) in the same space that the operating system uses for its very ability to function!
And when networking and user-profiles were attempted to be grafted onto the system, further problems cropped up and required that there be some of the registry hive stored as user-data, and other as system data, and the registry editor and APIs now have to navigate multiple hives behind the scenes to get it to all come out right, and it didn't always.
And I can imagine the fun it must have been at Microsoft when they realized that they needed to add security descriptors for every single hive address in their registry in order to have any ability to control the access to operating system protected parts of the system from the application's user-data portions. And how often over the years has registry security settings interfered with otherwise perfectly functional software? I know as a software user as well as developer that many, many, many times over the years our customers problems have resolved to: You deleted an account from your Windows PC and now some portion of your registry is utterly inaccessible to you or anyone on that computer, despite logging in as Administrator!
These are all nightmarish consequences of Microsoft's insistence on the registry as being the right way to store and maintain application settings. But to my mind, there is an even more basic an obvious reason that the registry is a bad idea: portability.
If I as a user want to move my settings, that I have invested real time and effort into configuring for myself, from one machine to another - say from office to home, or from an older machine to a new purchase, I often run smack into the walls put up by the registry.
I cannot simply copy my application's installation folder from one machine to another. I cannot navigate to a configuration file and copy it to the new machine. No, I have to somehow extract various settings from different parts of the registry and reassemble them on the target machine.
And how do I know what parts of the registry I'll need? I don't. Nobody does. Even software developers don't know all of the registry settings that their own applications use. Often times their installer, often written by another group or dept., will have a bunch of settings in addition to the many that the application needs. Its a common truth that many software packages fail to remove all of their entries from the registry when they're uninstalled. Perhaps a new registry entry was added between the time their installer or uninstaller was written and the various patches that were applied to the main application by the time it was uninstalled, hence rendering the uninstaller's log of what registry entries to remove long-out of date and incorrect.
If the application's data had instead simply been stored in the application's folder, then installation could be 100% accurate every time by simply deleting the folder, which is intuitive and obvious to any computer user, but which seems to be well beyond the grasp of the designers at Microsoft.
And when one looks at the problem overall, one has to wonder: Why was there an insistence on the registry? And why has it persisted all of this time? It seems to me that the dirty little secret is that many software publishers love it precisely because it does break their software when users try to copy it to a new machine! Free copy-protection, and they can blame Microsoft and claim that they aren't responsible at all. Its a Windows issue.
Well, one doesn't actually have to continue to use the Registry, and it really is more menace than aid. Its time we all admit it as a failure, and put our configuration data in a per-user and per-machine folder in a user-editable flat file, so that we can empower our customers to have clear and precise control over our software, and so that they have an easy mechanism for disaster recover, system migration, and backups that don't require a specialized knowledge and tool for extracting and restoring this information to/from the highly error-prone Windows registry.
So, I'm sure that they thought: hey, we can provide an OS level solution that will help developers by giving them a higher level API to use, so that they don't have to waste time reinventing the wheel, and creating their own "read configuration data" and "save configuration data" functions for every piece of software that comes out for Windows, and we can at the same time clean up the file system a little and help organize our customers computers by placing all of this data into a hive of configuration data. Heck, we'll need one ourselves, for all of our software (Microsoft's), as well as for the OS itself, so we'll kill like a thousand birds with one stone and everyone will be the better for it.
Its a well-intentioned, and good-in-theory idea. One that, at the time, I too thought was a "good thing"(tm).
However, over time it became increasingly obvious what the down-sides and limitations are to such an approach to the problem. First, there is the issue of fixing data when a configuration setting is bad / broken / wrong. This happens to software on occasion: say it recalls its last used window position from run to run, but you've had to downgrade your monitor while your good one is out to be repaired, and as a consequence, the window for this application is off the side of the screen and cannot be accessed. So you tell your customers: hey, just delete this setting from your configuration data, and everything will be fine! The application will initialize to defaults again, and all is well. But... the user needs to make this change to the very same registry that holds all of the variables that allows Windows to boot and run correctly! How often have users inadvertently changed the wrong setting, or otherwise made their machines broken or unbootable due to mis-edits in the registry!
Its just a bad idea to put application data (user-data) in the same space that the operating system uses for its very ability to function!
And when networking and user-profiles were attempted to be grafted onto the system, further problems cropped up and required that there be some of the registry hive stored as user-data, and other as system data, and the registry editor and APIs now have to navigate multiple hives behind the scenes to get it to all come out right, and it didn't always.
And I can imagine the fun it must have been at Microsoft when they realized that they needed to add security descriptors for every single hive address in their registry in order to have any ability to control the access to operating system protected parts of the system from the application's user-data portions. And how often over the years has registry security settings interfered with otherwise perfectly functional software? I know as a software user as well as developer that many, many, many times over the years our customers problems have resolved to: You deleted an account from your Windows PC and now some portion of your registry is utterly inaccessible to you or anyone on that computer, despite logging in as Administrator!
These are all nightmarish consequences of Microsoft's insistence on the registry as being the right way to store and maintain application settings. But to my mind, there is an even more basic an obvious reason that the registry is a bad idea: portability.
If I as a user want to move my settings, that I have invested real time and effort into configuring for myself, from one machine to another - say from office to home, or from an older machine to a new purchase, I often run smack into the walls put up by the registry.
I cannot simply copy my application's installation folder from one machine to another. I cannot navigate to a configuration file and copy it to the new machine. No, I have to somehow extract various settings from different parts of the registry and reassemble them on the target machine.
And how do I know what parts of the registry I'll need? I don't. Nobody does. Even software developers don't know all of the registry settings that their own applications use. Often times their installer, often written by another group or dept., will have a bunch of settings in addition to the many that the application needs. Its a common truth that many software packages fail to remove all of their entries from the registry when they're uninstalled. Perhaps a new registry entry was added between the time their installer or uninstaller was written and the various patches that were applied to the main application by the time it was uninstalled, hence rendering the uninstaller's log of what registry entries to remove long-out of date and incorrect.
If the application's data had instead simply been stored in the application's folder, then installation could be 100% accurate every time by simply deleting the folder, which is intuitive and obvious to any computer user, but which seems to be well beyond the grasp of the designers at Microsoft.
And when one looks at the problem overall, one has to wonder: Why was there an insistence on the registry? And why has it persisted all of this time? It seems to me that the dirty little secret is that many software publishers love it precisely because it does break their software when users try to copy it to a new machine! Free copy-protection, and they can blame Microsoft and claim that they aren't responsible at all. Its a Windows issue.
Well, one doesn't actually have to continue to use the Registry, and it really is more menace than aid. Its time we all admit it as a failure, and put our configuration data in a per-user and per-machine folder in a user-editable flat file, so that we can empower our customers to have clear and precise control over our software, and so that they have an easy mechanism for disaster recover, system migration, and backups that don't require a specialized knowledge and tool for extracting and restoring this information to/from the highly error-prone Windows registry.
Anti-UI pattern: Copying files & folders in Windows
This is another one that drives me nuts in Windows, and has been bass-ackwards now since... well, since Windows was first conceived.
DOS had options to make this work right. DOS. Venerable, ancient, command-line DOS could do this, but Windows File Manager, and later, Windows Explorer still cannot:
Copy a set of files & folders and gracefully handle problems during the copy without requiring the user to start over from the beginning, or WORSE, leaving things in a messed up half finished state when the operation fails for whatever reason (out of disk space being an obvious and common one).
WTF? I'm listening to PDC2008 video from MS that gives an overview of their "design process", that discusses the why's behind many of their decisions, and the driving principles for their UI department for Windows 7. And many of these design principles are laudable. Simplicity. Less steps to do obvious and necessary things. Less clutter and distraction. Yes, these are wonderful! But do they step back and actually look at their own OS and evaluate maybe some of the most obvious and necessary functionality with Windows (or any OS): File Management???
Apparently not, otherwise they'd have long ago discovered that their OS doesn't have the fundamental interface / tool-set to give users the ability to reliably copy or move files from one place to another with confidence that the operation will actually succeed.
Why is that? What could possibly be going through the many minds at Microsoft that leads them to ignore this fundamental requirement of a modern PC?! Windows 7 "Gestures"... while being nifty and full of novelty, don't actually represent a requirement of today's PC. Maybe they're a sales bullet point requirement from MS's marketing dept. But they are NOT a core requirement of a PC.
Copying and Moving files reliably, however, IS.
So why is it that when I use Windows vaunted Explorer, and I select a folder containing many files, does it abort the entire operation and fail to clean up after itself (roll back) or offer me the ability to remedy the failure and continue the remainder of the operation?! The latter is preferable, but the former would be acceptable, and another alternative would be to allow me to pick up & resume an operation that was partially finished (though this probably the least intuitive, and hardest to imagine a UI that would make sense to most people for).
I have had situations where 98% of my files (which can take hours to move or copy) fails at that last 2%, and the entire thing must be started over. One cannot fix the offense (say, delete a few more files on the target volume in order to free up some space for the remaining few files in the incomplete copy). One cannot choose to cleanly roll back the operation, leaving things as they were before one started. This is especially important if I was for example MOVING a few thousand files, because it then abandons the two file systems in a mixed state.
What is especially egregious about this interface is that when you go to copy things, Windows takes a small century to go through and think about the operation you're about to perform... yet, when it finally decides to begin the operation, it apparently hasn't used that thinking time to actually do any reality checks - simple things like "does the target volume have enough space for the requested operation to succeed?"
Now, mind you, that's not an especially reliable check anyway. Its a possible up-front check, which isn't the worst idea to go through with, but the reality of matter is that the target volume way well change its available space during the time that the copy or move is being performed anyway, perhaps due to another copy process, or being a shared volume in use by other clients, or for any other of a large range of reasons. So whatever check it can do up-front are only an initial reality check, and hardly any assurance of success, and shouldn't be relied upon by the copy algorithm as assurances that it doesn't have to actually handle problems on the fly.
Waaaay back in DOS one could purchase the excellent PC Tools or Symantec Tools which would give you a Text/GUI for copying, moving, and other file management operations. These competing packages both offered very smart copy, move, and error recovery. And yet today, more than a decade later, Windows has yet to provide such basic and essential maintenance support.
As long as we're on it, I might as well at least touch upon the stupidities and inadequacies of Windows Explorers security management interfaces. They're clumsy, hard to use, impossible to understand with anything less than a certificate in Windows security administration, and they do the wrong thing in most circumstances.
Say I upgraded my computer and chose to do a clean install of Windows onto a new hard drive. But I want access to all of my old files and so I keep the old hard drive around for both backup and access purposes. After completing my fresh install onto my new drive, I attach the old drive, boot to Windows, and try to access my old files. BONK! Can't read most of the folders on my old volume, due to security descriptors. Okay, so I just need to change the security to give myself access to my own files. Its something like 20-40 clicks to accomplish this, along with a long, long ass wait. I have to take ownership, add security for myself, remove any useless security from them, and these operations are exposed through a thoroughly unfriendly interface that often refuses to do what I ask it to, despite my being the Administrator on the machine to which this drive is attached. And woe is you if you actually used MS's encryption abilities on any of your files... they're goners unless you're still able to boot to the old OS in order to access them.
So why is this? Why are these things incredibly head-up-ass retarded in their convoluted, frustrating, and generally unhelpful implementation?
Microsoft is fond of thinking of itself as the company that cares about its customers, that takes pains to learn how folks use its software and to actually improve its users experiences of its products, and yet consistently they miss even the most basic usability issues with their software, be it Word, Excel, Windows, or other.
Microsoft, when can we have a marginally functional file system management tool for normal usage patterns, such as ...wait for it... copying and moving files around. I know, I know, this is a TALL order, one way up in the stratosphere of DOS level of complexity. But I would think even you guys could manage this after a full decade to think about it and do usability tests and design by committee or whatever else you needed to do to come up with a viable solution.
DOS had options to make this work right. DOS. Venerable, ancient, command-line DOS could do this, but Windows File Manager, and later, Windows Explorer still cannot:
Copy a set of files & folders and gracefully handle problems during the copy without requiring the user to start over from the beginning, or WORSE, leaving things in a messed up half finished state when the operation fails for whatever reason (out of disk space being an obvious and common one).
WTF? I'm listening to PDC2008 video from MS that gives an overview of their "design process", that discusses the why's behind many of their decisions, and the driving principles for their UI department for Windows 7. And many of these design principles are laudable. Simplicity. Less steps to do obvious and necessary things. Less clutter and distraction. Yes, these are wonderful! But do they step back and actually look at their own OS and evaluate maybe some of the most obvious and necessary functionality with Windows (or any OS): File Management???
Apparently not, otherwise they'd have long ago discovered that their OS doesn't have the fundamental interface / tool-set to give users the ability to reliably copy or move files from one place to another with confidence that the operation will actually succeed.
Why is that? What could possibly be going through the many minds at Microsoft that leads them to ignore this fundamental requirement of a modern PC?! Windows 7 "Gestures"... while being nifty and full of novelty, don't actually represent a requirement of today's PC. Maybe they're a sales bullet point requirement from MS's marketing dept. But they are NOT a core requirement of a PC.
Copying and Moving files reliably, however, IS.
So why is it that when I use Windows vaunted Explorer, and I select a folder containing many files, does it abort the entire operation and fail to clean up after itself (roll back) or offer me the ability to remedy the failure and continue the remainder of the operation?! The latter is preferable, but the former would be acceptable, and another alternative would be to allow me to pick up & resume an operation that was partially finished (though this probably the least intuitive, and hardest to imagine a UI that would make sense to most people for).
I have had situations where 98% of my files (which can take hours to move or copy) fails at that last 2%, and the entire thing must be started over. One cannot fix the offense (say, delete a few more files on the target volume in order to free up some space for the remaining few files in the incomplete copy). One cannot choose to cleanly roll back the operation, leaving things as they were before one started. This is especially important if I was for example MOVING a few thousand files, because it then abandons the two file systems in a mixed state.
What is especially egregious about this interface is that when you go to copy things, Windows takes a small century to go through and think about the operation you're about to perform... yet, when it finally decides to begin the operation, it apparently hasn't used that thinking time to actually do any reality checks - simple things like "does the target volume have enough space for the requested operation to succeed?"
Now, mind you, that's not an especially reliable check anyway. Its a possible up-front check, which isn't the worst idea to go through with, but the reality of matter is that the target volume way well change its available space during the time that the copy or move is being performed anyway, perhaps due to another copy process, or being a shared volume in use by other clients, or for any other of a large range of reasons. So whatever check it can do up-front are only an initial reality check, and hardly any assurance of success, and shouldn't be relied upon by the copy algorithm as assurances that it doesn't have to actually handle problems on the fly.
Waaaay back in DOS one could purchase the excellent PC Tools or Symantec Tools which would give you a Text/GUI for copying, moving, and other file management operations. These competing packages both offered very smart copy, move, and error recovery. And yet today, more than a decade later, Windows has yet to provide such basic and essential maintenance support.
As long as we're on it, I might as well at least touch upon the stupidities and inadequacies of Windows Explorers security management interfaces. They're clumsy, hard to use, impossible to understand with anything less than a certificate in Windows security administration, and they do the wrong thing in most circumstances.
Say I upgraded my computer and chose to do a clean install of Windows onto a new hard drive. But I want access to all of my old files and so I keep the old hard drive around for both backup and access purposes. After completing my fresh install onto my new drive, I attach the old drive, boot to Windows, and try to access my old files. BONK! Can't read most of the folders on my old volume, due to security descriptors. Okay, so I just need to change the security to give myself access to my own files. Its something like 20-40 clicks to accomplish this, along with a long, long ass wait. I have to take ownership, add security for myself, remove any useless security from them, and these operations are exposed through a thoroughly unfriendly interface that often refuses to do what I ask it to, despite my being the Administrator on the machine to which this drive is attached. And woe is you if you actually used MS's encryption abilities on any of your files... they're goners unless you're still able to boot to the old OS in order to access them.
So why is this? Why are these things incredibly head-up-ass retarded in their convoluted, frustrating, and generally unhelpful implementation?
Microsoft is fond of thinking of itself as the company that cares about its customers, that takes pains to learn how folks use its software and to actually improve its users experiences of its products, and yet consistently they miss even the most basic usability issues with their software, be it Word, Excel, Windows, or other.
Microsoft, when can we have a marginally functional file system management tool for normal usage patterns, such as ...wait for it... copying and moving files around. I know, I know, this is a TALL order, one way up in the stratosphere of DOS level of complexity. But I would think even you guys could manage this after a full decade to think about it and do usability tests and design by committee or whatever else you needed to do to come up with a viable solution.
Wednesday, May 13, 2009
Program Files (x86)
Okay, all of you Microsoft apologists out there - explain to me this: Why in tarnation does it make any sense at all to change the base pathname for legacy applications, instead of for new (x64) applications???
If MS had chosen:
C:\Program Files\
C:\Program Files (x64)\
That would have made somewhat more sense. But, why bother to divide 32bit and 64 bit applications at all? What was wrong with: C:\Program Files\ for both?
As a software developer, we would have considered it our responsibility to differentiate if we came out with a 64 bit product. It seems like an obvious thing... we write new software, we write a new installer for it, and we have it go to a different folder than our 32 bit software... or we maybe choose to place both the 32 bit and 64 bit versions in the same folder. Also a fairly obvious choice, and one we could have handled in our installer. i.e. if installing on x64, choose the 64 bit version of the exe and dlls and so on, and if installing under 32 bit OS, then choose the 32 bit versions of those files. I know for a fact that the 8 person company I work for could handle this with aplomb. I am pretty sure that even your average software development house, hell, even most corporate in-house developer teams could have handled such an obvious and simple issue.
So why the extra folder, and why rename the one that is likely to cause problems with legacy code?
If you haven't figured it out yet, then welcome to the group. I don't think there is a rational explanation. I have thought long and hard on this, and the only thing I can come up with is "group think" - design by committee. Its a stupid, stupid choice, and one that causes problems, and reflects the general pattern at Microsoft of disorganization. It was always horrendously shallow to choose an arbitrary folder like "Program Files" to shove... literally, everything you install on your machine into. Why not: Games, Productivity Apps, Tools & Utilities, and so on, actually organizing one's file system by some rational design?
Putting everything one owns into the same drawer is by definition not a system of organization at all. One must actually differentiate between things and group them by some level of conscious choice for there to be intelligence and organization in the system. Microsoft just doesn't seem to grasp the concept, and never has.
Its a stupid shame - and one that will doubtless cause many users grief and frustration as their software that used to work stops working, due to the broken paths. Here's an obvious example: In Vista and in Windows 7 we have the new "Games Explorer", where you can access all of the games on your PC from one convenient place. However, In many circumstances Windows shows the wrong icon for your game! You can take a what appears to be a well-formed shortcut from your start menu and copy it into your games explorer, only to have games explorer change the icon and substitute something retarded for it. At first this seems bizarre (in a way that only Windows is - commonly getting even the most basic things wrong). But then, you think: "I can fix that - just change the associated icon!" Hmm... well, Microsoft comes to the failure again by not providing a "properties" setting on many of the shortcuts - especially it would seem on the ones you add by hand from shortcuts!!!! Okay, well, that's bizarre (in a very Windows-way - where failure and stupidity seem to be "Job #1"). But maybe there was something wrong with the original shortcut, even though they appear correct in the Start Menu. You edit the start menu, get properties on the shortcut you need, and low-and-behold, the "change icon" dialog complains that it cannot find "%Program Files%/blah/blah/some.ico"!!! Seriously?! You've got to be kidding me, Microsoft?! Your idiotic decision to rename Program Files to Program Files (x86) now means that all of my 32 bit software's shortcuts will all always be wrong?! Wow. Just... wow.
I've also seen software that creates the old legacy paths for various things because the developer didn't realize that there was a dynamic way to get the paths from the OS, combined with MS's penchant for changing the rules every single time they release an OS (oh yeah, it makes perfect sense to change things arbitrarily from one bad system to another without actually making any gains in the process... that's surely someone's definition of "progress"... it just isn't any rational being's definition).
Or do you see the sense in Program Files (x86)?
If MS had chosen:
C:\Program Files\
C:\Program Files (x64)\
That would have made somewhat more sense. But, why bother to divide 32bit and 64 bit applications at all? What was wrong with: C:\Program Files\
As a software developer, we would have considered it our responsibility to differentiate if we came out with a 64 bit product. It seems like an obvious thing... we write new software, we write a new installer for it, and we have it go to a different folder than our 32 bit software... or we maybe choose to place both the 32 bit and 64 bit versions in the same folder. Also a fairly obvious choice, and one we could have handled in our installer. i.e. if installing on x64, choose the 64 bit version of the exe and dlls and so on, and if installing under 32 bit OS, then choose the 32 bit versions of those files. I know for a fact that the 8 person company I work for could handle this with aplomb. I am pretty sure that even your average software development house, hell, even most corporate in-house developer teams could have handled such an obvious and simple issue.
So why the extra folder, and why rename the one that is likely to cause problems with legacy code?
If you haven't figured it out yet, then welcome to the group. I don't think there is a rational explanation. I have thought long and hard on this, and the only thing I can come up with is "group think" - design by committee. Its a stupid, stupid choice, and one that causes problems, and reflects the general pattern at Microsoft of disorganization. It was always horrendously shallow to choose an arbitrary folder like "Program Files" to shove... literally, everything you install on your machine into. Why not: Games, Productivity Apps, Tools & Utilities, and so on, actually organizing one's file system by some rational design?
Putting everything one owns into the same drawer is by definition not a system of organization at all. One must actually differentiate between things and group them by some level of conscious choice for there to be intelligence and organization in the system. Microsoft just doesn't seem to grasp the concept, and never has.
Its a stupid shame - and one that will doubtless cause many users grief and frustration as their software that used to work stops working, due to the broken paths. Here's an obvious example: In Vista and in Windows 7 we have the new "Games Explorer", where you can access all of the games on your PC from one convenient place. However, In many circumstances Windows shows the wrong icon for your game! You can take a what appears to be a well-formed shortcut from your start menu and copy it into your games explorer, only to have games explorer change the icon and substitute something retarded for it. At first this seems bizarre (in a way that only Windows is - commonly getting even the most basic things wrong). But then, you think: "I can fix that - just change the associated icon!" Hmm... well, Microsoft comes to the failure again by not providing a "properties" setting on many of the shortcuts - especially it would seem on the ones you add by hand from shortcuts!!!! Okay, well, that's bizarre (in a very Windows-way - where failure and stupidity seem to be "Job #1"). But maybe there was something wrong with the original shortcut, even though they appear correct in the Start Menu. You edit the start menu, get properties on the shortcut you need, and low-and-behold, the "change icon" dialog complains that it cannot find "%Program Files%/blah/blah/some.ico"!!! Seriously?! You've got to be kidding me, Microsoft?! Your idiotic decision to rename Program Files to Program Files (x86) now means that all of my 32 bit software's shortcuts will all always be wrong?! Wow. Just... wow.
I've also seen software that creates the old legacy paths for various things because the developer didn't realize that there was a dynamic way to get the paths from the OS, combined with MS's penchant for changing the rules every single time they release an OS (oh yeah, it makes perfect sense to change things arbitrarily from one bad system to another without actually making any gains in the process... that's surely someone's definition of "progress"... it just isn't any rational being's definition).
Or do you see the sense in Program Files (x86)?
Friday, May 8, 2009
Windows 7...
So... MS made a great product some years ago. An OS that pleased almost everyone, that was fairly simple to use, had great capabilities, could do business software, interconnect with printers, scanners, fax machines, connect to the internet, and supported vast hard drives, was quick and responsive to the user, and could be easily tweaked to your personal needs. It was the pinnacle of an age of OS technology... no, I'm not talking about Windows 7, or even XP. I'm talking about Windows 98. The ultimate hybrid of 32 bit processing and DOS mode kernel, bringing to near perfection computing on a PC. Sure there were still glitches here and there, nothing is perfect. But in many ways I contend that Windows 98 was superior to Vista, and the up coming Windows 7 from the "what does it do for me" and "ease of use" POV.
Windows XP was another high point in MS's OSes. It had the enhanced stability of the NT core combined with the vastly superior user interface supported by Windows 98, bringing to the masses a truly 32 bit OS with no legacy DOS compromises that was at once easy to use, hugely configurable and extensible by software developers, while offering robust support for the latest 32 bit technology of the chips of the day. This did away with the limitations of fixed USER, KERNEL and GUI heap sizes of Windows 98 once and for all. Gone was a need to regularly reboot the machine in order to get back missing resources that slowly leaked away into a no-mans land of purgatory, awaiting the next reboot to live again. NTFS was the new defacto file system, bringing with it massive improvements in file storage efficiency over the aging and stretched to nearly breaking FAT32 filesystem, giving us an underlying transaction oriented filesystem with much room to grow and adapt to future hardware capabilities. And much like Windows 95, XP was very well received... in time.
It is easy to forget now the many voices of distrust and dislike of XP at the time. But XP was initially criticized on many levels, for breaking compatibility with Win 9x games and software, and for foisting upon users the more error-prone and complex world of security attributes on the registry and filesystem, and user accounts that could easily prevent various software from functioning properly, or which could lock out your computer from being usable at all, were you so foolish as to forget the only account password for your machine. But in time, most folks saw that the relaxation of, and in some cases, complete disappearance of restrictions from the old DOS-kernel based 9x OSes by XP was a worthy trade-up, and the nay-sayers voices died down in a general atmosphere of contentment with XP. After all, it had taken Microsoft many years to bring the vision of a truly new OS, written from the ground up as a 32 bit fully preemptive micro-kernel-esque to the masses. An OS that was inherently stable, extensible, robust in every way, and secure enough internally as to rate a C2 level from the government. Modern computing was finally here! No more crashing the machine when a single buggy application experienced a failure. No longer would one application be able to grab access to another's memory, or to mess with any other component's state and cause harm to your PC. The dream appeared real, and for the most part, functional.
But having a single OS that both business and consumers use proved a fantastically huge target for the unscrupulous amongst us. Virus writers, malware writers, phishers, net bots, and so on found a fantastic wealth of users who didn't know how to protect themselves from the explosion of connectivity available during that time, and so Microsoft got something of a tarnished reputation for the guys that make the OS that is susceptible to every virus, malware, and bot-net ever conceived.
From there, MS, motivated to avoid losing its dominance in both the consumer market and the business market, has made more and more strident attempts to quash this reputation.
Sadly, this is what has inexorably lead to Vista and Windows 7. Not that this is all that Vista and Windows 7 are about. There is a great deal of focus and good design behind C#, and the .NET platform as a whole. There are some excellent improvements to the video device driver model, as well as to the sound subsystem. And intertwined with all of these other improvements has been the largely unheralded creation of x64 based versions of XP and Vista, with solid device driver support for the lion's share of devices for Vista x64 edition. All of those improvements are just that: improvements. They don't take anything away from the end-user, they don't make it harder to use one's computer, they only create an enhanced set of capabilities for a computer running Vista / Windows 7, especially x64.
However, all of these advancements are overshadowed by ineptitude of MS's security model. It seems to me that many parallels could be drawn between MS's wrong-headed approach to security and this nation's wrong-headed approach to foreign diplomacy under the Bush administration. Both sought to improve the security of its "citizens", and both created an atmosphere in which the evildoers and the enforcers thrive at the expense of their citizens. Our rights as owners of our own computers are less today than they were when XP was introduced, which itself restricted some of our former rights under 98.
The intent is understandable. We all want to have our computers virus, and malware, free. We want our data to be off-limits from those who aren't authorized to view it. We want our computers to remain functional under an attack - to prove stronger than the virus or malware its subjected to as we browse the wild west of the Internet. That's a laudable goal.
However, MS has built walls the likes of which can only be seen in Israel and in the formerly partitioned Germany. The very idea of such walls is contrary to freedom, to the free flow of ideas, and to empowering citizens to be able to accomplish what they want with their own computers. It takes away control from the hands of owners (users), and puts it in the hands of overseers (Microsoft). Which from some obviously Machiavellian perspective fits Microsoft's overall business goals perfectly: they gain control of everyone's PCs making people all the more dependent upon Microsoft and its affiliates for relief from problems that arise, and it helps move the entire notion of a computer away from an ownership by the end-user model towards a rental model where Microsoft remains firmly in control. Chances are good that these thoughts have occurred to Steve Ballmer or other luminaries at Microsoft. I'm equally sure that they're not the primary goal or driving force behind MS. There is no conspiracy, just motivating factors. And giving Microsoft more control, and users and businesses even more reason to need MS in order to function well, can only be seen as a good thing to those who wish to get as much as they can out of our wallets at MS (which is by definition the primary goal of any corporation's share-holders, and therefor the primary goal of the corporation's senior management).
When it comes right down to it, Vista and Windows 7's penchant for creating an even more complicated environment in which to operate as an end user is fundamentally a bad idea. It necessitates middle men to become the high priests of computers, specialized individuals who have the aptitude and training to maintain end-users and businesses computers in the face of the growing complexity of doing so. It encourages users to become ever more complacent, ever more putting themselves in the hands of an expert with no hope for taking control of their machines, of having any real understanding or ability to control them and make them work for them, and adapt to their needs, rather than the other way around.
We are more and more forced to become slaves to our computers, forced to figure out how to make them function for what we need to accomplish within the ever-more-restricted environments that they present to us, all in the name of "security."
But I ask you - what security? Real security, measurable with actual results? Or the illusion of security. The sense that it is hard for a virus to succeed because it is hard for us to succeed at using our own machines? But is there any concrete evidence that a machine, running Windows Vista or Windows 7, is any less susceptible to current viruses and malware and net bots than the same machine running Windows 98 or XP? I doubt it. I very much doubt it.
Now, I'm sure that given MS's marketing dept, a reasonable-sounding case can be made that seems like MS has made gains in theses areas. However, ask yourself: "do I feel more confident about my computer now than I did 5 years ago?" Or, "when a virus strikes, am I more or less confident that I can rid my machine of it and restore it to full operation without losing my files and configuration settings on my machine now as compared to 5 years ago?"
I suspect that, like me, you don't feel more confident now on either count. That, in truth, the complexity that makes our machines harder to understand, and harder to control works in favor of the virus writers (who can specialize in this technology) and against ourselves, who are by definition not going to specialize in every nuance of the ever-changing complexities of MS's security measures.
The fact of the matter, from the most obvious and simple stand-point, is that obscurity and complexity aids the bad guys, and transparency and simplicity aids the common person. If everyone knows the rules, then everyone can figure out how to fix it, or at least a much, much larger pool of folks can, which means that viruses are only that much more easily removed and rendered useless. They're also easier to detect, since the system as a whole is easier to understand and see what its supposed to do, and easier to see when its functioning incorrectly.
At the absolute minimum, I would be content if MS would take its ill-thought-out war on simplicity over to its business-only side of the fence. I think its still a disservice to its business customers for much the same reason that I think its a foolish policy in general, anywhere and anytime, but at least there is some real motivation from the business side... primarily in the form of "I don't care if MS bilks bajillions of dollars from a stupid sheep-like business community", but I do care if they debilitate ever man woman and child in their ill-considered quest for world-domination and perfect security.
Home users don't need, nor want, for the most part, a security model that gets in the way of actually accomplishing productive uses for their costly computers. I want my PC to auto-detect other computers on my LAN. I want to share files with my family easily. I want to be able to print to any printer on my LAN without the need for a masters in the bizarre underworld of MS "security." My wife wishes to install and play games as painlessly as possible. My daughter wants to get onto facebook or myspace and hang out with her friends. She doesn't understand, nor should she be required to understand or see or ever have to deal with a retarded "are you sure you want to install blah-blah-blah"?
If software wants to install onto a computer, a simple signature verification should be issued, and confirmed, and a user-friendly and comprehensible dialog asking if you trust X vendor should be shown. If you trust that vendor, then the software is installed and given enough rights to perform its duties. If you don't, it isn't, end of story. And if it doesn't have proper credentials, then it simply shouldn't be allowed at all except by a super-user / administrator. I, as owner of the machine, should have the right to shoot myself in the foot. Its my computer, and hence my prerogative.
But perhaps now we're wandering into a cultural stupidity that needs to be resolved in America before some of these idiocies of technology can be properly addressed. The idea of personal responsibility.
Currently, we seem to be leaning ever so precipitously over the edge of a cliff of "its someone else's responsibility at all times" attitude in this nation. An attitude that is so incredibly at odds with those of our parents and their parents and on back to the settlers and immigrants that founded this nation. If I override the warnings, and install something that ultimately is harmful to me... that IS MY OWN DAMN FAULT. It isn't MS's for failing to warn me adequately. It isn't my governments for failing to protect me adequately. It isn't my parents for failing to teach me adequately. IT IS MY OWN DAMN FAULT. I am responsible for my actions. Me and me alone. And if I do something retarded... well, I suffer the consequences. Not sue someone. "I did something stupid: so pay me lots of money because you should have made it impossible for me to be an idiot." -- who the fuck thought that this was a reasonable approach to life, and why do we as a nation seem to be wedded to this intellectually, morally, and spiritually vacuous and ultimately self-defeating idea?
Gross negligence should be the burden of the plaintiff. And if the negligence isn't gross, obvious, systematic, and otherwise blatantly out of control, then the fault is not the companies, not the governments, but the individuals. You chose to buy the cup of coffee. If you're too fucking dumb to know its really hot and hot things are owie when spilled, then you're too fucking stupid to live on this planet and fuck you already.
And I don't want to live in a world filled with limitations on what I can do with the things I buy because the manufacturer is terrified that I'll sue (and win) over their failure to stop me from being a fucking idiot. Idiots have removed themselves from the gene pool from time immemorial by virtue of their own stupidity. There is no reason to think that this is a bad thing. There is no reason that I can think of that society should endeavour or waste any resources on protecting such idiots from themselves (Though, there is a good reason to protect the larger society from such idiots).
So, in a nutshell, Windows 7 is Vista with a few minor visual baubles, and the myriad patches necessary to make Vista stable, and a continuation of the misguided policies at Microsoft which further alienate the American public and solidify their reputation for being an error-prone and user-unfriendly OS and company in general.
Apple gets no love from me, but that's a rant for another day.
And that's my take on Windows 7. God help us all.
Windows XP was another high point in MS's OSes. It had the enhanced stability of the NT core combined with the vastly superior user interface supported by Windows 98, bringing to the masses a truly 32 bit OS with no legacy DOS compromises that was at once easy to use, hugely configurable and extensible by software developers, while offering robust support for the latest 32 bit technology of the chips of the day. This did away with the limitations of fixed USER, KERNEL and GUI heap sizes of Windows 98 once and for all. Gone was a need to regularly reboot the machine in order to get back missing resources that slowly leaked away into a no-mans land of purgatory, awaiting the next reboot to live again. NTFS was the new defacto file system, bringing with it massive improvements in file storage efficiency over the aging and stretched to nearly breaking FAT32 filesystem, giving us an underlying transaction oriented filesystem with much room to grow and adapt to future hardware capabilities. And much like Windows 95, XP was very well received... in time.
It is easy to forget now the many voices of distrust and dislike of XP at the time. But XP was initially criticized on many levels, for breaking compatibility with Win 9x games and software, and for foisting upon users the more error-prone and complex world of security attributes on the registry and filesystem, and user accounts that could easily prevent various software from functioning properly, or which could lock out your computer from being usable at all, were you so foolish as to forget the only account password for your machine. But in time, most folks saw that the relaxation of, and in some cases, complete disappearance of restrictions from the old DOS-kernel based 9x OSes by XP was a worthy trade-up, and the nay-sayers voices died down in a general atmosphere of contentment with XP. After all, it had taken Microsoft many years to bring the vision of a truly new OS, written from the ground up as a 32 bit fully preemptive micro-kernel-esque to the masses. An OS that was inherently stable, extensible, robust in every way, and secure enough internally as to rate a C2 level from the government. Modern computing was finally here! No more crashing the machine when a single buggy application experienced a failure. No longer would one application be able to grab access to another's memory, or to mess with any other component's state and cause harm to your PC. The dream appeared real, and for the most part, functional.
But having a single OS that both business and consumers use proved a fantastically huge target for the unscrupulous amongst us. Virus writers, malware writers, phishers, net bots, and so on found a fantastic wealth of users who didn't know how to protect themselves from the explosion of connectivity available during that time, and so Microsoft got something of a tarnished reputation for the guys that make the OS that is susceptible to every virus, malware, and bot-net ever conceived.
From there, MS, motivated to avoid losing its dominance in both the consumer market and the business market, has made more and more strident attempts to quash this reputation.
Sadly, this is what has inexorably lead to Vista and Windows 7. Not that this is all that Vista and Windows 7 are about. There is a great deal of focus and good design behind C#, and the .NET platform as a whole. There are some excellent improvements to the video device driver model, as well as to the sound subsystem. And intertwined with all of these other improvements has been the largely unheralded creation of x64 based versions of XP and Vista, with solid device driver support for the lion's share of devices for Vista x64 edition. All of those improvements are just that: improvements. They don't take anything away from the end-user, they don't make it harder to use one's computer, they only create an enhanced set of capabilities for a computer running Vista / Windows 7, especially x64.
However, all of these advancements are overshadowed by ineptitude of MS's security model. It seems to me that many parallels could be drawn between MS's wrong-headed approach to security and this nation's wrong-headed approach to foreign diplomacy under the Bush administration. Both sought to improve the security of its "citizens", and both created an atmosphere in which the evildoers and the enforcers thrive at the expense of their citizens. Our rights as owners of our own computers are less today than they were when XP was introduced, which itself restricted some of our former rights under 98.
The intent is understandable. We all want to have our computers virus, and malware, free. We want our data to be off-limits from those who aren't authorized to view it. We want our computers to remain functional under an attack - to prove stronger than the virus or malware its subjected to as we browse the wild west of the Internet. That's a laudable goal.
However, MS has built walls the likes of which can only be seen in Israel and in the formerly partitioned Germany. The very idea of such walls is contrary to freedom, to the free flow of ideas, and to empowering citizens to be able to accomplish what they want with their own computers. It takes away control from the hands of owners (users), and puts it in the hands of overseers (Microsoft). Which from some obviously Machiavellian perspective fits Microsoft's overall business goals perfectly: they gain control of everyone's PCs making people all the more dependent upon Microsoft and its affiliates for relief from problems that arise, and it helps move the entire notion of a computer away from an ownership by the end-user model towards a rental model where Microsoft remains firmly in control. Chances are good that these thoughts have occurred to Steve Ballmer or other luminaries at Microsoft. I'm equally sure that they're not the primary goal or driving force behind MS. There is no conspiracy, just motivating factors. And giving Microsoft more control, and users and businesses even more reason to need MS in order to function well, can only be seen as a good thing to those who wish to get as much as they can out of our wallets at MS (which is by definition the primary goal of any corporation's share-holders, and therefor the primary goal of the corporation's senior management).
When it comes right down to it, Vista and Windows 7's penchant for creating an even more complicated environment in which to operate as an end user is fundamentally a bad idea. It necessitates middle men to become the high priests of computers, specialized individuals who have the aptitude and training to maintain end-users and businesses computers in the face of the growing complexity of doing so. It encourages users to become ever more complacent, ever more putting themselves in the hands of an expert with no hope for taking control of their machines, of having any real understanding or ability to control them and make them work for them, and adapt to their needs, rather than the other way around.
We are more and more forced to become slaves to our computers, forced to figure out how to make them function for what we need to accomplish within the ever-more-restricted environments that they present to us, all in the name of "security."
But I ask you - what security? Real security, measurable with actual results? Or the illusion of security. The sense that it is hard for a virus to succeed because it is hard for us to succeed at using our own machines? But is there any concrete evidence that a machine, running Windows Vista or Windows 7, is any less susceptible to current viruses and malware and net bots than the same machine running Windows 98 or XP? I doubt it. I very much doubt it.
Now, I'm sure that given MS's marketing dept, a reasonable-sounding case can be made that seems like MS has made gains in theses areas. However, ask yourself: "do I feel more confident about my computer now than I did 5 years ago?" Or, "when a virus strikes, am I more or less confident that I can rid my machine of it and restore it to full operation without losing my files and configuration settings on my machine now as compared to 5 years ago?"
I suspect that, like me, you don't feel more confident now on either count. That, in truth, the complexity that makes our machines harder to understand, and harder to control works in favor of the virus writers (who can specialize in this technology) and against ourselves, who are by definition not going to specialize in every nuance of the ever-changing complexities of MS's security measures.
The fact of the matter, from the most obvious and simple stand-point, is that obscurity and complexity aids the bad guys, and transparency and simplicity aids the common person. If everyone knows the rules, then everyone can figure out how to fix it, or at least a much, much larger pool of folks can, which means that viruses are only that much more easily removed and rendered useless. They're also easier to detect, since the system as a whole is easier to understand and see what its supposed to do, and easier to see when its functioning incorrectly.
At the absolute minimum, I would be content if MS would take its ill-thought-out war on simplicity over to its business-only side of the fence. I think its still a disservice to its business customers for much the same reason that I think its a foolish policy in general, anywhere and anytime, but at least there is some real motivation from the business side... primarily in the form of "I don't care if MS bilks bajillions of dollars from a stupid sheep-like business community", but I do care if they debilitate ever man woman and child in their ill-considered quest for world-domination and perfect security.
Home users don't need, nor want, for the most part, a security model that gets in the way of actually accomplishing productive uses for their costly computers. I want my PC to auto-detect other computers on my LAN. I want to share files with my family easily. I want to be able to print to any printer on my LAN without the need for a masters in the bizarre underworld of MS "security." My wife wishes to install and play games as painlessly as possible. My daughter wants to get onto facebook or myspace and hang out with her friends. She doesn't understand, nor should she be required to understand or see or ever have to deal with a retarded "are you sure you want to install blah-blah-blah"?
If software wants to install onto a computer, a simple signature verification should be issued, and confirmed, and a user-friendly and comprehensible dialog asking if you trust X vendor should be shown. If you trust that vendor, then the software is installed and given enough rights to perform its duties. If you don't, it isn't, end of story. And if it doesn't have proper credentials, then it simply shouldn't be allowed at all except by a super-user / administrator. I, as owner of the machine, should have the right to shoot myself in the foot. Its my computer, and hence my prerogative.
But perhaps now we're wandering into a cultural stupidity that needs to be resolved in America before some of these idiocies of technology can be properly addressed. The idea of personal responsibility.
Currently, we seem to be leaning ever so precipitously over the edge of a cliff of "its someone else's responsibility at all times" attitude in this nation. An attitude that is so incredibly at odds with those of our parents and their parents and on back to the settlers and immigrants that founded this nation. If I override the warnings, and install something that ultimately is harmful to me... that IS MY OWN DAMN FAULT. It isn't MS's for failing to warn me adequately. It isn't my governments for failing to protect me adequately. It isn't my parents for failing to teach me adequately. IT IS MY OWN DAMN FAULT. I am responsible for my actions. Me and me alone. And if I do something retarded... well, I suffer the consequences. Not sue someone. "I did something stupid: so pay me lots of money because you should have made it impossible for me to be an idiot." -- who the fuck thought that this was a reasonable approach to life, and why do we as a nation seem to be wedded to this intellectually, morally, and spiritually vacuous and ultimately self-defeating idea?
Gross negligence should be the burden of the plaintiff. And if the negligence isn't gross, obvious, systematic, and otherwise blatantly out of control, then the fault is not the companies, not the governments, but the individuals. You chose to buy the cup of coffee. If you're too fucking dumb to know its really hot and hot things are owie when spilled, then you're too fucking stupid to live on this planet and fuck you already.
And I don't want to live in a world filled with limitations on what I can do with the things I buy because the manufacturer is terrified that I'll sue (and win) over their failure to stop me from being a fucking idiot. Idiots have removed themselves from the gene pool from time immemorial by virtue of their own stupidity. There is no reason to think that this is a bad thing. There is no reason that I can think of that society should endeavour or waste any resources on protecting such idiots from themselves (Though, there is a good reason to protect the larger society from such idiots).
So, in a nutshell, Windows 7 is Vista with a few minor visual baubles, and the myriad patches necessary to make Vista stable, and a continuation of the misguided policies at Microsoft which further alienate the American public and solidify their reputation for being an error-prone and user-unfriendly OS and company in general.
Apple gets no love from me, but that's a rant for another day.
And that's my take on Windows 7. God help us all.
Subscribe to:
Posts (Atom)
Posts
