www.digitalmars.com         C & C++   DMDScript  

c++.announce - Linking with MFC 4.2 and C++ 8.28 beta

reply "Walter" <walter digitalmars.com> writes:
Some of you have noticed problems with unresolved symbols when linking with
MFC 4.2. I have tracked down what appears to be the problem, and posted an
update:

    ftp://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip

The problem comes from having switched to wchar_t being a real type rather
than an alias for unsigned short. The solution is to add:

    #pragma DMC mfc

to afx.h which will tell the compiler to maintain binary compatibility with
the MFC dll's. Included in the patch are new compilers and a new afx.h.

The patch also includes the new empty base class optimization, which can
give your STL applications a nice speed boost.

-Walter
Apr 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Are these people using a recompiled MFC?
I have recompiled MFC since and never experienced that problem!
(Or are they using a .DLL instead of a static library?!)
Jan



Walter wrote:

 Some of you have noticed problems with unresolved symbols when linking with
 MFC 4.2. I have tracked down what appears to be the problem, and posted an
 update:

     ftp://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip

 The problem comes from having switched to wchar_t being a real type rather
 than an alias for unsigned short. The solution is to add:

     #pragma DMC mfc

 to afx.h which will tell the compiler to maintain binary compatibility with
 the MFC dll's. Included in the patch are new compilers and a new afx.h.

 The patch also includes the new empty base class optimization, which can
 give your STL applications a nice speed boost.

 -Walter

Apr 02 2002
parent reply Chris Widdows <chris widdows.demon.nl> writes:
On Tue, 02 Apr 2002 08:10:25 -0500, Jan Knepper <jan smartsoft.cc>
wrote:

Jan,

I'm having this with the original binaries, the recompiled ones should
be ok. As I understand it, the original binaries were built when
wchar_t was unsigned short, which results is the current compiler
emitting names mangled with wchar_t and having to link with exports
mangled with unsigned short. The newer compiler has a wchar_t so if
you used that to compile MFC, it should link without the pragma.

I tried rebuilding MFC with the original source (CD and subsequent
patches), didn't work (but perhaps I chose the wrong method). I
downloaded the latest release, that didn't work either, got an
internal compiler error, so I notified Walter (again, sigh).

I've just tested the patch, and it works for me, so Walter thank you
for the quick response.

Chris

Are these people using a recompiled MFC?
I have recompiled MFC since and never experienced that problem!
(Or are they using a .DLL instead of a static library?!)
Jan



Walter wrote:

 Some of you have noticed problems with unresolved symbols when linking with
 MFC 4.2. I have tracked down what appears to be the problem, and posted an
 update:

     ftp://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip

 The problem comes from having switched to wchar_t being a real type rather
 than an alias for unsigned short. The solution is to add:

     #pragma DMC mfc

 to afx.h which will tell the compiler to maintain binary compatibility with
 the MFC dll's. Included in the patch are new compilers and a new afx.h.

 The patch also includes the new empty base class optimization, which can
 give your STL applications a nice speed boost.

 -Walter


Apr 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
Chris Widdows wrote:

 I'm having this with the original binaries, the recompiled ones should
 be ok. As I understand it, the original binaries were built when
 wchar_t was unsigned short, which results is the current compiler
 emitting names mangled with wchar_t and having to link with exports
 mangled with unsigned short. The newer compiler has a wchar_t so if
 you used that to compile MFC, it should link without the pragma.

With the original binairies, compiled with a compiler without wchar_t as a type you will be in trouble.
 I tried rebuilding MFC with the original source (CD and subsequent
 patches), didn't work (but perhaps I chose the wrong method). I
 downloaded the latest release, that didn't work either, got an
 internal compiler error, so I notified Walter (again, sigh).

I must have been lazy (or to buzy). I still use 8.1d.1n for production because I noticed there were isssue's with later versions of the compiler. I was not been able to recompile any of my projects with a certain successor and have not tried the newer versions. What are the problems you are having with recompiling MFC though?! Are you using the .tar.gz from the website?
 I've just tested the patch, and it works for me, so Walter thank you
 for the quick response.

That will work. Jan
Apr 02 2002
parent reply Chris Widdows <chris widdows.demon.nl> writes:
On Tue, 02 Apr 2002 09:36:51 -0500, Jan Knepper <jan smartsoft.cc>
wrote:

Chris Widdows wrote:

 I'm having this with the original binaries, the recompiled ones should
 be ok. As I understand it, the original binaries were built when
 wchar_t was unsigned short, which results is the current compiler
 emitting names mangled with wchar_t and having to link with exports
 mangled with unsigned short. The newer compiler has a wchar_t so if
 you used that to compile MFC, it should link without the pragma.

