• Walter (12/12) Mar 26 2002 If you have DMC 8.27.4, there's a bug causing bad code to be generated w...
• Chris (34/46) Mar 28 2002 Walter,
• Walter (8/38) Mar 28 2002 Run the undefined symbols through "unmangle" to see what they are, and p...
• Chris (25/68) Mar 29 2002 Ok, this is interesting, unmangle output:
• Walter (20/90) Mar 29 2002 It sounds like you are compiling with one set of MFC headers, and linkin...
• Chris (46/148) Mar 29 2002 Which is strange, as the only change I make is to set the project settin...
• Walter (8/18) Mar 29 2002 with
• Chris (5/24) Mar 30 2002 OK, the -50 works fine. I've sent the dumps of the -5 and -50 compile to
• Walter (12/53) Mar 29 2002 somehow
• Chris (7/68) Mar 30 2002 O that's ok, the one big bonus is that the IDDE allows you to open the

"Walter" <walter digitalmars.com> writes:

If you have DMC 8.27.4, there's a bug causing bad code to be generated when
a stack frame is larger than 4k bytes and full optimization is on. The bug
will cause a stack overflow crash. It only is in 8.27.4.

To find out which version you have, run scppn:

\dm\bin\scppn
Digital Mars C/C++ Compiler Version 8.27.4n
Copyright (C) Digital Mars 2000-2002.  All Rights Reserved.
Written by Walter Bright
www.digitalmars.com

If you have that one, or if you have the CD with v827.2 in the \dm
directory, download the update to 8.27.5:

    ftp://ftp.digitalmars.com/dmc.zip

Chris <chris widdows.demon.nl> writes:

On Tue, 26 Mar 2002 16:11:00 -0800, "Walter" <walter digitalmars.com>
wrote:

If you have DMC 8.27.4, there's a bug causing bad code to be generated when
a stack frame is larger than 4k bytes and full optimization is on. The bug
will cause a stack overflow crash. It only is in 8.27.4.

To find out which version you have, run scppn:

\dm\bin\scppn
Digital Mars C/C++ Compiler Version 8.27.4n
Copyright (C) Digital Mars 2000-2002.  All Rights Reserved.
Written by Walter Bright
www.digitalmars.com

If you have that one, or if you have the CD with v827.2 in the \dm
directory, download the update to 8.27.5:

    ftp://ftp.digitalmars.com/dmc.zip

Walter,

Thought this might be the answer to a problem I'm seeing. But it wasn't.
The problem I'm having is the following:
The  MFC program, debug build using default options, linking against de DLL
MFC and runtime works fine. But when I switch to release I change the
following, link using libs statically (both MFC and runtime), use fast
floating point and optimise for pentium. This code crashes upon entering an
otherwise normal C++ function. Now I can solve this crash via two different
routes, one is to set the optimisation to 486 the other is to not compile
for NT, but for W95. However when I compile for W95, all the buttons turn
out much more narrow than the NT compile produces, up to the point that the
test doesn't fit anymore. Switching to single byte still gives the error,
switching to Unicode causes the IDDE to vanish. 

I know I have the Unicode build working for a simple W32 API program, but
cannot seem to get it right for a more elaborate MFC program. As the IDDE
blows upon linking I tried smake, which produced:

        LINK /NOI /DE /PACKF /XN /NT /ENTRY:WinMainCRTStartup /BAS:4194304
/A:512 /RC   :PicPrint.RES  PicPrint.LNK
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

mainfrm.OBJ(mainfrm)
 Error 42: Symbol Undefined
?Create CWnd  UAEHPB_Y0KABUtagRECT  PAV1 IPAUCCreate
Context   Z
picprdoc.OBJ(picprdoc)
 Error 42: Symbol Undefined ?DoSave CDocument  UAEHPB_YH Z
picprdoc.OBJ(picprdoc)
 Error 42: Symbol Undefined ?OnSaveDocument CDocument  UAEHPB_Y Z
SMAKE fatal error: command "LINK" returned with error code 128
Stopping.

