Re: Internatinalization and multiple language support without resource DLLs
My problem wasn't so much the user of DLL's as it was noticing that the
problem is exacerbated by adding satellite language DLL's. I deal with it,
but I am annoyed by some of my project where there are 10 extra 5K DLLs for
languages for a DLL that has very minimal functionality. I would have
rather linked the code in and included the other RC file. I've also had
problems in the past where people have created MFC based DLLs incorrectly
and I've ended up with threads calling back into my main UI with a different
resource instance and it's kind of a nightmare to debug so I confess to
being a little sensitive. In perfect world, perhaps.
This whole new binding thing in the manifest has made matters even worse
since some people started using it and others didn't and we couldn't figure
out why our main application wouldn't start up and just gave a stupid
message "Failed to initialize" which meant nothing to anyone.
I also have one app that has to be a single EXE because it goes on every CD
we produce and has to be small and does not actually get installed. I know
that's a rare thing.
I wish MFC would use FindResourceEx() so we could have better resolution
over languages built into the application's EXE, alas...
Tom
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:05jko45rcomvghe36fh5d4lblels0lbd86@4ax.com...
I will admit that the whole .msi mechanism is prone to catastrophic
failures, largely due
to incompetent design (I've had long and painful discussions with people
over how .msi
fails). But we've found that overall it works incredibly well---it's just
that when it
fails, it does things like making installs impossible. Yes, a single .exe
works fine, if
all you need to deliver is a single .exe, and don't need to register
controls, install
DLLs because the project demands the use of DLLs (such as plug-ins), etc.
The problem I hear is that people don't want to use DLLs because they
don't want to use
DLLs. That is the argument I tend to be offended by. Why not use DLLs?
Well, DLLs
require that you can't copy a single .exe. Wow! THAT'S the most
convincing reason for
not using DLLs? Sorry, I need better reasons for disrupting a development
strategy to
accomodate the single .exe model.
I deliver a LOT of single-.exe products. But probably 1/3 of my
deliverables involve one
or more DLLs, and when DLLs are the right technical choice, I don't rule
them out just
because they are DLLs. No customer has ever complained if I deliver a
product with six
DLLs. Some customers *insist* on certain modularizations. The most
extreme case was a
customer that wanted every CDocument class and CView class in a separate
DLL, and I admit
that was a bit of a struggle. But with dynamically-constructed menus, we
were able to
deliver custom components over the next five years, until the controller
line itself was
retired (the program is still in use, but we aren't doing development on
it any longer).
The key here is that the decision to use or not use DLLs should be limited
to the
technical reasons; the XCOPY==install or copy==install issue should be
considered
irrelevant to the choice of optimum development strategy and optimum
technical choices.
joe