With the original binairies, compiled with a compiler without wchar_t as a type you will be in trouble.

As I understand and experience it, with a compiler WITH a real wchar_t AND linking with the ORIGINAL MFC libs/dll's AND using UNICODE you will be in trouble. (caps are for me, BTW). The compiler that uses an alias for wchar_t WILL link with the original MFC libs/dll's. All compilers should link to libs/dll's they created.
 I tried rebuilding MFC with the original source (CD and subsequent
 patches), didn't work (but perhaps I chose the wrong method). I
 downloaded the latest release, that didn't work either, got an
 internal compiler error, so I notified Walter (again, sigh).

I must have been lazy (or to buzy). I still use 8.1d.1n for production because I noticed there were isssue's with later versions of the compiler. I was not been able to recompile any of my projects with a certain successor and have not tried the newer versions. What are the problems you are having with recompiling MFC though?! Are you using the .tar.gz from the website?

I took the tar from the website, and the one that worked best for me was using the allmfc.mak from the projects subdir. The prj's in the sc subdir didn't work as is. What I really wanted was to rebuild the original source to new MFC's to circumvent the UNICODE build problems I was having. The one on the website is a newer MFC, but installing it breaks 16-bit MFC installed, I tried that as well, but ran into a internal compiler error. Walter's looking into that, as the steps to reproduce are easy (but I don't have then with me right now). As for the original mfc source, the prj's looked a little suspect (release libs coming up in a debug build) and it looked to me that some work was required to get them to build with the newer compiler, so I didn't follow through.
 I've just tested the patch, and it works for me, so Walter thank you
 for the quick response.

That will work. Jan

Apr 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
 As I understand and experience it, with a compiler WITH a real wchar_t
 AND linking with the ORIGINAL MFC libs/dll's AND using UNICODE you
 will be in trouble. (caps are for me, BTW).

Yes! wchar_t != unsigned short && wchar_t != signed short
 The compiler that uses an alias for wchar_t WILL link with the
 original MFC libs/dll's.

Yup!
 All compilers should link to libs/dll's they created.

<g> They will if you use the proper prototypes for the functions... SetWindowText ( unsigned short * ) is not the same as SetWindowText ( wchar_t * ) anymore...
 I took the tar from the website, and the one that worked best for me
 was using the allmfc.mak from the projects subdir. The prj's in the sc
 subdir didn't work as is.

That's probably because I still need to upgrade them to the DMC++ file formats...
 What I really wanted was to rebuild the
 original source to new MFC's to circumvent the UNICODE build problems
 I was having. The one on the website is a newer MFC, but installing it
 breaks 16-bit MFC installed,

Why is that? Do you still need the 16-bit MFC version???
 I tried that as well, but ran into a internal compiler error. Walter's looking
 into that, as the steps to
 reproduce are easy (but I don't have then with me right now).

I noticed problems too with one of the later compilers when compiling MFC and MFC applications. I have not gotten the time however to properly report the problems...
 As for the original mfc source, the prj's looked a little suspect
 (release libs coming up in a debug build) and it looked to me that
 some work was required to get them to build with the newer compiler,
 so I didn't follow through.

Correct! I hope to get to that someday soon. For now I first patched IMPLIB.exe so it can parse header files, find a function prototype and add the n for most of the exported functions. It does not work 100%, but so far I have got very good results on the LEADTOOLS .dll's. Jan
Apr 02 2002
parent reply Chris <chris widdows.demon.nl> writes:
On Tue, 02 Apr 2002 13:19:16 -0500, Jan Knepper <jan smartsoft.cc> wrote:

 I took the tar from the website, and the one that worked best for me
 was using the allmfc.mak from the projects subdir. The prj's in the sc
 subdir didn't work as is.

That's probably because I still need to upgrade them to the DMC++ file formats...
 What I really wanted was to rebuild the
 original source to new MFC's to circumvent the UNICODE build problems
 I was having. The one on the website is a newer MFC, but installing it
 breaks 16-bit MFC installed,

Why is that? Do you still need the 16-bit MFC version???

Well the structure of the newer MFC resides one level of the two that are included standard. In \dm\mfc\include you have stubs for all mfc headers, going to subdir 32-bit or 16-bit depending on the build. The newer 32-bit should overwrite the previous 32-bit, but leave the 16-bit unaffected IMO. No, I don't really need 16-bit, but it is a feature and I have some tick about removing stuff I might need. There is no real reason other than that would render some options in some dialogs unusable, and I like options to work ;-) But somebody else might really need the 16-bit stuff, and might not like the idea of breaking that to be able to use the latest 32-bit.
 I tried that as well, but ran into a internal compiler error. Walter's looking
 into that, as the steps to
 reproduce are easy (but I don't have then with me right now).

I noticed problems too with one of the later compilers when compiling MFC and MFC applications. I have not gotten the time however to properly report the problems...

Well the Unicode problem seems solved, and the internal errors seem gone, but the mak's are messed. They're referencing other mak's that are not there (under that name). For instance allmfc.mak reference smfc42d.mak, and I only see sfc42d.mak. I know this easy to solve, but having to do that does not instill great confidence that the results is as intended.
 As for the original mfc source, the prj's looked a little suspect
 (release libs coming up in a debug build) and it looked to me that
 some work was required to get them to build with the newer compiler,
 so I didn't follow through.

Correct! I hope to get to that someday soon.

That would be great, just one prj, load, no adjust, hit rebuild all and every single MFC lib/dll combo is rebuilt. Without even upgrading the MFC stuff, I would still let the libs profit from the advancement in the compiler. Up to now I haven't had any need for MS's latest, the that is included by default works for me.
For now I first patched IMPLIB.exe so it can parse header files, find a function
prototype and add the  n for most of the exported functions. It does not work
100%,
but so far I have got very good results on the LEADTOOLS .dll's.

I have a tool that will list any DLL's exported function, ordinal and all and save the output to clipboard. I use it to build a def file for implib that allows the __fhfhf xx to map to the exported _dfhfg or ordinal. That way I let DMC++ generate the symbol it wants, and map it to the correct exported function. As ever there's a system to this and I have never got around scripting it, I just use manual control. I could try your implib to see how it reacts to the dll's I use.
Jan

Chris
Apr 02 2002
parent Jan Knepper <jan smartsoft.cc> writes:
 Well the structure of the newer MFC resides one level of the two that are
 included standard. In \dm\mfc\include you have stubs for all mfc headers,
 going to subdir 32-bit or 16-bit depending on the build. The newer 32-bit
 should overwrite the previous 32-bit, but leave the 16-bit unaffected IMO.

 No, I don't really need 16-bit, but it is a feature and I have some tick
 about removing stuff I might need. There is no real reason other than that
 would render some options in some dialogs unusable, and I like options to
 work ;-) But somebody else might really need the 16-bit stuff, and might
 not like the idea of breaking that to be able to use the latest 32-bit.

Well, in that case you could install the newer MFC (.tar.gz) in an different directory and just change the include and lib path's in the IDDE project. That's basically all there is to it. <g>
 Well the Unicode problem seems solved, and the internal errors seem gone,
 but the mak's are messed. They're referencing other mak's that are not
 there (under that name). For instance allmfc.mak reference smfc42d.mak, and
 I only see sfc42d.mak. I know this easy to solve, but having to do that
 does not instill great confidence that the results is as intended.

Is this in the Projects directory?
 That would be great, just one prj, load, no adjust, hit rebuild all and
 every single MFC lib/dll combo is rebuilt. Without even upgrading the MFC
 stuff, I would still let the libs profit from the advancement in the
 compiler. Up to now I haven't had any need for MS's latest, the that is
 included by default works for me.

Well, that will be one main .prj file which probably will include quite a few others... MS's latest MFC (I think that is 7.0 by now) I will try to port sometime later this year.
For now I first patched IMPLIB.exe so it can parse header files, find a function
prototype and add the  n for most of the exported functions. It does not work
100%,
but so far I have got very good results on the LEADTOOLS .dll's.

I have a tool that will list any DLL's exported function, ordinal and all and save the output to clipboard. I use it to build a def file for implib that allows the __fhfhf xx to map to the exported _dfhfg or ordinal. That way I let DMC++ generate the symbol it wants, and map it to the correct exported function. As ever there's a system to this and I have never got around scripting it, I just use manual control. I could try your implib to see how it reacts to the dll's I use.

Well, the problem with that is that functions seem to reside in a .DLL as L_CreateBitmap. While DMC through compiling generates _L_CreateBitmap 12 The point is, I used to do it the way you do it. Just create a .def file someway somehow. However... that still is a tedeous job, especially if you are talking .DLL't with literally hundreds of exported functions. Yet, I finally got in trouble and patched IMPLIB... It does not always work perfectly (it is not a C/C++ parser so it could take the wrong prototype out of the headers file, like one that is 'commented' I had to add a little check for that yesterday), but it certainly has made my life easier, and adding the little check was a lot easier than writing the .def file manually... Jan
Apr 02 2002