Confused, hope you can help.

Regards, Chris.

"Walter" <walter digitalmars.com> writes:

Run the undefined symbols through "unmangle" to see what they are, and poke
around in MFC to see where they are defined. -Walter

"Chris" <chris widdows.demon.nl> wrote in message
news:2pk7ausbth1hg910bpc8o9rmg2rf9kgea2 4ax.com...
 The problem I'm having is the following:
 The  MFC program, debug build using default options, linking against de

DLL
 MFC and runtime works fine. But when I switch to release I change the
 following, link using libs statically (both MFC and runtime), use fast
 floating point and optimise for pentium. This code crashes upon entering

an
 otherwise normal C++ function. Now I can solve this crash via two

different
 routes, one is to set the optimisation to 486 the other is to not compile
 for NT, but for W95. However when I compile for W95, all the buttons turn
 out much more narrow than the NT compile produces, up to the point that

the
 test doesn't fit anymore. Switching to single byte still gives the error,
 switching to Unicode causes the IDDE to vanish.

 I know I have the Unicode build working for a simple W32 API program, but
 cannot seem to get it right for a more elaborate MFC program. As the IDDE
 blows upon linking I tried smake, which produced:

         LINK /NOI /DE /PACKF /XN /NT /ENTRY:WinMainCRTStartup /BAS:4194304
 /A:512 /RC   :PicPrint.RES  PicPrint.LNK
 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 mainfrm.OBJ(mainfrm)
  Error 42: Symbol Undefined
 ?Create CWnd  UAEHPB_Y0KABUtagRECT  PAV1 IPAUCCreate
 Context   Z
 picprdoc.OBJ(picprdoc)
  Error 42: Symbol Undefined ?DoSave CDocument  UAEHPB_YH Z
 picprdoc.OBJ(picprdoc)
  Error 42: Symbol Undefined ?OnSaveDocument CDocument  UAEHPB_Y Z
 SMAKE fatal error: command "LINK" returned with error code 128
 Stopping.

 Confused, hope you can help.

 Regards, Chris.

Chris <chris widdows.demon.nl> writes:

On Thu, 28 Mar 2002 23:57:01 -0800, "Walter" <walter digitalmars.com>
wrote:

Run the undefined symbols through "unmangle" to see what they are, and poke
around in MFC to see where they are defined. -Walter

Ok, this is interesting, unmangle output:

?DoSave CDocument  UAEHPB_YH Z
int syscall CDocument::DoSave(int )
?Create CWnd  UAEHPB_Y0KABUtagRECT  PAV1 IPAUCCreateContext   Z
int syscall CWnd::Create(unsigned long ,tagRECT const &,CWnd *,unsigned
,CCreate
Context *)
?OnSaveDocument CDocument  UAEHPB_Y Z
?OnSaveDocument CDocument  UAEHPB_Y Z

The one that precedes the linker dump doesn't unmangle...

The int DoSave (int) doesn't exist.  For 32bit we do have BOOL
CDocument::DoSave(LPCTSTR lpszPathName, BOOL bReplace) in doccore.cpp line
294. Mangled name doesn't match the dosave in the defs.

The CWnd::Create exists, but in the source has two extra LPCTSTR's before
the list mentioned by unmangle. Wincore.cpp line 682.

So here we have in both cases disappearing LPCTSTR's, must mean something. 

Is this related to the P5 optimisation error, and what exactly is the
difference by specifying W95 instead of NT from the IDDE, because the W95
works, the NT version doesn't. There seems to be a relation between W95, NT
and single, MCBS or Unicode compilation, the ability to spec W95 and
UNICODE seems interesting ;-) But because I have a workaround, the unicode
problem seems more important, but would like the P5 opts to work as well.

Chris


"Chris" <chris widdows.demon.nl> wrote in message
news:2pk7ausbth1hg910bpc8o9rmg2rf9kgea2 4ax.com...
 The problem I'm having is the following:
 The  MFC program, debug build using default options, linking against de

