Archive | January, 2003

These are some essays I just recently found, dated 1998 and 1999, that express some of the frustrations or dealing with Microsoft. I was amused to find the situation just as bad, although a tad dated, four and five years later.

DLL Pickle (31-July-1998)

The DLL model is broken. It always has been.

For those of you not deep into the Microsoft model of software computing, here’s a quick primer on the idea of DLLs: a DLL (so called because that is usually its three-letter file name extension) is a Dynamic Link Library, a collection of programming routines compiled together into one file. DLLs typically live in the Windows system directory, and are used by many programs.

The concept behind the DLL is attractive. Why not take a routine needed by many tasks and write it only once, install it in a place where it is accessible by all, and then all programs can share it. The idea is good. Sharing common routines allows them to be written and debugged once. This enhances code reuse, lowering the cost of writing later software that use those routines, lowering the hard disks usage requirements, and simplifying the coding and testing of new software. In addition, if these DLLs are written so that they can be called from many applications, but be loaded into memory only once, significant savings in memory usage can be achieved. In theory, anyway.

This model would be great if these DLLs could be written once, written right, and supported everything needed of them from the beginning. But the reality of software development is that these routines may not be coded to meet all needs the first time out. Plain old bugs that cause the routine not to work correctly will be missed in the first release, showing themselves only when tested on new hardware platforms, or perhaps only under unusual circumstances.

So the routines need to be rewritten and revised. Microsoft anticipated this problem, and introduced support for a version number branded into each DLL, so that later versions of the DLL could be shipped with later software and replace the earlier, buggy, versions. But there are two bad assumptions in this scheme.

The first bad assumption is that any programmer could write routines that were “new and improved” and at the same time, fully backward compatible. Software developers, living in the real world where real software actually has to be delivered, did their best to work with the original DLLs, occasionally having to write work-arounds or depending on undocumented behaviors to get their software to work. When a DLL was revised, “fixed” in some people’s opinions, those behaviors changed and software broke. Who was at fault? The developer of the software or the author of the DLL? Certainly a point of debate.

The second bad assumption was that the version numbers would be controlled in such a way that a later version was always an improved copy of an earlier version, Mistakes happen, and DLLs were mistakenly misnumbered leading to a “rogue” DLL with an incorrect number taking over a system. If the number were greater than it should be, newer software would be unable to replace the supposed “later” DLL, and conflicts would occur when this older DLL failed to perform as anticipated.

The problem is most apparent in the “shared” or “common” DLLs that provide services used by a number of applications. Common DLLs, often prefaced by :”COM” such as COMCTL32.DLL and COMDLG.DLL, provide controls and dialogs used by many applications. A change in the error messages returned by these routines or the format of the information available from these DLLs crash systems left and right.

The Quality Assurance effort at Microsoft to avoid these problems is insufficient to the task. If a common control needs a change in order to work with a new version of Visual Fred, the DLL is tested with Visual Fred, but not necessarily tested with the hundreds of other products which may also be using this DLL. As Microsoft is in the business of selling development tools, it needs to test not only its own tools, but the software that can be generated with their tools, to ensure that changes to the DLL do not cause these products to fail as well. Any product which could use a DLL, not matter how obscure, needs to run a comprehensive test on that DLL, checking all of the functions, inputs and outputs, to ensure full compatibility. If the DLL cannot survive these tests, it should not be released upon an unsuspecting public.

An alternative to this difficult regime is one used on other operating systems. When a new common module is installed, the older modules are archived and tracked by the system, rather than being overwritten and obliterated. Each software module calling a routine in a DLL specifies not only the DLL name, but the version number with which it was tested. In this way, an application which depends on a particular behavior of a specific version of a DLL will get the behavior it desires. Obviously, this is a major change to the way DLLs are managed and would require significant changes at the operating system level to the way DLLs are used, but it does offer us the hope that our software will run – today, tomorrow, and in the future.

If you examine the typical Microsoft installation routine, you will see that it installs not only the application it is supposed to, but also the latest DLLs with which this software was developed. While fine in theory, the effect can be devastating. Software installed on the machine years ago may suddenly cease working, or worse, crash the system with a loss of data.

No other vendor is in the position of Microsoft to ship entire updates to the operating system with each new game, utility, development package they ship. Keeping up in a game with such lop-sided rules is difficult at best.

This is a situation that cannot be allowed to go on.

