Microsoft Incompatible Dependency Suite
Microsoft Incompatible Dependency SuiteI acknowledge that this page has become a Microsoft bash and defend page, but there are two real issues here: CompatibleSuiteUpgrade (dependable paths) and IncompatibleSuiteUpgrade (undependable paths). I propose that we leave the bashing to the government and create these topics. -- Wyatt Matthews
The MicrosoftIncompatibleDependencySuite is a bunch of pieces of Microsoft software that, in the interests of reusable components (or, if you subscribe more to the antitrust school of thought, market domination), depends on every other piece of Microsoft software out there. Many programmers have taken the easy way out and made their own software dependent on pieces of said suite (but thankfully not interdependent!)
Pieces of the suite include:
So is this an example of massive refactoring that we can mark ConsideredHarmful?
Refactoring would reduce mutual dependencies and tight coupling. Taken to its logical extreme, refactoring would result in a layered architecture, with container/containee components (HTML document, Word document, Excel spreadsheet, image display, etc.), layered above a set of transport components (HTTP, FTP, File I/O, etc.), all which are plugged together by a common component infrastructure (COM, CORBA, etc.).
The software you name above is pretty close to this ideal. Internet Explorer is built along exactly these lines. Word and other Office applications suffer from a long history dating from before document-oriented user-interfaces were the norm and before COM was developed. That history is still in evidence: many members of the office suite still use MDI interfaces, and Word's attempt at an SDI interface still has awkward traces of its MDI ancestry.
However, the overall utility of the OLE/ActiveX/whatever architecture has been an inspiration to other projects, including OpenDoc and, more recently, KDE and Gnome. Gnome in particular explicitly acknowledges COM as an inspiration for much of the design of it's Bonobo component architecture.
COM as an inspiration for Bonobo is not right. The Gnome equivalent to COM is CORBA, and Bonobo is actually at the same level as OLE (which is on top of COM). -- PierrePhaneuf
CORBA does not provide exactly the same things as COM. CORBA comes from a distributed systems background while COM comes from a desktop background and it therefore provides a different set of features on which to build a ComponentFramework.
Bonobo was indeed influenced by COM, but I would say rather indirectly. They were rather interested in the OLE-style, more end-user components (though not necessary end-user), like embedding a spreadsheet in a word processor document. This kind of stuff is way over COM's head. So yes, you see COM inspiration in Bonobo, but it's a result of needing this to support the OLE-style architecture (bridging the gaps between COM and CORBA). -- PierrePhaneuf
Is JohnWalker, of AutoDesk fame, yet another one of your so-called incompetents? Because he couldn't even keep his Hacker's Diet Excel spreadsheet running from release to release because Microsoft kept making incompatible changes. This type of this explodes when you start making multiple dependencies to different parts of the aforementioned suite.
JohnWalker was using Excel to create software (just like MicroSoft wants us all to do), not just a bunch of numbers. The Eat Watch tools were actually quite advanced. Unfortunately, he had to rewrite them each time because MicroSoft decided it was best to make each version incompatible without introducing some kind of versioning facility. This is not to say that deprecating components is bad, but when you pretend there's no problem, well...
This kind of thinking is what causes the MicrosoftIncompatibleDependencySuite. It's massive integration on many levels and the standard response to problems that crop up is "upgrade".
I used to be a coder on MicroSoft platforms myself. I liked this thing and that thing about it. But I quit, primarily because I did have a choice, and the dependency game was really getting to me. I used BorlandDelphi instead of VisualBasic, to start; but even that wasn't the ideal solution.
The incompatible dependency suite problem's most visible purveyor is MicroSoft, but it is a real software problem, and it shows every time a company has to put out an update because a newer version of the member of the dependency suite breaks their older code, or perhaps even breaks other members of the suite. It happens.
I'm trying to point out a problem with a mindset. I know more people can identify with it if I point out the company that is most prominent in that mindset.
Both Unix and Windows have problems maintaining dependencies between DLLs in the face of change. This is not an operating-system specific issue, but is a problem with current software architectures that has still to be solved on any system. Windows tries to solve it by storing dependency information in the registry, but does not always get it right in my experience. Unix doesn't do it at all in any standard manner, but a number of proprietary package systems have been developed by individual Unix vendors over the years to address the issue. The most widely used on Linux are RPM and .deb packages.
This is a hard problem. Research is continuing in this area, both in industry and in academia. I think that the Internet will help a great deal, in that package systems will be able to automatically upgrade packages when they detect mismatches, without naive users having to know about the underlying mechanisms. This is the basis for the Eazel and Helix Code businesses in the Gnome/Linux space, and is also one of the ideas behind Microsoft's .NET. (Despite all the posturing and political idealism, there is actually very little technical difference between Microsoft and the OpenSource community when it comes to services for naive users).
-- NatPryce (I've signed it this time!)
Is this problem really that hard? I really don't know. In the good old times, running OS/2, I have never encountered the DLL hell problem. Perhaps one reason is that there is clear separation between what is the OS and what is the application. The 'System' comes from IBM and is patched with fixpaks from IBM, no application is supposed to change anything on the system. Any non-system DLLs used by the application should come with the application, and stay in the application's directory. And also, in the VisualAge C++ for OS/2 manual, there is a section telling you how to rename and repackage their runtime DLLs with your application, so that different applications using different versions of VAC++ will not have their DLLs clash. In fact, that is required by the license of VAC++ for distributing the runtime DLLs with your application. This practice has been criticized as inefficient, because it prevents sharing of the runtime DLLs between applications thus using up more disk space and memory, but it also prevents the DLL hell! The only application that updates the system is Lotus SS, after IBM bought the company, and that caused a section of it to appear in all OS fixpaks that comes after it. Contrast this with the usual practice of many Windows program coming with their own VBRUN and overwriting each other, I think using a bit more space is a wise choice. -- OliverChung
I worry that behind-the-scenes updating is going to yield more of the incompatibility phenomenon. If a company like MicroSoft with its huge resources can't keep track of versioning issues enough to keep dependencies working between updates, how can we expect others to do it?
In the Windows world, we have been pretty upset at what we all call the DLL Hell problem. Fornately, Microsoft has finally fixed the problem in Windows 2000 with total file protection for System DLLs. You cannot overwrite system DLLs in the system directory and the system will recover and restore one if you somehow do.
Let me see if I understand this. Originally in plain DLLs, the problem was the loader required all DLL functions known to the compiler (not just the called functions) to be available at run time. Software recompiled with the new version, but not using any new functions, would fail if it was run in the original environment. To fix this, Microsoft did not address the DLL loader, but came out with COM. In COM, however, when Microsoft releases a new version of a COM module, it renames the existing interfaces and gives the new interface a previously existing name (in disregard of their own development guidelines). For the developer, the end result is still the same. A version recompiled in an updated environment will not run in the original environment. Now you tell us the answer is to drop COM and DLLs and have our clients throw away their existing machines and Microsoft.NET will fix all our woes. I have yet to hear anyone from Microsoft answer how .NET will solve backward compatibility any better than before. This is not a "versioning" problem, it is a compatibility problem. -- WayneMack
I think that the greatest success in re-usable components has been the *nix PipesAndFilters mechanism. Perhaps not in terms of "market capitalization", but certainly in being a mechanism that allows people to casually combine programs in ways unforeseen by the original author of the program. Any Component model that requires a more complicated API than write(2) is evil ;-) (Yes, that means that I consider CORBA/KOM/Bonobo evil, too.)
The best "component" model is probably what you can do with Morphic in Squeak: a Morphic object is just an object that knows how to display itself. Since there are no artificial boundaries between "applications" in Squeak, that's enough.
Unix PipesAndFilters have not kept pace with changes in user-interface technology. I can easily combine filters on the command line, because all they do is read/write text. But interactive, graphical components do not have such a simple mode of operation, and can not so easily be combined.
Yes they can... in Squeak. SH
I don't know much about Squeak, but your description of a Morphic object above says that Morphic objects only know how to display themselves. A component in a desktop system needs to do a lot more than that. It needs to, at the very least, be able to save itself as part of the document that contains it. It also needs to transfer its data via cut/copy/paste and drag-and-drop, and to negotiate the format in which it transfers data to other applications. It also need to be scriptable from a variety of other languages.
Most importantly, the protocols (AbstractInteractions) by which components interact to achieve these ends need to be well-defined and standardized so that components can be written by different organizations, sold separately and combined by the end user with out any programming. Without those well-defined protocols, a component architecture does not exist.
A Morhic object knows how to display itself. Like any Smalltalk object, it can be cloned. All Morphic objects (i.e. every object in the Squeak interface) can be copied, moved, rotated, inspected, etc.. It is automatically persistent because the whole Squeak session can be saved in an image file. It doesn't have to negotiate a "format": it is just an object, it has the sole responsibility for its own representation. There are no "applications" per se in Squeak, so we don't have to do anything difficult to transcend application borders. By removing the borders between applications, we make the things "component models" achieve with great difficulty, almost trivially easy. The question is solved by removal of the unnessary. -- StephanHouben
As you describe it, Squeak hasn't removed the unnecessary. It has ignored the fact that programs must interoperate in a networked environment containing a heterogeneous mix of hardware, operating systems and programming languages. There are boundaries between applications, even if those applications present an object-centric interface to the user. Squeak doesn't make a language-neutral ComponentFramework unnecessary, it just ignores the need for one and doesn't solve any of the problems that such a framework addresses.
For example, you save a document from a Squeak word processor by dumping the image of the Squeak VM. How can I load that document into a word processor written in C++? If an object is responsible for its own representation and doesn't negotiate data formats, how can I copy-and-paste or drag-and-drop that object into a foreign application? If there are no standard data formats (such as CAB or Bento), how can a Squeak save a document to be sent to someone else who uses a non-Squeak system?
Wouldn't the obvious solution be to write a serializer that dumps to the particular file format you want?
Yes. You'd need to encapsulate different serializers behind an abstract serialization interface. This is exactly what OLE does. For copy-and-paste and drag-and-drop you also need to determine which formats are understood by the destination and which can be provided by the source and select the best one. This is exactly what the OLE drag-and-drop interfaces are for. Unsurprisingly, it looks like Squeak does need more than the Morphic class to support document components.
There is NO subsitute for in-competence. And I maintain that ANYONE who can not set up a development environment on a Windows machine including whatever tools you want and MicrosoftOffice and MicrosoftInternetExplorer should be fired on the spot.
Let me use my apparent incompetence in setting up Microsoft development environments as an example. I was unable to set up a Visual Studio 6 development environment the compile and reproduce code developed under a Visual Studio 5 environment. Pesky little problems with ATL library changes and ADO and other DLL changes. Seems ADO renames its interfaces under newer versions making recompiled code inoperable in the previous run time environment. At the end of the Visual Studio 5 phase of our project, we lost one development station because some one added a VB source code analysis tool. It upgraded DLLs and we could no longer build code compatable with the target environment. Due to these issues, I have strongly advised my development team not to install any of the free Visual Studio .NET beta CDs they have received. Perhaps someone can explain to this incompetent how to target earlier version of the OS/DLLs from a newer version of Visual Studio? -- WayneMack
I have never seen this problem. We took hundreds of thousands of lines of existing code on Visual Studio 5 and just compiled under Visual Studio 6. There were *no* changes.
I'm glad you were so lucky, but "DLL Hell" is a well known problem. Even Microsoft admits it is a problem (they just choose to keep perpetuating it for some reason).
Under Visual Sutdio 6, a new version of ADO is installed. In the new version, the Open command of the connection object has an additional parameter. To compensate for this change, we had to recode one line, but also had to install the latest MDAC on our target platforms for upgrade. We're lucky we only had 11 geographically separate sites to support.
Our latest brush with the MicrosoftIncompatibleDependencySuite came when we release a patch to a VB program. It seems the build machine had been upgraded to Internet Explorer 5.5. This installed a new version of scrrun.dll. We added the newly built executable to our install set and began shipping. About a week later, we started getting bug reports that a basic function that reads and writes text to/from a file was broken. We had to create a patch to our patch and update our install utility to include the latest version of scrrun.dll. How am I to be able to keep control over my development environment, when any and all applications installed can change it, and the changes are not backward compatible?
-- WayneMack
EditText of this page
(last edited July 18, 2006)
or FindPage with title or text search