结束DLL地狱神话...... [英] Ending the DLL Hell myth......

问题描述

我正在重新发布一个我参与的新主题的部分内容

，因为似乎仍有人相信整个DLL

地狱神话。


我希望我可以为一些人揭开这种欺骗行为......


" Michael A. Covington" <螺** @ ai.uga.edu.for.address>在消息中写道

新闻：％2 *************** @ TK2MSFTNGP15.phx.gbl ...

Jim Hubbard <再*** @ groups.please>在消息中写道
新闻：uL ******************** @ giganews.com ...

As对于＃1 - 正如我们在VB6中看到的VB6一样，微软完全有能力（并非故意）发送破坏旧功能的服务包。使用Thinstall .Net应用程序，没有发生这种情况的危险。

.NET的更新具有不同的版本号（已经是1.0对1.1）和
软件与特定的软件相关联;你可以同时安装在
机器上。结束DLL Hell是.NET的一个特定目标。

我想直接谈谈DLL Hell的问题。


DLL Hell对于那些遵循微软倡导的错误的，过时的编程实践的开发人员而言，这只是一个问题。微软长期以来推广使用共享DLL。这种做法开始时，硬盘

空间是一项巨大的开支，以最大化硬件投资和

，以便在有限的硬盘空间中获得更多的使用。 />

如果微软告诉开发人员消除这个DLL

Hell的简单方法只是将其应用程序所需的DLL放在与其可执行文件相同的

目录中（并确保工作目录是与exe目录相同的

），整个DLL地狱神话会死于一个快速而无痛的死亡。


相反，我们得到的是DLL Hell。错误信息是一个原因

需要完整的新语言。


这是微软的彻头彻尾的欺骗和对
的无知
假设专家程序员编写了许多关于

假设的悲剧的故事，这些悲剧只存在于软件商店中，而且不知道win32可执行文件是如何工作的。


现在，我们有一个真正的问题，即重新分配程序资源（即
..Net框架）不能轻易修复。它是修复地狱这是真实的。


使用Fix Hell，Microsoft发出修复消息。对于.Net的问题（仅当你需要花费20到30分钟来调用它们并请求修复）时才会花费20到30分钟。

修复是小补丁，可以改变.Net框架或微软修复的行为。

IDE已安装。


如果您安装了修复您的.Net框架不再与您的

潜在市场相同。换句话说，对于没有下载修复的其他人来说，它不会起作用。


如果用户安装了修复 ; （通过致电微软，另一个开发者'

设置或他/她自己）修复可能会破坏您的程序，这些程序依赖于

相同的.Net框架版本，但设计时没有修复。


如果您安装修复 ;在另一台PC上，您可能会破坏其他供应商的应用程序的功能，这些应用程序使用与您的应用程序相同版本的.Net
使用的修复已经应用了。


使用Thinstall，Fix Hell消失了。您的Thinstall可执行文件

包含您的

应用程序所需的所有.Net框架（有或没有修复），并且没有修复安装在用户的PC上会改变你的Thinstall应用程序的性能。


直言不讳...... Thinstall是唯一的在.Net平台上大规模推广软件的方法，并且100％确定修复软件。不会搞砸你的

申请并增加你的客户服务电话。


请阅读
http://weblogs.asp.net/fbouma/archiv ... / 13 /89021.aspx 另一个

（虽然年龄较大）对此修复的观点情况。


Jim Hubbard

解决方案

>我希望我可以为某些人揭开这种欺骗行为.....< snip>


嗯，你对DLL地狱的理解很大程度上是错误的。 DLL地狱真的比实际受到影响的COM组件（dll，ocx或其他）比标准更严重

Win16 / 32 dll'。 COM dll' - 你必须知道 - 不仅仅是常规的Win16 / 32

dll'。每个人都知道你可以1）安装一个标准的dll并排

因为永远甚至更好2）将它嵌入（静态编译）到你的exe的'

