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.....
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:uL********************@giganews.com...
As for #1 - As we saw with SP6 for VB6, Microsoft is perfectly capable of
and willing to (not intentionally) send out service packs that break old
functionality. With Thinstall .Net applications, there is no danger of
that happening.
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/archiv.../13/89021.aspx for another
(albeit older) view on this "fix" situation.
Jim Hubbard 22  2225 
> 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.
"Jim Hubbard" wrote:
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.....
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:uL********************@giganews.com...
As for #1 - As we saw with SP6 for VB6, Microsoft is perfectly capable of
and willing to (not intentionally) send out service packs that break old
functionality. With Thinstall .Net applications, there is no danger of
that happening.
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/archiv.../13/89021.aspx for another
(albeit older) view on this "fix" situation.
Jim Hubbard
On Tue, 22 Mar 2005 02:03:08 -0800, CMM
<CM*@discussions.microsoft.com> wrote: 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.
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).
"Joe" wrote: On Tue, 22 Mar 2005 02:03:08 -0800, CMM
<CM*@discussions.microsoft.com> wrote: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.
CMM wrote: [...]
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.
"Joe" wrote:
[...]
Andre
On Fri, 25 Mar 2005 07:58:36 +0100, Andre Kaufmann
<an****************@t-online.de> wrote: 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.
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. :-)
"Andre Kaufmann" wrote: CMM wrote: [...]
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.
"Joe" wrote:
> [...]
Andre
CMM wrote: 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
Joe wrote: On Fri, 25 Mar 2005 07:58:36 +0100, Andre Kaufmann
<an****************@t-online.de> wrote:
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.
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
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.
"Andre Kaufmann" wrote: CMM wrote: 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
CMM wrote: 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.
"Andre Kaufmann" wrote:
[...]
"Andre Kaufmann" <an****************@t-online.de> wrote in message
news:OX****************@tk2msftngp13.phx.gbl... CMM wrote: 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.
And linking would trump them both....too bad we don;t have it in .Net yet.
Jim Hubbard
> 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.
"Jim Hubbard" wrote:
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.....
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:uL********************@giganews.com...
As for #1 - As we saw with SP6 for VB6, Microsoft is perfectly capable of
and willing to (not intentionally) send out service packs that break old
functionality. With Thinstall .Net applications, there is no danger of
that happening.
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/archiv.../13/89021.aspx for another
(albeit older) view on this "fix" situation.
Jim Hubbard
On Tue, 22 Mar 2005 02:03:08 -0800, CMM
<CM*@discussions.microsoft.com> wrote: 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.
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).
"Joe" wrote: On Tue, 22 Mar 2005 02:03:08 -0800, CMM
<CM*@discussions.microsoft.com> wrote: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.
CMM wrote: [...]
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.
"Joe" wrote:
[...]
Andre
On Fri, 25 Mar 2005 07:58:36 +0100, Andre Kaufmann
<an****************@t-online.de> wrote: 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.
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. :-)
"Andre Kaufmann" wrote: CMM wrote: [...]
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.
"Joe" wrote:
> [...]
Andre
CMM wrote: 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
Joe wrote: On Fri, 25 Mar 2005 07:58:36 +0100, Andre Kaufmann
<an****************@t-online.de> wrote:
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.
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
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.
"Andre Kaufmann" wrote: CMM wrote: 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
CMM wrote: 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.
"Andre Kaufmann" wrote:
[...]
"Andre Kaufmann" <an****************@t-online.de> wrote in message
news:OX****************@tk2msftngp13.phx.gbl... CMM wrote: 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.
And linking would trump them both....too bad we don;t have it in .Net yet.
Jim Hubbard This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Tony LaPaso |
last post by:
Hi all,
I'm not sure if this is an HTML issue or CSS issue but it's weird.
I've been working w/XML for 5+ years and it's always been true that you
can use a shorthand notation for an empty...
|
by: roman ziak |
last post by:
I just read couple articles on this group and it keeps amazing me how
the portability is used as strong argument for language cleanliness.
In my opinion, porting the program (so you just take the...
|
by: Max Sandman |
last post by:
This myth about the Designer only deleting empty event handlers when you
unassign them? Where did that start? I've just deleted two with code,
one accidentally, one on purpose. Is this fixed in...
|
by: GreatB |
last post by:
Bill Gates died in a car accident.
He found himself in Purgatory being sized up by God .
.. "Well, Bill, I'm really confused on this call. I'm
not sure whether to send you to Heaven or Hell....
|
by: Greg Smith |
last post by:
I am working on my first web app. What is the proper way to end the
application and close the aspx page?
Any help is greatly appreciated.
|
by: Ben R. |
last post by:
In an article I was reading
(http://www.ftponline.com/vsm/2005_06/magazine/columns/desktopdeveloper/),
I read the following:
"The ending condition of a VB.NET for loop is evaluated only once,...
|
by: Blair P. Houghton |
last post by:
I'm just learning Python, so bear with.
I was messing around with the webbrowser module and decided it was
pretty cool to have the browser open a URL from within a python script,
so I wrote a...
|
by: barry.edmund.wright |
last post by:
Hi All,
I want to build a Find Statement on the fly.
The code below starting with 'This Code Works! is fine but as I said I
want to build the
Me!cboSelect1 & "=" & rs(Me!cboSelect1)
portion of...
|
by: Umesh |
last post by:
I want to extract a string abc*xyz from a text file.
* indicates arbitrary no. of characters.
I'm only able to do it when the string has definite no. of characters
or the string length is...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: erikbower65 |
last post by:
Here's a concise step-by-step guide for manually installing IntelliJ IDEA:
1. Download: Visit the official JetBrains website and download the IntelliJ IDEA Community or Ultimate edition based on...
|
by: kcodez |
last post by:
As a H5 game development enthusiast, I recently wrote a very interesting little game - Toy Claw ((http://claw.kjeek.com/))。Here I will summarize and share the development experience here, and hope it...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Sept 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
|
by: lllomh |
last post by:
How does React native implement an English player?
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
| |