“Hey, we’re not talking rocket science here,” my coworker argues.

Rocket Science? Just what is this rocket science stuff anyways? Rocket science consists of mixing volatile stuff together, explosives, and squirting the resulting exhaust out the back, using the thrust to hopefully get where you want to go. Rocket science consists of Newtonian mechanics:

s = vᵢt + ½at²

This is algebra. Big deal. s, the distance traveled, is the sum of two elements: the product of initial velocity and time, and one half the product of acceleration times time squared. This is rocket science?

Okay, it gets trickier in two and three dimensions, when you factor in angular velocity, gravitational attraction, wind shear and the rest. But it’s just math! A little trig, a little computation, maybe a differential equation if it gets really messy. If you’re dealing with large masses or speeds that are a significant fraction of the speed of light, then you might need to throw in Einstein’s mass defect calculations as well, to keep precision, but, hey! This is just numbers.

The numbers get hard to work on a hand calculator, sure. That’s what computers are for, after all. Did you think computers were invented for you to play Solitaire, chum? Guess again. Computers were invented to solve ballistic equations. Cannons, mortars, V-2 rockets. The fact that computers now wallow in big fat GUIs and let you waste your work day oogling at cheerleaders.com is just a by-product, and an unfortunate one, at that. Computers were made to blow things up, bigger things, bigger explosions. Looked at this way, computers are probably the single most destructive tool ever invented.

So that’s rocket science. Big deal. Numbers. Sheesh.

Now, application development, that’s real work. We don’t have stinking numbers to tell us what to do. Application development requires reading the client’s mind. Application Development means making complex decisions on balancing application functionality against budget, against political realities. Going on gut instinct to decide if a denormalization makes sense considering the distribution of queries against the net throughput of the network, the latency and seek time of the drive array, the likelihood of a cache hit. Application Development is hard.

“I said, this isn’t rocket science,” my impatient coworker repeats.

“Damn right it’s not” I say.

It’s not just an address. It is the most succinct statement of Microsoft philosophy ever written.

Microsoft always plays the “Me, too!” card. No major vendor can announce a new technology without Microsoft counter-announcing “we’re on it.” “We have a better solution – more flexible, more reliable, and not just a fluke – it’s all part of our grand umbrella strategy of Windows at Work/WOSA/DNA/COM+ (fill in your favorite acronym)” Windows, after all, was a response to Xerox’ success with the GEM graphical user interface and the success of the Macintosh platform. The tabbed interface and nearly all other inventions were not created in the labs in Microsoft, but appropriated from other vendors.

Embrace. Enhance. Extend. Extinguish.

Embrace

is good. Supporting standards are a way of ensuring that our products play together well.

Enhance and Extend

can be good, sometimes. Introducing new innovations into an existing standard is necessary to keep the industry from stagnating. Change is inevitable and rapid on our industry, and pushing new technologies forward is a necessary part of the process. But pushing proprietary extensions, while competitively driven, splinters emerging technologies into different camps. An apochrophal story has made the rounds for years that a certain operating system was built with the motto, “It doesn’t ship until Lotus breaks.” Surely that is an exaggeration, but it does identify an attitude I suspect is all too common.

Extinguish

is usually bad. The race goes to the swift. Darwin tells us the fittest survive. But we have come to recognize, at least in some fields of endeavor, that endangers and threatened species are necessary for the biodiversity needed for all life to survive

I made the mistake years ago of choosing a computer platform based on the technological superiority of the machine, rather than on the popularity. After investing years of effort in learning and teaching and writing about the machine, it came to the end of its all too short lifetime. My investment was not recovered. My business was forced to close. I had to get a real job.

Upgrades for the sake of upgrades. It’s not a new f [Note: the remainder of this essay appears to have been lost. I’m trying to find a backup.]

The Answers Are Out There (23-May-1999)

Until recently, I was a Microsoft “Most Valuable Professional” for the free time I spent on CompuServe answering questions. In addition, I have co-authored the “Advisor Answers” column (formerly “Ask Advisor”) for the past four and a half years. I have stepped down from both of those positions. I am tired of answering questions.

The answers are out there.

Visual FoxPro is a complex language, with a long history, excellent backward-compatibility, and extraordinary capabilities. It is flexible, convoluted and exasperating all at the same time. But one advantage of Visual FoxPro over many other languages is its longevity; it has been around forever.