Mixing non-Unicode MFC dll with an MFC _Unicode application
Jacquin Buchanan
I have a MFC application that I compile with _Unicode defined. This
works great and gives me the international support I want (at least on NT
platforms). I am linking with a third party DLL that uses MFC as well, but
was not compiled with the _Unicode switch. Everything links and copiles OK
but crashes in the third party DLL. If I remove the _Unicode from my
application and run it all works fine (except the unicode characters don't
display right). If I don't link with the third party DLL (and comment out
the calls) then everything works OK.
I have considered switching to using the the "Microsoft Layer for Unicode"
and the UnicoWS.dll This is supposed to provide better support for unicode
under 95/98/me.
Any ideas would be appriciated,
Jack
Michael (michka) Kaplan
getting them to recompile their binary for Unicode is the best answer.
MSLU does not provide better Unicode support -- it simply provides a Unicode
interface so that you write Unicode apps that will *run* on all platforms.
--
MichKa
Michael Kaplan
(principal developer of the MSLU)
Trigeminal Software, Inc. -- http://www.trigeminal.com/
the book -- http://www.i18nWithVB.com/
"Jacquin Buchanan" <Jacquin....@MarineAcoustics.com> wrote in message
news:eio9knqdBHA.1028@tkmsftngp04...
Jacquin Buchanan
Library I'd like to use to recompile their code for Unicode. This is not
very likely.
I am not looking for better support out of MSLU, though the same support on
more platforms does seem "better" by definition.
It seems my problem stems from not being able mix MFC versions. When you
specify the _unicode define the compiler links in MFC42U.dll instead of the
normal MFC42.dll. Since the application and the DLL are linked to different
versions of MFC you get a crash. You get similar problems, but not a crash,
when you mix the debug MFC with the non-debug MFC. For this reason most
third party developers ship both debug and non-debug versions of their Libs.
They unfortunately don't always ship a Unicode version.
I was hoping that when using MSLU you did not have to specify the _unicode
define. This would mean my application linked with the normal MFC42.dll and
got its Unicode support from the UnicoWS.dll.
It might be possible for me to statically link my application with MFC.
There are other problems this will cause but I may be able to overcome them
some other way. I didn't want to take a long road down either of these paths
unless I was pretty sure they would work in the end.
thanks,
Jack
"Michael (michka) Kaplan" <forme...@spamfree.trigeminal.nospam.com> wrote
in message news:uVIIpjrdBHA.568@tkmsftngp02...
Pete Delgado
"Jacquin Buchanan" <Jacquin....@MarineAcoustics.com> wrote in message
news:eio9knqdBHA.1028@tkmsftngp04...
You're having the same problems as you would if you were to use the "normal"
ANSI versions of the C run-time libraries with Unicode strings. Since the
MFC string class decides at compile time which versions of the CRT functions
to use based upon the preprocessor definitions of _UNICODE or _MBCS, what
you are essentially doing is masking the difference in the CString
underlying data with the CString class.
What you can do is simple, but can be costly in terms of performance &
system resources -you need to pass the multibyte equivelent of the Unicode
string to the third-party library so that the data is in the format that the
library expects. The easiest way to do this is to wrap the API of the
third-party in a set of classes that perform the conversion for you. You
can use several of the handy macros that are defined in Visual C++ in order
to minimize the amount of code that you'll have to write.
I don't think the MS layer for Unicode wouldn't help you since you have
alrady stated that the particular library that you need hasn't been compiled
to handle Unicode. Unless the library you are referring to is part of the
opeating system, I don't think it will help you. Of course, I've not used
MSLFU as I tend to write applications that target NT, 2000 and XP so take
this particular piece of advice with a grain of skepticism.
-Pete
Michael (michka) Kaplan
> I was hoping that when using MSLU you did not have to specify the _unicode
> define. This would mean my application linked with the normal MFC42.dll
and
> got its Unicode support from the UnicoWS.dll.
Sorry, MSLU still requires the UNICODE and _UNICODE defines.
Michael (michka) Kaplan
> I don't think the MS layer for Unicode wouldn't help you since you have
> alrady stated that the particular library that you need hasn't been
compiled
> to handle Unicode. Unless the library you are referring to is part of the
> opeating system, I don't think it will help you. Of course, I've not used
> MSLFU as I tend to write applications that target NT, 2000 and XP so take
> this particular piece of advice with a grain of skepticism.
You are correct, FWIW.
Now MSLU would allow your apps to run on all platforms, so it might be worth
taking a look at. :-)
Jacquin Buchanan
I have two real options. Find libraries that will do unicode builds and
therefore limit my applications features or switch my application to JAVA,
whichs has a more elegent solutions to such problems. I think those will be
my short term and long term plans respectively.
Thank you for your input, you saved me a lot of work trying out the MSLU.
( I might still do that if any customers insist on running under Windows 98
or ME).
Jack
"Michael (michka) Kaplan" <forme...@spamfree.trigeminal.nospam.com> wrote
in message news:#T01T6udBHA.1360@tkmsftngp02...
Michael (michka) Kaplan
a great deal of junk lately that has been touted as "best practices" for
Java in relation to locale modeling and supplementary character support.
--
MichKa
Michael Kaplan
(principal developer of the MSLU)
Trigeminal Software, Inc. -- http://www.trigeminal.com/
the book -- http://www.i18nWithVB.com/
"Jacquin Buchanan" <Jacquin....@MarineAcoustics.com> wrote in message
news:uY3tYC3dBHA.1952@tkmsftngp03...
Gerd Gerold
I have the same problem. Our app is Unicode and we are
dependant on 3'rd party dlls linking to non-Unicode mfc
dlls (AutoDesk(!) among others). The problems with mixed
MFC environments seems to arise when or after
concurrencing threads are using different mfc.dlls on the
same objects. I made a certain thread mfc-free by using
STL. The thread is using the 3'rd parties extensively. I
am crash-free now ( and hopefully stay ). Are you using
different threads? Then this might apply to your problem.
Gerd.
>.
>