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.ed u.for.address> wrote in message
news:%2******** *******@TK2MSFT NGP15.phx.gbl.. .
"Jim Hubbard" <re***@groups.p lease> wrote in message
news:uL******** ************@gi ganews.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......Th install 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  2272 
> 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 "registrati on" 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 "encouragem ent"
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.ed u.for.address> wrote in message
news:%2******** *******@TK2MSFT NGP15.phx.gbl.. .
"Jim Hubbard" <re***@groups.p lease> wrote in message
news:uL******** ************@gi ganews.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......Th install 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*@discussion s.microsoft.com > wrote: Unfortunatel y, because of the "registrati on" 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*@discussion s.microsoft.com > wrote:Unfortunatel y, because of the "registrati on" 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\locati on\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]
[InprocServerLoc 1 = d:\mydll\locati on\mydll.dll]
[InprocServerLoc 2 = e:\location2\my dll.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
"architectu re" 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\locati on\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]
[InprocServerLoc 1 = d:\mydll\locati on\mydll.dll]
[InprocServerLoc 2 = e:\location2\my dll.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 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 element like this:
"<fred/>" is the same as "<fred></fred>"
|
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 source code and
recompile) is a myth started 20-30 years ago when world consisted of
UNIX systems. Well, world does not consist of UNIX systems...
|
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 the 2003 version?
sandman
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
|
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. After
all, you enormously helped society by putting a
computer in almost every home in the world and yet you
created that ghastly Windows 95. I'm...
|
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, while the
C# for loop ending condition is evaluated on every iteration."
Is this accurate? I don't understand how you could get away without...
|
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 short script to open a local file the same way, using the
script file as an example target:
# browser-test.py
import webbrowser
import sys
|
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 the Find statement below on the fly:
rsTemp1.FindFirst Me!cboSelect1 & "=" & rs(Me!cboSelect1)
on the fly.
|
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 constant: i.e. five or the string is abc?????
xyz
How can i generalize it for any length of the string?
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...
| |