DLL
 MFC and runtime works fine. But when I switch to release I change the
 following, link using libs statically (both MFC and runtime), use fast
 floating point and optimise for pentium. This code crashes upon entering

an
 otherwise normal C++ function. Now I can solve this crash via two

different
 routes, one is to set the optimisation to 486 the other is to not compile
 for NT, but for W95. However when I compile for W95, all the buttons turn
 out much more narrow than the NT compile produces, up to the point that

the
 test doesn't fit anymore. Switching to single byte still gives the error,
 switching to Unicode causes the IDDE to vanish.

 I know I have the Unicode build working for a simple W32 API program, but
 cannot seem to get it right for a more elaborate MFC program. As the IDDE
 blows upon linking I tried smake, which produced:

         LINK /NOI /DE /PACKF /XN /NT /ENTRY:WinMainCRTStartup /BAS:4194304
 /A:512 /RC   :PicPrint.RES  PicPrint.LNK
 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 mainfrm.OBJ(mainfrm)
  Error 42: Symbol Undefined
 ?Create CWnd  UAEHPB_Y0KABUtagRECT  PAV1 IPAUCCreate
 Context   Z
 picprdoc.OBJ(picprdoc)
  Error 42: Symbol Undefined ?DoSave CDocument  UAEHPB_YH Z
 picprdoc.OBJ(picprdoc)
  Error 42: Symbol Undefined ?OnSaveDocument CDocument  UAEHPB_Y Z
 SMAKE fatal error: command "LINK" returned with error code 128
 Stopping.

 Confused, hope you can help.

 Regards, Chris.

"Walter" <walter digitalmars.com> writes:

It sounds like you are compiling with one set of MFC headers, and linking
with a mismatched version of the MFC library.

I don't know what's different about targetting Win95 vs WinNT, I know there
is no difference as far as the compiler is concerned.

Different code gets generated for the Pentium than for other Intel
processors. Tracking down just why one version works and another doesn't can
be difficult, but to start with mix & match the .obj files until you find
which .obj file has the error in it, then try working down to the function
level.

"Chris" <chris widdows.demon.nl> wrote in message
news:bfc8au4lop72lhbn51ald56rp6rs0vuip2 4ax.com...
 On Thu, 28 Mar 2002 23:57:01 -0800, "Walter" <walter digitalmars.com>
 wrote:

Run the undefined symbols through "unmangle" to see what they are, and


poke
around in MFC to see where they are defined. -Walter

 Ok, this is interesting, unmangle output:

 ?DoSave CDocument  UAEHPB_YH Z
 int syscall CDocument::DoSave(int )
 ?Create CWnd  UAEHPB_Y0KABUtagRECT  PAV1 IPAUCCreateContext   Z
 int syscall CWnd::Create(unsigned long ,tagRECT const &,CWnd *,unsigned
 ,CCreate
 Context *)
 ?OnSaveDocument CDocument  UAEHPB_Y Z
 ?OnSaveDocument CDocument  UAEHPB_Y Z

 The one that precedes the linker dump doesn't unmangle...

 The int DoSave (int) doesn't exist.  For 32bit we do have BOOL
 CDocument::DoSave(LPCTSTR lpszPathName, BOOL bReplace) in doccore.cpp line
 294. Mangled name doesn't match the dosave in the defs.

 The CWnd::Create exists, but in the source has two extra LPCTSTR's before
 the list mentioned by unmangle. Wincore.cpp line 682.

 So here we have in both cases disappearing LPCTSTR's, must mean something.

 Is this related to the P5 optimisation error, and what exactly is the
 difference by specifying W95 instead of NT from the IDDE, because the W95
 works, the NT version doesn't. There seems to be a relation between W95,

NT
 and single, MCBS or Unicode compilation, the ability to spec W95 and
 UNICODE seems interesting ;-) But because I have a workaround, the unicode
 problem seems more important, but would like the P5 opts to work as well.

 Chris


"Chris" <chris widdows.demon.nl> wrote in message
news:2pk7ausbth1hg910bpc8o9rmg2rf9kgea2 4ax.com...
 The problem I'm having is the following:
 The  MFC program, debug build using default options, linking against de

