Re: Side-by-side installation on Windows 98SE and Windows 2000
- From: MM <kylix_is@xxxxxxxxxxx>
- Date: Thu, 20 Nov 2008 21:06:33 +0000
On Thu, 20 Nov 2008 13:42:19 -0500, "Bob Riemersma" <nospam@xxxxxxx>
wrote:
"MM" <kylix_is@xxxxxxxxxxx> wrote in message
news:2r5bi41scpjn1slbgv6qfbqpqrk8ji29vv@xxxxxxxxxx
I am reading an article by Michiel de Bruijn from the June 2000:
edition of VB Programmer's Journal: "Reduce DLL Hell in Windows 2000"
Of specific interest: DLL/COM Redirection
I was surprised to find that this is also supported on Windows 98
Second Edition as well as on 2000. (A test program from the article
confirms this.) So I quickly created a test scenario on a second 98SE
PC known not to contain certain components, e.g. richtx32.ocx,
msflxgrd.ocx and several others.
:
In other words is SP6 more "aware" of the SxS feature on 98SE/2000?
Thanks.
MM
That is an *ancient* article and I am amazed it doesn't have flashing red
warning text around it.
This is a tough one to describe concisely because you can rapidly get lost
in pronoun soup (lots of references to "it" that can't be easily tracked to
antecedents).
I think what it basically comes down to is that DLL/COM Redirection should
only be used with COM component libraries that were designed to use it, and
VB6 cannot create them. The culprit here is probably the self registration
entrypoint logic that VB6 creates in components it compiles.
What most of the articles on this subject don't go into enough detail on is
precisely how such a library should be registered. Simply suggesting that
component paths should be relative may not be enough.
However assuming that is true would imply that by registering with a
relative path means linkage will occur by using the paths that the Windows
DLL Search algorithm explores at runtime. Windows would search these paths
until it finds the first occurence of the relative pathed library.
Dynamic-Link Library Search Order
http://msdn.microsoft.com/en-us/library/ms682586.aspx
The article linked above suggests that the "directory from which the
application loaded" is searched first whether SafeDllSearchMode is enabled
or not. So if you had registered a given library with a "flat" relative
name (the library filename itself, with no path at all in front of it) it
seems that a .local file should be entirely unnecessary. In other words if
registered with such a path (just the DLL/OCX filename) you automagically
have Redirection through DLL Search with no .local file required at all.
Since this makes no sense, I assume there is a bit more to the process: and
there is!
It is meant to get around hard coded DLL paths in the client application:
The Windows 2000 Approach to DLL Hell: Private DLLs
http://msdn.microsoft.com/en-us/library/ms811694.aspx#dlldanger1_topic3
Other issues immediately spring to mind. First, it is clear that the COM
library *must be* registered for any of this to work. Second, your VB6
program may well (I don't know when and where this occurs, i.e. under what
circumstances, but it does it my test cases) call the COM library's self
registration entrypoint if it finds the library and finds that it is not
already registered. Thirdly, the quote you gave tells the tale: a
VB6-created library's self-reg logic always registers the full path.
So it seems to me that using .local with a VB6 program invoking a
VB6-created COM library is a recipe for registry corruption! Removing your
program (and it's libraries in the app folder) leaves behind a broken COM
registration entry.
If you read what Microsoft has published on DLL/COM Redirection closely
you'll see it is *not* a substitute for registering COM libraries *at all*.
Instead it is meant to allow an application to use a private, different
version but binary-compatible occurrence of a COM library *that has already
been registered on the system* as the global system version of the library.
Another thought that occurs to me is that about the time that Windows
Installer was introduced COM registration was somewhat expanded to enhance
"serviceability" of COM components. That refers to installing, updating,
and removing such libraries cleanly. At the same time the use of
self-registration was deprecated, because very few existing COM libraries
had "smart enough" self-reg logic to accomodate the new serviceability
standards. VB6 is certainly too old to to create "proper" self-reg code.
This means you should really never use regsvr32.exe to register components
as part of installation (it just calls the self-reg/unreg entrypoints). See
the Remarks at:
SelfReg Table
http://msdn.microsoft.com/en-us/library/aa371608.aspx
... as well as many similar warnings by vendors of application packaging
tools (Wise, etc.) which echo the very same caveats.
The good news is that if you create an Installer MSI carefully, using:
Registry Tables Group
http://msdn.microsoft.com/en-us/library/aa371169(VS.85).aspx
... you have fine control over component registration, and this means you
*should* be able to register even a VB6 COM library using a relative path.
Many packagers that produce Installer packages provide support for this that
helps ease the pain. Some older script-based packagers like Inno Setup
*might* also do this, I wouldn't know. PDW most likely does not.
However the .local form of side by side versioning does nothing to eliminate
the need for component registration. It is also woefully obsolete, having
been supplanted in Windows XP by more advanced technology. It is still
supported for backward compatability but its use is discouraged.
If you really are trying to support Windows 98 it might be an option for
you. Indiscriminate use would appear to lead to registry corruption and
maybe the worst form of DLL Hell: broken component registration.
My conclusion: avoid it like the plague. it isn't meant for use by VB6
developers.
I'm sure others have opinions too. Hopefully some more hopeful information
as well.
A very detailed exposition, thanks.
MM
.
- References:
- Side-by-side installation on Windows 98SE and Windows 2000
- From: MM
- Re: Side-by-side installation on Windows 98SE and Windows 2000
- From: Bob Riemersma
- Side-by-side installation on Windows 98SE and Windows 2000
- Prev by Date: Re: app's designed icon not displayed in Start Menu
- Next by Date: Ryhmän sfnet.tiede.matematiikka virallinen kuvaus
- Previous by thread: Re: Side-by-side installation on Windows 98SE and Windows 2000
- Next by thread: Detecting a network drive.....
- Index(es):
Relevant Pages
|
