Hi,

I've got the original MFC source to build with the latest compiler. Somehow I've messed something up, the MCBS libs/dlls debug/release seem sort of ok, they work (although not fully tested). The UNICODE libs debug/release work also, but the UNICODE dll's don't (debug/release don't matter).

When started from explorer nothing happens, the DMC debugger finds an exception without a call stack and MS VC6 debugger finds an access violation in the third call to NTDLL.DLL.

I'm guessing that it is something to do with the startup code and compiler, breaking the link that was there. The RTL is still as provided on the CD, the MFC code has been altered a little to work with the new compiler. All changes where MCBS/UNICODE independent (but are debug / release dependent), so why the MCBS dll works, and the UNICODE dll doesn't has left my guessing.

Any ideas?

Chris

You've found a huge problem with MFC - the lack of any sort of test suite to verify that the build works. A reasonable way to track down this problem is to run the debugger with the old and new builds, comparing, and see where they diverge.

"Chris Widdows" <chris@widdows.demon.nl> wrote in message news:meh5bugrpkcchmo1ov6017qia8rn353m10@4ax.com...
> Hi,
>
> I've got the original MFC source to build with the latest compiler. Somehow I've messed something up, the MCBS libs/dlls debug/release seem sort of ok, they work (although not fully tested). The UNICODE libs debug/release work also, but the UNICODE dll's don't (debug/release don't matter).
>
> When started from explorer nothing happens, the DMC debugger finds an exception without a call stack and MS VC6 debugger finds an access violation in the third call to NTDLL.DLL.
>
> I'm guessing that it is something to do with the startup code and compiler, breaking the link that was there. The RTL is still as provided on the CD, the MFC code has been altered a little to work with the new compiler. All changes where MCBS/UNICODE independent (but are debug / release dependent), so why the MCBS dll works, and the UNICODE dll doesn't has left my guessing.
>
> Any ideas?
>
> Chris
>

On Tue, 9 Apr 2002 12:03:57 -0700, "Walter" <walter@digitalmars.com> wrote:

I agree about the problem with MFC, but perhaps not for this particular one. Using the MSVC debugger, it crashes on the third call into NTDLL.DLL. Nothing to track with the debugger, the DMC++ one reports the same access violation. I'm guessing the MSVC one is reporting more because it knows how to find the debug symbols for the os. So this is very, very early on. It would seem that the CRT is trying to set-up the dll, but not getting very far.

I've tried to piece together the route the startup code takes, but haven't been succesfull. As all other builds are getting past this point it has something to do the way everything gets setup for a unicode dll. One thing I did notice, the MCBS export complained that the new[] I had introduced for the current compiler wasn't exported when linking a couple of debug libs. Exporting solved the linker error. But for unicode it never complained, which was odd, as I had forgotton to export it.

I feel that it must be something like that, I've double checked the switches used to build the lib, even using the original switches, the problem persists. Not a regular to the CRT startup and how it fires the MFC startup, I could use help. Perhaps the failing to complain about the 'forgotten' new[] is a hint. It was compiled ok, obj2asm showed it was there, but it failed to be referenced when compiling other parts. I could take it out of the MCBS build  and see who should be putting in the request and finding out why it doesn't under UNICODE.

Pity, apart from that the rebuild went very well. I even made the one of the def files for compilation with the wchar_t, but the linker stalled big time. It accepted the objs as long as one def line couldn't be exported due to the change in mangled name. Once those were resolved, and it started to generate the DLL and LIB it blew. Still IF I get MFC to compile it is only a matter of time before the linker will accept _Y in the mangling. Should also provide input into porting future versions so I'd like to solve this one.

Chris

>You've found a huge problem with MFC - the lack of any sort of test suite to verify that the build works. A reasonable way to track down this problem is to run the debugger with the old and new builds, comparing, and see where they diverge.
>

On Tue, 09 Apr 2002 23:45:05 +0200, Chris <chris@widdows.demon.nl> wrote:

I've been testing a little more and things are progressing in the proper direction. All libs / dll combo's do run the initial MDI app as generated by AppExpress. The other program I'm working on uses a DLL written in MS VC++ 6, and I am not suspecting that there is a conflict between this and the DMC++ generated stuff. It now only falls over when I link to the Debug Unicode DLL. MFC debug does alter a lot with regard to memory management, and DMC++ is different to MS VC in at least one aspect, the new and new[] overloading. MS code won't compile if you leave out the debug overrides for new[], so something in the DMC and <other DLL> during startup is conflicting. I don't know what this dll is doing, but I do know that MFC does try to link all modules to a common memory and resource pool during the init of the dll's and exe. Perhaps de debug MS runtime is doing something similar as is DMC's runtime and the conflict is there, I don't know.

If somebody knows about this stuff and can provide more than my attempt at guessing it would be appreciated.

Chris

I emailed you a compiler where you can revert to the old new[] semantices with the -Aa- switch. If the Unicode dll then works with that, that's a clear signpost as to where to look for the specific problem.

"Chris Widdows" <chris@widdows.demon.nl> wrote in message news:ejk8buor0c6sk91i6tvmuk73aml7l0v511@4ax.com...
> On Tue, 09 Apr 2002 23:45:05 +0200, Chris <chris@widdows.demon.nl> wrote:
>
> I've been testing a little more and things are progressing in the proper direction. All libs / dll combo's do run the initial MDI app as generated by AppExpress. The other program I'm working on uses a DLL written in MS VC++ 6, and I am not suspecting that there is a conflict between this and the DMC++ generated stuff. It now only falls over when I link to the Debug Unicode DLL. MFC debug does alter a lot with regard to memory management, and DMC++ is different to MS VC in at least one aspect, the new and new[] overloading. MS code won't compile if you leave out the debug overrides for new[], so something in the DMC and <other DLL> during startup is conflicting. I don't know what this dll is doing, but I do know that MFC does try to link all modules to a common memory and resource pool during the init of the dll's and exe. Perhaps de debug MS runtime is doing something similar as is DMC's runtime and the conflict is there, I don't know.
>
> If somebody knows about this stuff and can provide more than my attempt at guessing it would be appreciated.
>
> Chris
>
>

On Wed, 10 Apr 2002 20:12:03 -0700, "Walter" <walter@digitalmars.com> wrote:

I mailed you the results of that version. For those interested, the -Aa- (no special handling of new[]) solves the problem.

>I emailed you a compiler where you can revert to the old new[] semantices with the -Aa- switch. If the Unicode dll then works with that, that's a clear signpost as to where to look for the specific problem.
>