www.digitalmars.com         C & C++   DMDScript  

c++.mfc - Some more patching.

reply Jan Knepper <jan smartsoft.cc> writes:
I've done some more patching of the MFC library.
It turned out as some of you already had noticed that the build
was incomplete, or rather problematic.
Well, sorry about that, but I guess I only included the original
'Projects' subdirectory underneath 'src' and not my own 'sc'
directory. Anyways, it is included now.
The libraries nafxcw.lib, nafxcwd.lib uafxcw.lib and uafxcwd.lib
seem to build fine. I have tested to use nafxcw.lib and
nafxcwd.lib in applications and they work fine.
Unfortunately recompiling the .DLL's is a bit more of a problem
at this moment as I do not think I have a recent enough version
of the RTL dll... Anyways, some more patching to do for me in
this corner.

Also, with the build #pragma DMC mfc is no longer necessary. I
have rebuild everything with success. I think this #pragma is
for binary compatibility of MFC compiled with earlier versions
of the compiler. Now everything can be build with one and the
same version this #pragma can be left out.

I use the following directory structure:
E:\MS
E:\MS\atl
E:\MS\MFC
E:\MS\atl\include
E:\MS\atl\lib
E:\MS\atl\src
E:\MS\MFC\4.21
E:\MS\MFC\4.21\include
E:\MS\MFC\4.21\lib
E:\MS\MFC\4.21\src
E:\MS\MFC\4.21\include\l.chs
E:\MS\MFC\4.21\include\l.cht
E:\MS\MFC\4.21\include\l.deu
E:\MS\MFC\4.21\include\l.Dutch
E:\MS\MFC\4.21\include\l.esp
E:\MS\MFC\4.21\include\l.fra
E:\MS\MFC\4.21\include\l.ita
E:\MS\MFC\4.21\include\l.kor
E:\MS\MFC\4.21\include\res
E:\MS\MFC\4.21\src\DMC
E:\MS\MFC\4.21\src\intel
E:\MS\MFC\4.21\src\l.cht
E:\MS\MFC\4.21\src\l.deu
E:\MS\MFC\4.21\src\l.fra
E:\MS\MFC\4.21\src\l.jpn
E:\MS\MFC\4.21\src\Projects
E:\MS\MFC\4.21\src\SC

I guess using something alike underneath MS/~ would make
recompiling this stuff a little easier.

Good luck!
Jan
Aug 02 2002
parent reply Chris <chris widdows.demon.nl> writes:
On Fri, 02 Aug 2002 18:39:23 -0400, Jan Knepper <jan smartsoft.cc> wrote:


I've done some more patching of the MFC library.
It turned out as some of you already had noticed that the build
was incomplete, or rather problematic.
Well, sorry about that, but I guess I only included the original
'Projects' subdirectory underneath 'src' and not my own 'sc'
directory. Anyways, it is included now.
The libraries nafxcw.lib, nafxcwd.lib uafxcw.lib and uafxcwd.lib
seem to build fine. I have tested to use nafxcw.lib and
nafxcwd.lib in applications and they work fine.
Unfortunately recompiling the .DLL's is a bit more of a problem
at this moment as I do not think I have a recent enough version
of the RTL dll... Anyways, some more patching to do for me in
this corner.

Also, with the build #pragma DMC mfc is no longer necessary. I
have rebuild everything with success. I think this #pragma is
for binary compatibility of MFC compiled with earlier versions
of the compiler. Now everything can be build with one and the
same version this #pragma can be left out.


As I remember it, the pragma solves a problem when linking to a UNICODE
dll. The compiler emits a different makeup for function with unicode in the
parameter list. Somehow the linker is unable to handle the wchar mangling
scheme and aborts. Using the pragma resolves this, as it then uses the same
mangling as for unsigned short, which does work during linking. 