DLL
 MFC and runtime works fine. But when I switch to release I change the
 following, link using libs statically (both MFC and runtime), use fast
 floating point and optimise for pentium. This code crashes upon



entering
an
 otherwise normal C++ function. Now I can solve this crash via two

different
 routes, one is to set the optimisation to 486 the other is to not



compile
 for NT, but for W95. However when I compile for W95, all the buttons



turn
 out much more narrow than the NT compile produces, up to the point that

the
 test doesn't fit anymore. Switching to single byte still gives the



error,
 switching to Unicode causes the IDDE to vanish.

 I know I have the Unicode build working for a simple W32 API program,



but
 cannot seem to get it right for a more elaborate MFC program. As the



IDDE
 blows upon linking I tried smake, which produced:

         LINK /NOI /DE /PACKF /XN /NT /ENTRY:WinMainCRTStartup



/BAS:4194304
 /A:512 /RC   :PicPrint.RES  PicPrint.LNK
 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 mainfrm.OBJ(mainfrm)
  Error 42: Symbol Undefined
 ?Create CWnd  UAEHPB_Y0KABUtagRECT  PAV1 IPAUCCreate
 Context   Z
 picprdoc.OBJ(picprdoc)
  Error 42: Symbol Undefined ?DoSave CDocument  UAEHPB_YH Z
 picprdoc.OBJ(picprdoc)
  Error 42: Symbol Undefined ?OnSaveDocument CDocument  UAEHPB_Y Z
 SMAKE fatal error: command "LINK" returned with error code 128
 Stopping.

 Confused, hope you can help.

 Regards, Chris.

Chris <chris widdows.demon.nl> writes:

On Fri, 29 Mar 2002 09:13:47 -0800, "Walter" <walter digitalmars.com>
wrote:

It sounds like you are compiling with one set of MFC headers, and linking
with a mismatched version of the MFC library.

Which is strange, as the only change I make is to set the project settings
to UNICODE instead of MCBS. How does this tie in with the fact that somehow
the name mangling is leaving the LPCTSTR's out, which just happen to be the
one thing that changes with the UNICODE compile. I was guessing that
somehow the MFC header got messed and the compiler started emitting badly
mangled names. The defines are switched correctly for MCBS/UNICODE, as is
the entry point. I've tried some settings to check, but now the linker is
reacting badly to other names, and none of those will unmangle, which seems
to indicate that the names are not the problem. And it causes the IDDE to
vanish, so the linker really doesn't like what's going on. 

In fact, I can reproduce this with a simple project. Use Appexpress to
create a SDI application, no OLE, 32-bit, NT and include help.
Then change the following project settings:

MFC DLL not LIB, character type UNICODE

Do a full rebuild, this gives two errors in the CMainFrame OnCreate, two
TRACE lines. Enclose the string with _T(...) for both TRACE macros and
recompile. With me it now compiles correctly, but the IDDE vanishes when
linking. Run smake on the make in the project directory and I see the same
messages that plague the larger project. Can anyone  reproduce this? FYI, I
use W2000 Prof as my development platform.


I don't know what's different about targetting Win95 vs WinNT, I know there
is no difference as far as the compiler is concerned.

Then it must be something with the resources. They change appearence
(buttons tend to shrink with the 95 option). 

The resource editor has other quirks as well. It is still firmly into NT
3.51 thinking with its NT vs. 95 distinction and for one doesn't seem to
offer the richedit text control (just multiline/singleline edits). It fails
to set the dropdown list attribute allthough it does display as such. I
have to manually edit the resource file. The resource compiler has no
trouble compiling it correctly once the attribute is set correctly. And for
some reason, some controls tend to shrink when repeatedly edited. Seems
like a problem with control alignment (I've had resizing dialogs from code
do something similiar), but can't see how to turn the alignment off. None
of this blocks development, but it does require some manual correction from
time to time which sometimes is a little frustrating.

