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

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

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

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

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
>

> 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

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

> 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