Ending the DLL Hell myth......

[Jim Hubbard]

I am reposting a portion of a thread that I am involved in under a new topic
because it seems that there are still people that believe the whole "DLL
Hell" myth.

I hope I can shed some light on this deception for some.....

Updates to .NET have distinct version numbers (already 1.0 vs. 1.1) and
software is tied to a specific one; you can have both installed on the
same
machine. Ending "DLL Hell" was a specific goal of .NET.

I'd like to speak directly to the issue of "DLL Hell".

"DLL Hell" was only an issue for the developers that followed incorrect,
outdated programming practices advocated by Microsoft. Microsoft had long
promoted the use of "shared DLLs". This practice started when hard disk
space was a big expense as a way to maximize the investment in hardware and
to get more use out of limited hard disk space.

Had Microsoft told developers that the simple way to eliminate this "DLL
Hell" was simply to place the DLLs needed by their applications in the same
directory as their executables (and make sure the working directory is the
same as the exe directory), the whole "DLL Hell" myth would have died a
quick and painless death.

Instead, we get handed the "DLL Hell" mis-information as one reason an
ENTIRELY NEW LANGUAGE is needed.

This was outright deception on the part of Microsoft and the ignorance of
supposed expert programmers that wrote many deceiving articles about the
supposed tragedy of something that only existed in software shops that did
not understand how a win32 executables actually worked.

Now, we have a real problem that reallocation of the program resources (i.e.
..Net framework) cannot as easily fix. It's "Fix Hell" and it's real.

With "Fix Hell", Microsoft issues a "fix" for a problem with .Net (only if
you spend 20 to 30 minutes per fix to call them and request the "fix").
"Fixes" are small patches that change the behavior of the .Net framework or
IDE on which the Microsoft "fix" is installed.

If you install the "fix" your .Net framework is no longer the same as your
potential market. In other words, it won't work for others that have not
downloaded the "fix".

If a user installs a "fix" (via a call to Microsoft, another developer's
setup or on his/her own) that "fix" may break your programs that rely on the
same .Net framework version but were designed without the "fix".

If you install the "fix" on another's PC, you may break the functionality of
other vendor's applications that use the same version of .Net that your app
uses and for which the "fix" was applied.

With Thinstall, the "Fix Hell" goes away. Your Thinstall executable
contains all of the .Net framework (with or without fixes) that your
application needs, and no "fixes" installed on the users' PCs will alter the
performance of your Thinstall application.

To put it bluntly......Thinstall is the only way to mass-market software in
the .Net platform and be 100% sure that a "fix" will not screw up your
application and increase your customer service calls.

Please read the blog at
http://weblogs.asp.net/fbouma/archive/2004/03/13/89021.aspx for another
(albeit older) view on this "fix" situation.

Jim Hubbard

 

[Guest]

I hope I can shed some light on this deception for some.....<snip>

Well, your understanding of DLL Hell is largely misinformed. DLL Hell really
affected COM components (dll, ocx, or otherwise) more seriously than standard
Win16/32 dll's. COM dll's- as you must know- aren't just regular Win16/32
dll's. Everyone knows that you can 1) install a standard dll "side-by-side"
since forever or even better 2) embed (statically compile) it into your exe's
(C++ only). Unfortunately, because of the "registration" architecture that
COM was based on, this was impossible with COM components. It wasn't a
"practice" followed by developers as you state because of "encouragement"
from Microsoft. It is just the way COM worked. There was no good way around
it.

<snip> promoted the use of "shared DLLs". This practice started when hard disk
space was a big expense<snip>

Again, mostly wrong. The "shared dll" paradigm (both COM and standard) was
inacted more so because of RAM contraints than disk space. When windows loads
a dll, it only loads the binary image (executable code) ONCE (yes, even on NT
based OS's) and the image simply gets *mapped* (NOT copied... see my P.S.
below) into processes that also try to load the same dll. What they do NOT
share, of course, is the storage space used for variables (stack, heap,
whatever). If the dll is in two locations on the hard drive, two images are
loaded into RAM. This is also true for COM dll's and .NET dll's too. I mean,
why don't all singular .NET apps just get their own side-by-side version of
the entire framework? A 100gb hard drive could very easily handle it.... but
512mb's of RAM certainly cannot.