Different code gets generated for the Pentium than for other Intel
processors. Tracking down just why one version works and another doesn't can
be difficult, but to start with mix & match the .obj files until you find
which .obj file has the error in it, then try working down to the function
level.

I've already traced the access violation. I have 1 global routine that can
write to a log using a printf like syntax (but using TCHAR's). You add with
each call the log level associated with that line. The routine compares
this level with the level set in the program settings, and decides to write
or skip based on that level compare. During development the routine gets
used a lot, never with any problems (even when calling it from different
threads at the same time). When I use P5 opts, it crashes when entering
that log routine, as if the stack is messed up. It fails to reach the first
statement within the function body. Could this be related to va_arg's and
alignment of the stack discussed recently?

Chris
"Chris" <chris widdows.demon.nl> wrote in message
news:bfc8au4lop72lhbn51ald56rp6rs0vuip2 4ax.com...
 On Thu, 28 Mar 2002 23:57:01 -0800, "Walter" <walter digitalmars.com>
 wrote:

Run the undefined symbols through "unmangle" to see what they are, and


poke
around in MFC to see where they are defined. -Walter

 Ok, this is interesting, unmangle output:

 ?DoSave CDocument  UAEHPB_YH Z
 int syscall CDocument::DoSave(int )
 ?Create CWnd  UAEHPB_Y0KABUtagRECT  PAV1 IPAUCCreateContext   Z
 int syscall CWnd::Create(unsigned long ,tagRECT const &,CWnd *,unsigned
 ,CCreate
 Context *)
 ?OnSaveDocument CDocument  UAEHPB_Y Z
 ?OnSaveDocument CDocument  UAEHPB_Y Z

 The one that precedes the linker dump doesn't unmangle...

 The int DoSave (int) doesn't exist.  For 32bit we do have BOOL
 CDocument::DoSave(LPCTSTR lpszPathName, BOOL bReplace) in doccore.cpp line
 294. Mangled name doesn't match the dosave in the defs.

 The CWnd::Create exists, but in the source has two extra LPCTSTR's before
 the list mentioned by unmangle. Wincore.cpp line 682.

 So here we have in both cases disappearing LPCTSTR's, must mean something.

 Is this related to the P5 optimisation error, and what exactly is the
 difference by specifying W95 instead of NT from the IDDE, because the W95
 works, the NT version doesn't. There seems to be a relation between W95,

NT
 and single, MCBS or Unicode compilation, the ability to spec W95 and
 UNICODE seems interesting ;-) But because I have a workaround, the unicode
 problem seems more important, but would like the P5 opts to work as well.

 Chris


"Chris" <chris widdows.demon.nl> wrote in message
news:2pk7ausbth1hg910bpc8o9rmg2rf9kgea2 4ax.com...
 The problem I'm having is the following:
 The  MFC program, debug build using default options, linking against de

DLL
 MFC and runtime works fine. But when I switch to release I change the
 following, link using libs statically (both MFC and runtime), use fast
 floating point and optimise for pentium. This code crashes upon



entering
an
 otherwise normal C++ function. Now I can solve this crash via two

different
 routes, one is to set the optimisation to 486 the other is to not



compile
 for NT, but for W95. However when I compile for W95, all the buttons



turn
 out much more narrow than the NT compile produces, up to the point that

the
 test doesn't fit anymore. Switching to single byte still gives the



error,
 switching to Unicode causes the IDDE to vanish.

 I know I have the Unicode build working for a simple W32 API program,



but
 cannot seem to get it right for a more elaborate MFC program. As the



IDDE
 blows upon linking I tried smake, which produced:

         LINK /NOI /DE /PACKF /XN /NT /ENTRY:WinMainCRTStartup