To test it, switch to unicode and call an MFC function that has a wchar_t
as an argument. Using just CString or MCBS won't show the problem. The
trouble is that the default def files fail to export these functions using
the wchar_t mangling. So it seems fine until you try to link to a
particular function, the linker cannot find the module. Then if you patch
the .def and recompile MFC, the linker finds the function and bombs.

Did you add special new [] handlers? I noticed that DM is a little more
picky and unlike MSVC does need new []  in the MFC build for debug builds
only, but it was required. 

I progressed to recompiling MFC (the default sources on the CD) with 8.26
or 8.27 I thing, adding the new[] code, but still using the pragma. I did
test it with one of my more elaborate apps (the ones that gave me grief
during the recompile) and they did work in all the different combo's. It
would be great if the pragma could go, but does that also imply that the
linker has been updated?

The trouble I have with MFC is that to get any sense of success you keep
having to build/link in virtually every combo (lib/dll debug/release
mcbs/unicode). Frequently I have things working for 90% of the combo's and
failing on just one or two, this not only takes time, but also shows that a
proper test set for MFC would be a great idea.

Chris.



I use the following directory structure:
E:\MS
E:\MS\atl
E:\MS\MFC
E:\MS\atl\include
E:\MS\atl\lib
E:\MS\atl\src
E:\MS\MFC\4.21
E:\MS\MFC\4.21\include
E:\MS\MFC\4.21\lib
E:\MS\MFC\4.21\src
E:\MS\MFC\4.21\include\l.chs
E:\MS\MFC\4.21\include\l.cht
E:\MS\MFC\4.21\include\l.deu
E:\MS\MFC\4.21\include\l.Dutch
E:\MS\MFC\4.21\include\l.esp
E:\MS\MFC\4.21\include\l.fra
E:\MS\MFC\4.21\include\l.ita
E:\MS\MFC\4.21\include\l.kor
E:\MS\MFC\4.21\include\res
E:\MS\MFC\4.21\src\DMC
E:\MS\MFC\4.21\src\intel
E:\MS\MFC\4.21\src\l.cht
E:\MS\MFC\4.21\src\l.deu
E:\MS\MFC\4.21\src\l.fra
E:\MS\MFC\4.21\src\l.jpn
E:\MS\MFC\4.21\src\Projects
E:\MS\MFC\4.21\src\SC

I guess using something alike underneath MS/~ would make
recompiling this stuff a little easier.

Good luck!
Jan
Aug 08 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Chris wrote:


 As I remember it, the pragma solves a problem when linking to a UNICODE
 dll. The compiler emits a different makeup for function with unicode in the
 parameter list. Somehow the linker is unable to handle the wchar mangling
 scheme and aborts. Using the pragma resolves this, as it then uses the same
 mangling as for unsigned short, which does work during linking.


Probably if you link against an existing library. (Compiled with an older
version of the compiler).
I shaw the same problem with a non-UNICODE version as that also can deal with
UNICODE strings. After I completely recompiled without the #pragma the program
linked fine.
An other thing is that the MFC dll's do not build at this moment due to an out
dated snnd.lib...


 To test it, switch to unicode and call an MFC function that has a wchar_t
 as an argument. Using just CString or MCBS won't show the problem. The
 trouble is that the default def files fail to export these functions using
 the wchar_t mangling. So it seems fine until you try to link to a
 particular function, the linker cannot find the module. Then if you patch
 the .def and recompile MFC, the linker finds the function and bombs.


I should do that one of these days. But I would have to be able to decently
rebuild the MFC .dll's...


 Did you add special new [] handlers? I noticed that DM is a little more
 picky and unlike MSVC does need new []  in the MFC build for debug builds
 only, but it was required.


I think I did that a long time ago.


 I progressed to recompiling MFC (the default sources on the CD) with 8.26
 or 8.27 I thing, adding the new[] code, but still using the pragma. I did
 test it with one of my more elaborate apps (the ones that gave me grief
 during the recompile) and they did work in all the different combo's. It
 would be great if the pragma could go, but does that also imply that the
 linker has been updated?


