www.digitalmars.com         C & C++   DMDScript  

c++.mfc - MFC built, next problem

reply Chris Widdows <chris widdows.demon.nl> writes:
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
Apr 09 2002
parent reply "Walter" <walter digitalmars.com> writes:
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
Apr 09 2002
parent reply Chris <chris widdows.demon.nl> writes:
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.
Apr 09 2002
parent reply Chris Widdows <chris widdows.demon.nl> writes:
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
Apr 10 2002
parent reply "Walter" <walter digitalmars.com> writes:
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
Apr 10 2002
parent Chris Widdows <chris widdows.demon.nl> writes:
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.
Apr 17 2002