Re: Static Dll vs Shared Dll
- From: "KMA" <KMA@xxxxxxxxxxxxxxxx>
- Date: Wed, 22 Jun 2005 08:17:24 +0200
>>> I am not aware of any program that does not have dependencies on Windows
DLLs
Neither am I, which is why I wrote:
"...that single exe programs with
no dependency on non-Windows dlls are somehow "old hat". "
By non-Windows I meant dlls that are not shipped with the OS. Surely you're
not suggesting tampering with OD dlls? My meaning was given the choice of
implementing as either exe + dll, or bigger exe with library code statically
linked, then I prefer the latter. And I also assert that for such a setup
copy==install. Or rather, "copy == run from anywhere without problem". And I
assert that there's absolutely nothing wrong with that.
A favourite utility of mine is Process Explorer (I'm sure you know it, from
sysinternals). I don't even have to unpack it permanently to use it, let
alone make an official install. I just unpack it from an archive as and when
I need it and run it. If I need to go to a problem machine, I just drop it
onto a CD or floppy take it to the machine and it works. Are all the Process
Explorer users just "lucky", or was the program designed to work like this?
I accept that this is an MFC newsgroup and that MFC42.dll is a
redistributable dll that could change and therefore theoretically should be
distributed new for each release. I also accept that "copy isn't always ==
install", but that wasn't my original claim. My claim was that it's possible
to build apps where copy==install and where this is possible this brings
benefits. I've given you a example of a non-trivial app where this works
reliably. Not an MFC app, I admit.
Thanks for your time.
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:jkegb118dej580cq0d9kou0t1vkj1s0se3@xxxxxxxxxx
> I am not aware of any program that does not have dependencies on Windows
DLLs. An MFC app
> with static linking uses something like a dozen DLLs outside the MFCxx.DLL
library, and
> many of these (such as OLE DLLs) are redistributable, and must be
redistributed.
>
> Any time you can simply copy the .exe and have it run means that you have
been lucky
> ("Feeling Lucky?"). It works by accident, not design. I've had a lot of
support problems
> from customers who having once done an install will do a copy of our app
to another
> machine (since in all cases this involves a piece of physical hardware,
there is no
> license violation), and it fails in some bizarre way. In most cases, they
have the correct
> version of MFC42.DLL installed, but the other libraries are out-of-sync.
This has nothing
> to do with good programming practice; it has to do with good product
distribution
> practice. There is nothing you can do as a programmer to deal with making
sure the correct
> redistributalbe DLLs are installed on the target machine, because you
cannot stop a static
> link of MFC from using them. And the static link of MFC still assumes a
certain level of
> DLL behavior for the other DLLs.
>
> I've spent too much time on the phone dealing with people who have thought
copy==install
> to believe it any longer. MFC42.DLL is rarely the problem, and in every
case, if they did
> an actual install instead of a copy (which installed all the other
redistributable DLLs),
> the problems went away. In most cases, it was OLE support DLLs that caused
the problems.
>
> So basically, I make no pretension of attempting to support copy==install.
You have no
> control over the selection of DLLs that would be included by a static
link, so you still
> need to make sure that the set required would be installed. In particular,
there have been
> some known serious bugs in the OLE support of Win9x and NT4.
>
> I do not build release packages. My clients do this, because each of them
has their own
> favorite installer package, and I'm not willing to shell out ~$800 each
for them. Note
> that the downloads I provide from my Web site presume that the latest
version of MFC is
> installed, but I provide the source so it can be rebuilt...I make no
promises that any
> executable will work, and when problems have been reported, I just send
the reply "rebuild
> it from the source", because freeware is just that, and I make no
pretensions of the code
> actually working. But I would never distribute a real product this way,
and if the
> download of the executable doesn't work, I don't support it.
> joe
> On Tue, 21 Jun 2005 07:56:48 +0200, "KMA" <KMA@xxxxxxxxxxxxxxxx> wrote:
>
> >> A belief that copy==install is obsolete, has been obsolete for 15
years,
> >and should not be
> >> used as justification for poor programming practice.
> >
> >Joe,
> >
> >I respect (and enjoy) about 99% of what you write, but I take issue with
the
> >above. I interpret what you've written to mean that single exe programs
with
> >no dependency on non-Windows dlls are somehow "old hat". Such a program
> >*can* be distributed simply by copying the exe and runing it, and I see
> >absolutely nothing wrong with that and plenty that's right. No dll
> >mismatches, no complicated registry keys, no messy uninstall (or rather
> >half-uninstall). To me that represents good programming practice. And the
> >cost is what? Larger exe? surely you're not campaigning on this point.
> >Inability to update a component DLL without reinstalling a new exe?
Please
> >explain.
> >
> >I look forward to an informative and entertaining reply. Unless I've
> >misinterpreted what you meant.
> >
> >
> >
> >
> >"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
> >news:8useb1h9ip0kmia4kjqjnaon1gsctrm2lf@xxxxxxxxxx
> >> There is no such thing as a "static DLL"; there is only a "static
link",
> >in which all the
> >> code is copied into your executable image.
> >>
> >> What link error do you get. All you've said is "my program doesn't
work,
> >what did I do
> >> wrong?", which isn't very much help in diagnosing your problem.
> >>
> >> As far as I have been able to tell in a decade of MFC programming is
that
> >static is never
> >> "better" than shared; I have not once delivered a statically-linked MFC
> >project. One
> >> client decided they wanted a static link, and theproblems they
experienced
> >were what I
> >> could have predicted.
> >>
> >> A belief that copy==install is obsolete, has been obsolete for 15
years,
> >and should not be
> >> used as justification for poor programming practice. Use an installer
> >program. As much as
> >> I despise InstallShield, it does come with VS, at least VS6.
> >> joe
> >>
> >> On Mon, 20 Jun 2005 11:39:28 +0100, "Simon" <spambucket@xxxxxxxxxxx>
> >wrote:
> >>
> >> >Hi,
> >> >
> >> >In the past I have always used Static link in the belief that whenever
I
> >> >created an exe I did not have to check that the user had anything
> >installed
> >> >on their computer, (any special dll that are on my machine but might
not
> >be
> >> >on anybody else).
> >> >
> >> >It made the exe itself a lot bigger but it never really was a problem
as
> >my
> >> >data files takes 99.9% of the size anyway.
> >> >
> >> >But now I created a new project, (for something totally different),
and I
> >> >get link errors when building statically, (but not when I link
shared).
> >> >I have 2 projects, one lib and the other is an exe, as usual I
selected
> >"Use
> >> >MFC in a static link".
> >> >
> >> >So, why is static better than shared? Is it really better? How can I
> >prevent
> >> >those link errors?
> >> >Ideally I don't want to have to worry about what is/is not installed
on
> >the
> >> >users machine.
> >> >What do I need to ship with my Shared Dll to get it to work on all
> >machines,
> >> >any possible licence problems?
> >> >
> >> >Simon
> >> >
> >>
> >> Joseph M. Newcomer [MVP]
> >> email: newcomer@xxxxxxxxxxxx
> >> Web: http://www.flounder.com
> >> MVP Tips: http://www.flounder.com/mvp_tips.htm
> >
>
> Joseph M. Newcomer [MVP]
> email: newcomer@xxxxxxxxxxxx
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- Static Dll vs Shared Dll
- From: Simon
- Re: Static Dll vs Shared Dll
- From: Joseph M . Newcomer
- Re: Static Dll vs Shared Dll
- From: KMA
- Re: Static Dll vs Shared Dll
- From: Joseph M . Newcomer
- Static Dll vs Shared Dll
- Prev by Date: Re: File Version without GetFileVersionInfo
- Next by Date: Re: Display Unicode In Richedit Conrol
- Previous by thread: Re: Static Dll vs Shared Dll
- Next by thread: Re: Static Dll vs Shared Dll
- Index(es):
Relevant Pages
|