（仅限C ++）。不幸的是，由于注册，作为COM基于的
架构，COM组件无法做到这一点。这不是一个b $ b的做法。由于微软的鼓励

，所以你所说的是开发人员。这就是COM的工作方式。

它没有好办法。

< snip>促进了共享DLL的使用。这种做法始于硬盘空间耗资巨大的时候< snip>


再次，大多是错误的。 共享dll是指共享dll。由于RAM的限制而不是磁盘空间，因此范式（COM和标准）都是因为内存较多而受到影响。当windows加载

a dll时，它只加载二进制图像（可执行代码）ONCE（是的，甚至在NT
基于
的操作系统上），图像只是得到*映射*（未复制...请参阅我的PS
下面的
）进入同样尝试加载相同dll的进程。他们所做的不是

共享，当然是用于变量的存储空间（堆栈，堆，

无论如何）。如果dll位于硬盘驱动器的两个位置，则两个图像将加载到RAM中。 COM dll'和.NET dll'也是如此。我的意思是，

为什么不是所有单一的.NET应用程序只是在整个框架中得到他们自己的并排版本的

？一个100GB的硬盘驱动器可以非常轻松地处理它......但是

512mb的内存当然不能。


P.S.仅供参考：是的，即使在NT / 2K / XP上，只有*将* dll'映射到

进程的地址空间。但是，当一个程序试图写入其当前映射到dll可执行映像的

地址空间的一部分时（这可以很容易地用于...一个误用的指针）Windows进入并且

*将以前*刚刚映射的*页面复制到进程的地址空间中，并且

允许它执行此操作。我不认为Win9x能够做到这一点。

" Jim Hubbard"写道：

我正在重新发布我在新主题下涉及的一部分线程
因为似乎仍然有人相信整个DLL
地狱"神话。

我希望我可以为一些人揭开这种欺骗行为......Michael A. Covington <螺** @ ai.uga.edu.for.address>在消息中写道
新闻：％2 *************** @ TK2MSFTNGP15.phx.gbl ...

吉姆哈伯德" <再*** @ groups.please>在消息中写道
新闻：uL ******************** @ giganews.com ...

As对于＃1 - 正如我们在VB6中看到的VB6一样，微软完全有能力（并非故意）发送破坏旧功能的服务包。使用Thinstall .Net应用程序，没有发生这种情况的危险。

.NET的更新具有不同的版本号（已经是1.0对1.1）和
软件与特定的软件相关联;你可以同时安装在
机器上。结束DLL Hell是.NET的一个特定目标。

我想直接谈谈DLL Hell的问题。

DLL Hell ;对于那些遵循微软倡导的不正确，过时的编程实践的开发人员来说，这只是一个问题。微软长期以来一直在推广使用共享DLL。这种做法始于硬盘空间是一项巨大的开支，以最大限度地增加硬件投资，并在有限的硬盘空间中获得更多的使用。

有微软告诉开发人员，消除这种DLL地狱的简单方法是只是将他们的应用程序所需的DLL放在与其可执行文件相同的目录中（并确保工作目录与exe目录相同），整个DLL Hell。神话会死于快速无痛的死亡。

相反，我们得到的是DLL Hell。错误的信息是需要一个完整的新语言的一个原因。
这是微软的彻头彻尾的欺骗和无知的专业程序员写了很多欺骗性的文章关于那些只存在于软件商店中的东西的悲剧，这些东西确实不能理解win32可执行文件是如何工作的。

现在，我们有一个真正的问题，即重新分配程序资源（即
..Net框架）不能轻易修复。它是修复地狱这是真实的。

使用Fix Hell，Microsoft发布了修复功能。对于.Net的问题（只有当你每次修复需要花费20到30分钟才能调用它们并请求修复时）。
修复是一些小补丁，可以改变.Net框架或微软修复的IDE的行为。已安装。

如果你安装了修复您的.Net框架不再与您的潜在市场相同。换句话说，对于没有下载修复的其他人来说，它不会起作用。