/BAS:4194304
 /A:512 /RC   :PicPrint.RES  PicPrint.LNK
 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 mainfrm.OBJ(mainfrm)
  Error 42: Symbol Undefined
 ?Create CWnd  UAEHPB_Y0KABUtagRECT  PAV1 IPAUCCreate
 Context   Z
 picprdoc.OBJ(picprdoc)
  Error 42: Symbol Undefined ?DoSave CDocument  UAEHPB_YH Z
 picprdoc.OBJ(picprdoc)
  Error 42: Symbol Undefined ?OnSaveDocument CDocument  UAEHPB_Y Z
 SMAKE fatal error: command "LINK" returned with error code 128
 Stopping.

 Confused, hope you can help.

 Regards, Chris.

"Walter" <walter digitalmars.com> writes:

"Chris" <chris widdows.demon.nl> wrote in message
news:9jm9aucugbe8ue356ekk96cgold8vgbkdh 4ax.com...
 I've already traced the access violation. I have 1 global routine that can
 write to a log using a printf like syntax (but using TCHAR's). You add

with
 each call the log level associated with that line. The routine compares
 this level with the level set in the program settings, and decides to

write
 or skip based on that level compare. During development the routine gets
 used a lot, never with any problems (even when calling it from different
 threads at the same time). When I use P5 opts, it crashes when entering
 that log routine, as if the stack is messed up. It fails to reach the

first
 statement within the function body. Could this be related to va_arg's and
 alignment of the stack discussed recently?

I don't see how. But it would be interesting to OBJ2ASM that function and
see what it looks like. Try the switch -50 which does Pentium optimizations
but turns off the instruction scheduler.

Chris <chris widdows.demon.nl> writes:

On Fri, 29 Mar 2002 18:30:45 -0800, "Walter" <walter digitalmars.com>
wrote:

"Chris" <chris widdows.demon.nl> wrote in message
news:9jm9aucugbe8ue356ekk96cgold8vgbkdh 4ax.com...
 I've already traced the access violation. I have 1 global routine that can
 write to a log using a printf like syntax (but using TCHAR's). You add

with
 each call the log level associated with that line. The routine compares
 this level with the level set in the program settings, and decides to

write
 or skip based on that level compare. During development the routine gets
 used a lot, never with any problems (even when calling it from different
 threads at the same time). When I use P5 opts, it crashes when entering
 that log routine, as if the stack is messed up. It fails to reach the

first
 statement within the function body. Could this be related to va_arg's and
 alignment of the stack discussed recently?

I don't see how. But it would be interesting to OBJ2ASM that function and
see what it looks like. Try the switch -50 which does Pentium optimizations
but turns off the instruction scheduler.

OK, the -50 works fine. I've sent the dumps of the -5 and -50 compile to
you and now am very interested in what you can discover.

Chris

"Walter" <walter digitalmars.com> writes:

"Chris" <chris widdows.demon.nl> wrote in message
news:9jm9aucugbe8ue356ekk96cgold8vgbkdh 4ax.com...
 On Fri, 29 Mar 2002 09:13:47 -0800, "Walter" <walter digitalmars.com>
 wrote:

It sounds like you are compiling with one set of MFC headers, and linking
with a mismatched version of the MFC library.

 Which is strange, as the only change I make is to set the project settings
 to UNICODE instead of MCBS. How does this tie in with the fact that

somehow
 the name mangling is leaving the LPCTSTR's out, which just happen to be

the
 one thing that changes with the UNICODE compile. I was guessing that
 somehow the MFC header got messed and the compiler started emitting badly
 mangled names. The defines are switched correctly for MCBS/UNICODE, as is
 the entry point. I've tried some settings to check, but now the linker is
 reacting badly to other names, and none of those will unmangle, which

seems
 to indicate that the names are not the problem. And it causes the IDDE to
 vanish, so the linker really doesn't like what's going on.

 In fact, I can reproduce this with a simple project. Use Appexpress to
 create a SDI application, no OLE, 32-bit, NT and include help.
 Then change the following project settings:

 MFC DLL not LIB, character type UNICODE

 Do a full rebuild, this gives two errors in the CMainFrame OnCreate, two
 TRACE lines. Enclose the string with _T(...) for both TRACE macros and
 recompile. With me it now compiles correctly, but the IDDE vanishes when
 linking. Run smake on the make in the project directory and I see the same
 messages that plague the larger project. Can anyone  reproduce this? FYI,

I
 use W2000 Prof as my development platform.


I don't know what's different about targetting Win95 vs WinNT, I know


there
is no difference as far as the compiler is concerned.

 Then it must be something with the resources. They change appearence
 (buttons tend to shrink with the 95 option).

 The resource editor has other quirks as well. It is still firmly into NT
 3.51 thinking with its NT vs. 95 distinction and for one doesn't seem to
 offer the richedit text control (just multiline/singleline edits). It

fails
 to set the dropdown list attribute allthough it does display as such. I
 have to manually edit the resource file. The resource compiler has no
 trouble compiling it correctly once the attribute is set correctly. And

for
 some reason, some controls tend to shrink when repeatedly edited. Seems
 like a problem with control alignment (I've had resizing dialogs from code
 do something similiar), but can't see how to turn the alignment off. None
 of this blocks development, but it does require some manual correction

from
 time to time which sometimes is a little frustrating.

I'm sorry about that. The reason it is a bit old fashioned is that's when it
was written.

Chris <chris widdows.demon.nl> writes:

On Fri, 29 Mar 2002 21:59:32 -0800, "Walter" <walter digitalmars.com>
wrote:

"Chris" <chris widdows.demon.nl> wrote in message
news:9jm9aucugbe8ue356ekk96cgold8vgbkdh 4ax.com...
 On Fri, 29 Mar 2002 09:13:47 -0800, "Walter" <walter digitalmars.com>
 wrote:

It sounds like you are compiling with one set of MFC headers, and linking
with a mismatched version of the MFC library.

 Which is strange, as the only change I make is to set the project settings
 to UNICODE instead of MCBS. How does this tie in with the fact that

somehow
 the name mangling is leaving the LPCTSTR's out, which just happen to be

the
 one thing that changes with the UNICODE compile. I was guessing that
 somehow the MFC header got messed and the compiler started emitting badly
 mangled names. The defines are switched correctly for MCBS/UNICODE, as is
 the entry point. I've tried some settings to check, but now the linker is
 reacting badly to other names, and none of those will unmangle, which

seems
 to indicate that the names are not the problem. And it causes the IDDE to
 vanish, so the linker really doesn't like what's going on.

 In fact, I can reproduce this with a simple project. Use Appexpress to
 create a SDI application, no OLE, 32-bit, NT and include help.
 Then change the following project settings:

 MFC DLL not LIB, character type UNICODE

 Do a full rebuild, this gives two errors in the CMainFrame OnCreate, two
 TRACE lines. Enclose the string with _T(...) for both TRACE macros and
 recompile. With me it now compiles correctly, but the IDDE vanishes when
 linking. Run smake on the make in the project directory and I see the same
 messages that plague the larger project. Can anyone  reproduce this? FYI,

I
 use W2000 Prof as my development platform.


I don't know what's different about targetting Win95 vs WinNT, I know


there
is no difference as far as the compiler is concerned.

 Then it must be something with the resources. They change appearence
 (buttons tend to shrink with the 95 option).

 The resource editor has other quirks as well. It is still firmly into NT
 3.51 thinking with its NT vs. 95 distinction and for one doesn't seem to
 offer the richedit text control (just multiline/singleline edits). It

fails
 to set the dropdown list attribute allthough it does display as such. I
 have to manually edit the resource file. The resource compiler has no
 trouble compiling it correctly once the attribute is set correctly. And

for
 some reason, some controls tend to shrink when repeatedly edited. Seems
 like a problem with control alignment (I've had resizing dialogs from code
 do something similiar), but can't see how to turn the alignment off. None
 of this blocks development, but it does require some manual correction

from
 time to time which sometimes is a little frustrating.

I'm sorry about that. The reason it is a bit old fashioned is that's when it
was written.

O that's ok, the one big bonus is that the IDDE allows you to open the
resource into a text editor or the resource editor, so unlike with the boys
from Redmond, manual tweaking is a doddle.

Any luck in reproducing the 'big linker bang'?

Chris