P.S. Just FYI: Yes, even on NT/2K/XP Windows only *maps* dll's to a
process's address space. But, when a program tries to write to a part of its
address space where a dll executable image is currently mapped to (which a
C++ app easily can do with just a misused pointer) Windows steps in and
*copies* the formerly *just mapped* page into the process's address space and
lets it do it. I don't think Win9x is able to do this.

 

[Joe]

Unfortunately, because of the "registration" architecture that
COM was based on, this was impossible with COM components

What's very puzzling, is why didn't Microsoft foresee this issue, and
simply do for COM servers what was already working with standard DLLs,
ie. when told to load path-free components, start by looking in the
EXE's directory for components, and look elsewhere only if the
component can't be found there. Then, DLL Hell would have been a much
smaller issue.

It's even more mysterious that MS didn't follow through, and provide a
way to allow different versions of a component to co-exist both on the
HD and in RAM. Why didn't they think of the very real possibility that
a newly-installed application would break a bunch of other apps simply
by replacing a component with an older version?

Is there a technical reason why they chose to first start looking in
the Registry, and without providing some form of versioning?

Thx
Joe.

 

[Guest]

Think about where COM evolved from and what the original purposes were.... it
evolved from OLE and its first and primary purpose was AUTOMATION of entire
applications. The cleanest, fastest, and easiest way to "discover" the object
model and type library of an application is to look it up in the registry.
You can't very well install Microsoft Excel side-by-side with every program
that might want to automate it. Think about this: why do you think .NET does
NOT support Automation Servers?... I mean, you can't make a .NET EXE expose
an automation interface the way ActiveX EXE servers can. You can only mimic
it via Remoting, which is a much more complicated and less than robust
solution (for instance Active X EXE servers do not need to be running when
they are called.... the OS will look them up in the registry and load them on
demand... on the other hand there's no middle-man to do this in .NET
Remoting).

I don't think MS had some evil plan to make DLL Hell or that they were
shortsighted. In fact, the COM / resgistry paradigm was very robust and made
a whole lot of sense at the time. When it was developed most machines were
working with 4mb of RAM (!!!), 200mb of HD space, and HD's were slow as hell.
Having to "discover" an object model by reading a type library (tlb) or
dissect an executable (exe,dll) for the information would have been a let
more expensive than looking it up in a fast-performance central "database"
(the registry).

 

[Andre Kaufmann]

[...]

I don't think MS had some evil plan to make DLL Hell or that they were
shortsighted. In fact, the COM / resgistry paradigm was very robust and made
a whole lot of sense at the time. When it was developed most machines were
working with 4mb of RAM (!!!), 200mb of HD space, and HD's were slow as hell.
Having to "discover" an object model by reading a type library (tlb) or
dissect an executable (exe,dll) for the information would have been a let
more expensive than looking it up in a fast-performance central "database"
(the registry).

That´s so far correct, but i don´t understand why there must be a
dedicated path to the dll in the registry, which holds the component.
Just the dll name without path information would do the trick. Either
the dll is found in the local directory or in the system directory.
Additionally the local path could be added to a sub registry key,
for installation / deinstallation purposes.

But by specifying a direct dll path, i had no chance (before WinXP)
to register and use 2 versions of the same dll.

Fortunately WinXP has a solution to prevent all this trouble,
side by side installation, by using manifest files.

VS 2005 supports this directly, from inside the IDE.

:


[...]

Andre

 

[Joe]

Fortunately WinXP has a solution to prevent all this trouble,
side by side installation, by using manifest files.

