The average PC has several orders of magnitude more disk space and memory than ten years ago, but developers are still sacrificing ease of use for a few megabytes.
My MSN Messenger stopped working mysteriously a few days ago. I could not log in, and the silly program just gave me a numerical error code and told me that some ‘key ports’ were not accessible. At first, I blamed temporary network problems, but when the guy next to me logged in, that explanation no longer seemed right. After about three hours of network troubleshooting, restarting, reinstalling, deleting, restarting again and other obvious attempts to make it work, I became quite annoyed. MSN messenger has somehow established itself as a my primary method of communication with customers, so I really need it to work. Searching for that strange numerical code on Google at least provided some comfort – I was not alone. However, none of the solutions seemed related to MSN – some poor soul had his proxy settings in IE changed by a virus, causing an error with the same numerical ID. I did not really see what IE proxies have to do with MSN, but at that point, I would even go for black magic if it worked. A quick check at the network configuration dialog of IE could not hurt, I thought. There were no proxies defined, but some other strange check-box was confirmed on that dialog, setting a ‘profile override file’. I unchecked it and the silly messenger logged in.
My messenger is apparently a browser
I used Selenium the day before to automate Web front-end tests, and the engine apparently did not clean up it’s IE configuration after a failed test. I use Firefox normally, and load IE only for occasional testing, so I did not notice that the browser was also not working. Huh… three hours wasted because of shared components.
I appreciate the attempt of Microsoft’s developers to save my disk space and RAM, but I would appreciate it even more if the computer did not have to restart after the messenger is re-installed. It’s like asking me to sleep a night in the hotel just because I had to change a light-bulb in my home. And I would really like the stupid messenger to disappear when I uninstall it and delete the files, not to come back as some undead monster and haunt me.
Is it also an IDE?
After a few hours, Visual Studio 2005 failed to open a project that was saved with VS2005+service pack 1, so I had to upgrade the IDE also. The patch was some 450 MB, so I downloaded it, let it run, changed my messenger status to ‘Out to lunch’, and went to get some food. When I came back, instead of a message telling me that the installation is over, I found a dialog insisting that MSN messenger should be closed because it’s blocking the upgrade. Ok, on some strange level I understand why messenger and IE share components, but what the hell does Visual Studio have in common with a messenger, and why did they not just statically link the library and store it in the application folder? Why does an IDE have to upgrade a messaging program?
Unfortunately, the trouble did not end there. I closed the messenger, let the installation run again, only to crash 30 minutes later due to some strange privilege problem. Google helped again, and I found out that to install a service pack for my IDE I had to define new local system security policies. It seems that those 450 MB of Visual Studio service pack did not only contain an upgrade for my messenger, but for the Windows also.
Yet another premature optimisation
Shared DLLs were a good idea, ten years ago. The technology has advanced enough to make a few megabytes on disk and in memory irrelevant. My current PC has several orders of magnitude more disk space and memory than the one I had 10 years ago, so I’m not really bothered if a DLL loads twice, but I do mind when I lose an entire day because of silly software dependencies. Code reuse was, and still is, a good thing – but shared deployments are not. Microsoft is not the only one to blame, I see the ‘sharing’ issue in enterprise software often (and I do it myself occasionally, to be fair). But never before did it strike me that shared deployment is a relict of the past, solution for a problem long gone, but we are still fighting against it in our heads. I’m not advocating memory leaks or taking up all available RAM and never releasing it, but the problem solved by shared DLLs is just like a scarecrow – simply not real.
Whatever Visual Studio, IE and MSN messenger have in common, it could easily be replicated three times and it would not make any real difference on system performance. Using shared kernel functions is undoubtedly justified, but I think that developers need to wake up to the fact that using shared components does more damage than good. So much memory and disk space is wasted on other issues that those few megabytes hardly make any difference. Like bit-packing and union structures, messing with shared DLLs without a good reason should not be regarded best practice any more, but as a premature optimisation.
Image credits: JMJVicente/SXC and Coby/SXC
|
|
What you seem to be missing is that it is simply not practical for every software vendor to manage security patches for an entire TCP/IP stack. That seems to be what you advocate, even if you don’t realize it.
So you want everyone to statically link a library instead of using wininet.dll. Fine. Now a security flaw is found in some prior version of the code. Now what? You now need to apply 50 patches, instead of one. How’s that for “ease of use?”
That is just one issue to consider. User-affecting bugs would be another–now every application developer needs to issue patches to fix issues that would be resolved in a single Windows Update. Is your application hanging for two minutes at startup when your machine is not joined to a domain? Well, you need to go talk to the ISV who statically linked the code about that. Oh, they went out of business? I hope you got their code so that you can recompile it yourself.
Believe it or not, shared proxy server settings is a great usability victory in a corporate setting (which tends to be the only setting in which proxy servers are used).
“I’m not advocating memory leaks or taking up all available RAM and never releasing it, but the problem solved by shared DLLs is just like a scarecrow – simply not real.”
That’s a major non-sequitur at best, and seems to suggest to me that you don’t actually understand how DLL’s work or what problems they solve.
Hi Dan,
fair enough, I should have been more precise. But you’ve missed my point:
In this case, neither IE nor MSN messenger (and especially not VS) should be updating that DLL – windows update should take care of that. I consider wininet a part of the system kernel, not MSN messenger. Third-party messengers like GAIM and Skype still use wininet, but do not require half of the system to be shut down to install or update properly.
I understand the frustration with your particular misconfiguration problem, but a lot of it seems to be application suckage unrelated to the more general concept of using shared libraries.
If you are (as I gather from the post) writing .NET software, you are committing essentially the same sin. To install one of your applications, a user may need to upgrade their runtime (say, from 1.1 to 2.0). That would require shutting down any process running the previous version, and after Vista that includes operating system components.
You shouldn’t need to stop the applications, you say? Well, there’s no good way to make this happen. You need to restart applications to refresh the code running in them, which is typically the point of applying security patches.
I suppose the moral here is that you can’t have your cake and eat it too.
Of course, it’s normal to expect that an application would be stopped in order to update it, but I see no good reason why other unrelated applications should have to be stopped also. As for .Net runtimes, I agree, it’s not that clean – Java is cleaner as I can pack a private JVM along with the application.
Shutting down unrelated applications may not be avoidable when the Framework is being updated, but I guess that a majority of upgrades are not that critical, and they still require a general anesthesia of the system. It’s normal to expect that you need to move out for a week if the new central heating system is installed, but you would not expect the same if when you buy a new TV set. Shutting down the system for application upgrades might have been
justified in the past (and still is when a key security patch or system upgrade is being applied), but I don’t really think that most of the application upgrades can justify it today.
Maybe you can’t have your cake and eat it too, but you don’t need to keep the fridge door open while you are eating it.
It’s entirely possible to have usable shared libraries, see Mac OS X. Memory consumption would explode without them. The fact that Microsoft’s current implementation is broken does not make the concept broken.
I think a bad implementation of shared libraries is one of the things to blame in this case. It’s unlikely that your IM application and IDE need to be running the same version of whatever component they share in lockstep.
Open apps should continue to use whatever versions of whatever shared libraries they launched with. As they are closed and reopened, they should pick up the newly installed components invisibly.