Re: Internationalization
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:s86dn3hci98ea9of5rbuvfasloaf72d2gc@4ax.com...
Actually, it was deeper than a feature set; there were actual bugs in the
OLE DLLs, for
example, one bug that caused a release failure, so the app was left
running even though it
shouldn't have been. Avoiding OLE is not an option if you are doing
something that
interfaces with it; I don't know of a way to do automation without using
the OLE DLLs;
once the decision is made to use that interface, the programmer has no
control of the
situation. So we have implicit trust in MS in this regard, that they have
tested their
DLLs and they all work. So why is the MFC DLL seen as an exception to
this trust?
Most Windows apps don't do automation. Even if they do, I don't believe
they have to redist OLE DLL's for modern Windows OS's anymore. Most Windows
apps redist only the msvcrt.dll and mfc dll. It's not an exception, that's
just all that is redistributed even with dynamic linking.
Some programs are special cases, but note that ProcExp.exe, for example,
uses
COMMCTL32.DLL (which has had multiple versions), version.dll,
COMMDLG32.dll (which has had
multiple versions, some incompatible with each other, do you remember the
File Open Dialog
crisis of a few years ago?), and OLE32.DLL. It uses no
sysinternals-supplied DLLs or
custom controls.
The fact that ProcExp.exe uses these DLL's but does not redist them (and in
fact Microsoft prohibits redist'ing commctl32.dll since IE 5) indicates it
is not necessary. And even if it did use SysInternals supplied DLL's, they
could or even in-proc COM controls, they could easily be copied to the same
folder and used from there without registration, with Reg free COM.
I create and distribute programs that use automation interfaces to
third-party controls
(required by customer specs), custom DLLs, client-supplied DLLs, and so
on, and copy just
wouldn't work for these situations. The problem is that people start
thinking
copy==install because they've seen the trivial cases, but get caught up
with the idea that
static linking is a Way Of Life; it isn't, it is just a minor perturbation
of the world
which often generates more problems than it solves. It is not a universal
solution, or
necessarily even a good solution, it is just A solution.
That may be true, but it is equally true that people see the needlessly
convoluted cases and think that is the way it has to be, when with a little
thought, they could save their companies and their end users a ton of
headaches.
-- David