如果用户安装了修复按钮。 （通过致电Microsoft，另一个开发人员的设置或他/她自己）修复可能会破坏依赖于相同的.Net框架版本但没有修复的程序。

如果你安装了修复。在另一台PC上，您可能会破坏其他供应商的应用程序的功能，这些应用程序使用与您的应用程序使用的相同版本的.Net，并且修复该应用程序。应用了。

使用Thinstall，Fix Hell消失了。您的Thinstall可执行文件
包含您的
应用程序所需的所有.Net框架（有或没有修复），并且没有修复。安装在用户的PC上会改变你的Thinstall应用程序的性能。

直言不讳...... Thinstall是大众推广软件的唯一途径.Net平台并且100％确定修复平台。不会搞砸你的
申请并增加你的客户服务电话。

请阅读
http://weblogs.asp.net/fbouma/archiv.../13/89021.aspx 另一个
（虽然年纪较大）对此修复的看法情况。

Jim Hubbard

2005年3月22日星期二02:03:08 -0800，CMM

< CM*@discussions.microsoft.com>写道：

不幸的是，由于注册而COM基于的架构，COM组件是不可能的

什么是非常令人费解的，为什么微软没有预见到这个问题，和$ / b $ b只为COM服务器做了什么，已经使用标准DLL，

ie。当被告知加载无路径组件时，首先查看组件的

EXE'目录，并且只有在

组件不能的情况下才能查看其他地方发现那里。那么，DLL Hell本来就是一个很小的问题。


MS没有跟进并提供更加神秘的东西一种

方式允许不同版本的组件在

HD和RAM中共存。为什么他们没有想到新安装的应用程序通过用旧版本替换组件来破坏一堆其他应用程序的真正可能性？

？


是否有技术上的原因，他们选择首先开始在注册表中查看

，而不提供某种形式的版本控制？


Thx

Joe。

想想COM从哪里演变出来以及最初的目的是什么......它

是从OLE演变而来的，它的第一个主要目的是整个

应用程序的自动化。 发现最干净，最快速，最简单的方法对象

应用程序的模型和类型库是在注册表中查找的。

你不能很好地并行安装Microsoft Excel每个程序

可能想要自动化它。想想这个：为什么你认为.NET会支持
不支持自动化服务器？...我的意思是，你不能让.NET EXE公开

an自动化接口ActiveX EXE服务器的方式。你只能通过Remoting来模仿

，这是一个更复杂且不太强大的b $ b解决方案（例如，当
它们被调用....操作系统将在注册表中查找它们并加载它们

需求...另一方面，没有中间 - 在.NET中这样做的人

Remoting）。


我不认为MS有一些邪恶的计划来制造DLL地狱或他们是

短视。事实上，COM / resgistry范例非常强大，并且当时很有意义。

。当开发它的时候，大多数机器都是4美元的RAM（!!!），200万的高清空间和HD的速度很慢。

有发现发现一个对象模型通过读取一个类型库（tlb）或

解析一个可执行文件（exe，dll）来获取这些信息本来就比让它看起来更贵了。在一个快速表现的中央数据库

（注册表）。


" Joe"写道：

2005年3月22日星期二02:03:08 -0800，CMM
< CM*@discussions.microsoft.com>写道：

不幸的是，由于注册而COM基于的架构，COM组件是不可能的

什么是非常令人费解的，为什么微软没有预见到这个问题，并且 EXE的目录中的组件，然后只在那里找不到
组件时查看其他地方。那么，DLL地狱本来就是一个很小的问题。

MS没有跟进并提供一种允许的方式更加神秘不同版本的组件在高清和RAM中共存。为什么他们没有想到新安装的应用程序只是通过用旧版本替换组件来破坏其他应用程序的真正可能性？
是否有技术上的原因，他们选择首先开始查看注册表，而不提供某种形式的版本控制？

Thx
Joe。

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

解决方案

> 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.

这篇关于结束DLL地狱神话......的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！