I've never tried it, but W2K also introduced a trick, where if a
zero-byte filename that matches an OCX but the extension .local was
present in the local directory, that one would be used by the EXE
instead of the one that is registered. As to why no one @ MS thought
about this issue before...

Joe.

 

[Guest]

The full path thing does makes sense... your proposal does not.... because
the Registry also describes the objects full interface (classes). It should
be assummed that DLL 1.0 in one location doesn't have exactly the same
classes and methods as DLL 1.1 in a different location... hence the 1:1
relationship between a DLL's registration and its binary implementation.

I just read an article that described Reg-Free COM in VS 2005 (the object is
described in totality via manifest file). I wish MS had though of this
before.

[...]

I don't think MS had some evil plan to make DLL Hell or that they were
shortsighted. In fact, the COM / resgistry paradigm was very robust and made
a whole lot of sense at the time. When it was developed most machines were
working with 4mb of RAM (!!!), 200mb of HD space, and HD's were slow as hell.
Having to "discover" an object model by reading a type library (tlb) or
dissect an executable (exe,dll) for the information would have been a let
more expensive than looking it up in a fast-performance central "database"
(the registry).

That´s so far correct, but i don´t understand why there must be a
dedicated path to the dll in the registry, which holds the component.
Just the dll name without path information would do the trick. Either
the dll is found in the local directory or in the system directory.
Additionally the local path could be added to a sub registry key,
for installation / deinstallation purposes.

But by specifying a direct dll path, i had no chance (before WinXP)
to register and use 2 versions of the same dll.

Fortunately WinXP has a solution to prevent all this trouble,
side by side installation, by using manifest files.

VS 2005 supports this directly, from inside the IDE.

:


[...]

Andre

 

[Andre Kaufmann]

The full path thing does makes sense... your proposal does not.... because
the Registry also describes the objects full interface (classes). It should
be assummed that DLL 1.0 in one location doesn't have exactly the same
classes and methods as DLL 1.1 in a different location... hence the 1:1
relationship between a DLL's registration and its binary implementation.

The registry just links the class name with another registy entry
linking to a specific dll, which effectively is causing the dll hell,
since another registration of the same dll at another location will
overwrite the dll entry and the registry entry will be removed if
one of the dll´s installed will be deregistered.

So if you have a class registered:

class [CLSID {FC220AD8-A92A-4EE8-(26E-0B7AD152A020}]

and the corresponding entry:

clsid {FC220AD8-A92A-4EE8-(26E-0B7AD152A020}

[InprocServer = d:\mydll\location\mydll.dll]

you are only able to register a single dll. I don´t see why this should
make more sense than holding all installation locations ?

E.g.:

clsid {FC220AD8-A92A-4EE8-(26E-0B7AD152A020}

[Dll = mydll.dll]
[InprocServerLoc1 = d:\mydll\location\mydll.dll]
[InprocServerLoc2 = e:\location2\mydll.dll]


This would at least prevent the second dll to be deinstall too, when the
first one is deinstalled.
And all i´ve stated is that it´s better for the application to search
for the dll in the local path first. E.g.: searching for mydll.dll
instead of using a single registered full path, which refers to another
dll which has been installed to a different path !?

My proposal shouldn´t be a solution for the versioning problem, which is
a principal problem of shared dll´s.
But at least my proposal would solve 2 problems:

a) Use the dll shipped with the application and not the registered one
b) Doesn´t deinstall another dll, when the local one is deinstalled,
and the other one has been installed after the local one


My proposal was only a theoretical one, since practically it can´t be
simply added to an existing Windows installation.

For WinXP there´s a better solution, which allows me tie each COM class
to a single (local) dll. The best of this solution is, that i don´t
have to register the com dll anymore.

I just read an article that described Reg-Free COM in VS 2005 (the object is
described in totality via manifest file). I wish MS had though of this
before.

This is what i referred to as "side by side" installation and i use this
already extensively and which is a feature of WinXP only.
Though VC 2005 will make my life much easier, since i don´t have to
write the manifest files manually.

[...]

Andre

 

[Andre Kaufmann]

I've never tried it, but W2K also introduced a trick, where if a
zero-byte filename that matches an OCX but the extension .local was
present in the local directory, that one would be used by the EXE
instead of the one that is registered. As to why no one @ MS thought
about this issue before...

Joe.

Thanx for the info. Didn´t know that ;-). This was perhaps the first try
to solve the dll hell and the manifest solution in WinXP works similiar.

