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

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
>

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

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