Re: Internatinalization and multiple language support without resource DLLs
Hi Colin,
Before Vista I've had a huge issue in testing with applications that, out of
necessity, had the languages all built into one EXE. Since the language was
not based on the thread instance any longer and since MFC doesn't support
getting resources using FindResourceEx() the only way to test was to host on
the actual system that had the proper language loaded in the OS. Vista made
that a lot easier with language packs, but on XP I think these were only
available to certain license types. External DLLs are easier to load and
user when possible in my opinion.
Before Win XP (win 2000) it was much easier to do single EXE apps, but then
it got difficult, and is not easy again (except that you have to count on
your application running on XP still. Maybe when Windows 7 catches on XP
will go the way of Win98 and Win2K and WinME and ...
Tom
"Colin Peters" <cpeters@coldmail.com> wrote in message
news:498a0064$1_6@news.bluewin.ch...
You can call it sloppiness, unprofesionality, herecy and blasphemy, but
you've just highlighted how it can happen. And there's not much you can do
to prevent it. Now, tell me how you could get version skew when the
resources are in the same executable as the code? (Note that I write
executable rather than exe; it'd be perfectly valid to have both contained
in a dll, like an ocx. The problem I'm trying to get across is that when
you split the code and dependent resources across separate files then the
potential for mismatch can't be removed. When they're contained in the
same file then it takes some serious effort to dislodge them. In which
case someone is trying to break your program rather than breaking it by
accident).