Andre

 

[Guest]

I see your point. But I don't think it would work well for COM EXE's.... and
as I said in an earlier post, COM EXE's (Automation Servers) were really the
main point ealier on. DLL's and OCX's became more important later. But, the
"architecture" had already been set in stone so to speak at that point.

The WinXP manifest (Reg-free) paradigm is so elegant... I can't believe MS
didn't think of it before.

The full path thing does makes sense... your proposal does not.... because
the Registry also describes the objects full interface (classes). It should
be assummed that DLL 1.0 in one location doesn't have exactly the same
classes and methods as DLL 1.1 in a different location... hence the 1:1
relationship between a DLL's registration and its binary implementation.

The registry just links the class name with another registy entry
linking to a specific dll, which effectively is causing the dll hell,
since another registration of the same dll at another location will
overwrite the dll entry and the registry entry will be removed if
one of the dll´s installed will be deregistered.

So if you have a class registered:

class [CLSID {FC220AD8-A92A-4EE8-(26E-0B7AD152A020}]

and the corresponding entry:

clsid {FC220AD8-A92A-4EE8-(26E-0B7AD152A020}

[InprocServer = d:\mydll\location\mydll.dll]

you are only able to register a single dll. I don´t see why this should
make more sense than holding all installation locations ?

E.g.:

clsid {FC220AD8-A92A-4EE8-(26E-0B7AD152A020}

[Dll = mydll.dll]
[InprocServerLoc1 = d:\mydll\location\mydll.dll]
[InprocServerLoc2 = e:\location2\mydll.dll]


This would at least prevent the second dll to be deinstall too, when the
first one is deinstalled.
And all i´ve stated is that it´s better for the application to search
for the dll in the local path first. E.g.: searching for mydll.dll
instead of using a single registered full path, which refers to another
dll which has been installed to a different path !?

My proposal shouldn´t be a solution for the versioning problem, which is
a principal problem of shared dll´s.
But at least my proposal would solve 2 problems:

a) Use the dll shipped with the application and not the registered one
b) Doesn´t deinstall another dll, when the local one is deinstalled,
and the other one has been installed after the local one


My proposal was only a theoretical one, since practically it can´t be
simply added to an existing Windows installation.

For WinXP there´s a better solution, which allows me tie each COM class
to a single (local) dll. The best of this solution is, that i don´t
have to register the com dll anymore.

I just read an article that described Reg-Free COM in VS 2005 (the object is
described in totality via manifest file). I wish MS had though of this
before.

This is what i referred to as "side by side" installation and i use this
already extensively and which is a feature of WinXP only.
Though VC 2005 will make my life much easier, since i don´t have to
write the manifest files manually.

[...]

Andre

 

[Andre Kaufmann]

I see your point. But I don't think it would work well for COM EXE's.... and
as I said in an earlier post, COM EXE's (Automation Servers) were really the
main point ealier on. DLL's and OCX's became more important later. But, the
"architecture" had already been set in stone so to speak at that point.

Yes. The structures are already there and my proposal was only a
hypothetical one. How a minimal change could have prevented some COM
problems.

The WinXP manifest (Reg-free) paradigm is so elegant... I can't believe MS
didn't think of it before.

Yes *g*.
And the .NET solution is even better.

:


[...]

 

[Jim Hubbard]

Yes. The structures are already there and my proposal was only a
hypothetical one. How a minimal change could have prevented some COM
problems.



Yes *g*.
And the .NET solution is even better.

And linking would trump them both....too bad we don;t have it in .Net yet.

Jim Hubbard