www.digitalmars.com         C & C++   DMDScript  

c++.announce - Compiler 8.27.4 bug

reply "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
Mar 26 2002
parent reply 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.
Mar 28 2002
parent reply "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.
Mar 28 2002
parent reply 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.
Mar 29 2002
parent reply "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.
Mar 29 2002
parent reply 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.
Mar 29 2002
next sibling parent reply "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.
Mar 29 2002
parent 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
Mar 30 2002
prev sibling parent reply "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.
Mar 29 2002
parent 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
Mar 30 2002