Linker does not have to be updated for this. As I understood the #pragma is for
binary compatibility of newly compiled code (with a newer compiler) and an
other MFC .lib (any form!) (thus compiled with an older compiled that does not
have wchar_t as a distinct type.


 The trouble I have with MFC is that to get any sense of success you keep
 having to build/link in virtually every combo (lib/dll debug/release
 mcbs/unicode). Frequently I have things working for 90% of the combo's and
 failing on just one or two, this not only takes time, but also shows that a
 proper test set for MFC would be a great idea.


<g>
I do not seem to have that problem. However... I usually only use static
linking of a release library. <g>

Jan
Aug 08 2002
parent Chris <chris widdows.demon.nl> writes:
On Thu, 08 Aug 2002 20:25:08 -0400, Jan Knepper <jan smartsoft.cc> wrote:


Chris wrote:


 As I remember it, the pragma solves a problem when linking to a UNICODE
 dll. The compiler emits a different makeup for function with unicode in the
 parameter list. Somehow the linker is unable to handle the wchar mangling
 scheme and aborts. Using the pragma resolves this, as it then uses the same
 mangling as for unsigned short, which does work during linking.


Probably if you link against an existing library. (Compiled with an older
version of the compiler).
I shaw the same problem with a non-UNICODE version as that also can deal with
UNICODE strings. After I completely recompiled without the #pragma the program
linked fine.
An other thing is that the MFC dll's do not build at this moment due to an out
dated snnd.lib...


Well that might be it, the DLL's do compile with or without the pragma for
me, it is during linking things bomb as soon as I lose the pragma. I
remember sending a detailed report to Walter, and remember something about
the name mangling being different when the pragma isn't in effect and the
compiler being able to cope better than the linker. It was months ago, and
the details are fuzzy. 


 To test it, switch to unicode and call an MFC function that has a wchar_t
 as an argument. Using just CString or MCBS won't show the problem. The
 trouble is that the default def files fail to export these functions using
 the wchar_t mangling. So it seems fine until you try to link to a
 particular function, the linker cannot find the module. Then if you patch
 the .def and recompile MFC, the linker finds the function and bombs.


I should do that one of these days. But I would have to be able to decently
rebuild the MFC .dll's...


 Did you add special new [] handlers? I noticed that DM is a little more
 picky and unlike MSVC does need new []  in the MFC build for debug builds
 only, but it was required.


I think I did that a long time ago.


 I progressed to recompiling MFC (the default sources on the CD) with 8.26
 or 8.27 I thing, adding the new[] code, but still using the pragma. I did
 test it with one of my more elaborate apps (the ones that gave me grief
 during the recompile) and they did work in all the different combo's. It
 would be great if the pragma could go, but does that also imply that the
 linker has been updated?


Linker does not have to be updated for this. As I understood the #pragma is for
binary compatibility of newly compiled code (with a newer compiler) and an
other MFC .lib (any form!) (thus compiled with an older compiled that does not
have wchar_t as a distinct type.


 The trouble I have with MFC is that to get any sense of success you keep
 having to build/link in virtually every combo (lib/dll debug/release
 mcbs/unicode). Frequently I have things working for 90% of the combo's and
 failing on just one or two, this not only takes time, but also shows that a
 proper test set for MFC would be a great idea.


<g>
I do not seem to have that problem. However... I usually only use static
linking of a release library. <g>


I prefer the lib version, but sometimes there is a compelling need to do
otherwise. In effect using all the different combo's serves a cheap test
suite for me. If I write proper MFC and follow most (or as much as I can
remember) of the guidelines it should work identically regardless of the
build options. That way I can worry about what goes into a program first
and deal with the build config later. Also, I hate it when something
doesn't work. It is just like when a switch on some machine doesn't work,
regardless of the fact I don't need it to work, I get irritated when it
doesn't ;-) I guess this is a little similiar.

Jan


- Chris
Aug 10 2002