VS C++ 2003 vs WinDDK 2k3 SP1, incompatible compiler mangling?

NTDEV
1

Hello all,

I ran today in a problem when trying to link with WinDDK 2k3 SP1 linker an
application build with WinDDK 2k3 SP1 compiler and a 3rd party library built
with VS C++ 2003. It looks to me the name mangling is different and
incompatible, leading to errors such as:

error LNK2001: unresolved external symbol “__declspec(dllimport) public:
__thiscall std::basic_string,class
std::allocator >::basic_stringstd::char_traits,class std::allocator >(char const *)”
(_imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@QAE@P
BD@Z)

(A huge amount of them, got at the end:

ddkbuild complete

ABuildUNTi386 - 3212 error(s), 89 warning(s))

Using dumpbin on the 3rd party lib and on the msvcprtd.lib of WinDDK 2k3
SP1, the naming conventions looked different to me. Checking VS C++ 2003
libs, their msvcprtd.lib looks much much different (for instance, 1.3 Mb
instead of the 800 kb of the WinDDK version). The x64 and IA64 versions of
the libs do not have the same issue as the Platform SDK 2k3 sp1 includes
libs compatible with WinDDK. But there is no i386 version of msvcprtd.lib in
this Platform SDK.

Working with the 3rd party, we couldn’t find any compiler option on any side
to make them work together, so the 3rd party is working on learning WinDDK
and producing a new version of its lib, a WinDDK-compatible one. Needless to
say this is lot of work.

Does anyone has an easier solution?

Best regards,

David Burg

----------------------------------------------------------------
David Burg
Software Development,
InCD and Low Level Drivers Project Leader

Nero AG
Im Stoeckmaedle 18 fax: +49 (0)7248 928 299
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com
----------------------------------------------------------------

2

The name mangling issue might be due to one of the libraries being
compiled with the -Zc:wchar_t and the other not.

>> xxxxx@nero.com 6/6/2005 11:03:53 AM >>>
Hello all,

I ran today in a problem when trying to link with WinDDK 2k3 SP1 linker
an
application build with WinDDK 2k3 SP1 compiler and a 3rd party library
built
with VS C++ 2003. It looks to me the name mangling is different and
incompatible, leading to errors such as:

error LNK2001: unresolved external symbol “__declspec(dllimport)
public:
__thiscall std::basic_string,class
std::allocator >::basic_stringstd::char_traits,class std::allocator >(char const *)”
(_imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@QAE@P
BD@Z)

(A huge amount of them, got at the end:

ddkbuild complete

ABuildUNTi386 - 3212 error(s), 89 warning(s))

Using dumpbin on the 3rd party lib and on the msvcprtd.lib of WinDDK
2k3
SP1, the naming conventions looked different to me. Checking VS C++
2003
libs, their msvcprtd.lib looks much much different (for instance, 1.3
Mb
instead of the 800 kb of the WinDDK version). The x64 and IA64 versions
of
the libs do not have the same issue as the Platform SDK 2k3 sp1
includes
libs compatible with WinDDK. But there is no i386 version of
msvcprtd.lib in
this Platform SDK.

Working with the 3rd party, we couldn’t find any compiler option on any
side
to make them work together, so the 3rd party is working on learning
WinDDK
and producing a new version of its lib, a WinDDK-compatible one.
Needless to
say this is lot of work.

Does anyone has an easier solution?

Best regards,

David Burg

----------------------------------------------------------------
David Burg
Software Development,
InCD and Low Level Drivers Project Leader

Nero AG
Im Stoeckmaedle 18 fax: +49 (0)7248 928 299
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com
----------------------------------------------------------------

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

The DDK uses (more or less) the same 32-bit C/C++ compiler as VS 2003.
However, the headers and runtime libraries are NOT the same. VS 2003
uses msvcr71.dll and msvcp71.dll, which ship with VS, and must be
redistributed by apps that use them. The DDK uses msvcrt.dll and
msvcp60.dll, which ship with the OS. The C runtimes are mostly
interchangable, but the C++ runtimes are not.

Your third-party library provider needs to build against the
headers/libs in the DDK. This requires installing the DDK, but doesn’t
require converting to build.exe. They should be able to do it from
Visual Studio by adjusting the directory paths (Tools | Options |
Projects | VC++ Directories). They’ll also need to add
BufferOverflowU.lib as an Additional Dependency to any EXE/DLL VS
project.

It’s also possible to use build.exe with the VS headers/libraries. This
is a bigger problem than using VS with the DDK files, and is left as an
exercise for the reader.

–John

-----Original Message-----
From: David Burg
Sent: Monday, June 06, 2005 10:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] VS C++ 2003 vs WinDDK 2k3 SP1, incompatible compiler
mangling?

Hello all,

I ran today in a problem when trying to link with WinDDK 2k3 SP1 linker
an
application build with WinDDK 2k3 SP1 compiler and a 3rd party library
built
with VS C++ 2003. It looks to me the name mangling is different and
incompatible, leading to errors such as:

error LNK2001: unresolved external symbol “__declspec(dllimport) public:
__thiscall std::basic_string,class
std::allocator >::basic_stringstd::char_traits,class std::allocator >(char const *)”
(_imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@Q
AE@P
BD@Z)

(A huge amount of them, got at the end:

ddkbuild complete

ABuildUNTi386 - 3212 error(s), 89 warning(s))

Using dumpbin on the 3rd party lib and on the msvcprtd.lib of WinDDK 2k3
SP1, the naming conventions looked different to me. Checking VS C++ 2003
libs, their msvcprtd.lib looks much much different (for instance, 1.3 Mb
instead of the 800 kb of the WinDDK version). The x64 and IA64 versions
of
the libs do not have the same issue as the Platform SDK 2k3 sp1 includes
libs compatible with WinDDK. But there is no i386 version of
msvcprtd.lib in
this Platform SDK.

Working with the 3rd party, we couldn’t find any compiler option on any
side
to make them work together, so the 3rd party is working on learning
WinDDK
and producing a new version of its lib, a WinDDK-compatible one.
Needless to
say this is lot of work.

Does anyone has an easier solution?

Best regards,

David Burg

4

Exporting the C++ mangled names from the DLLs shipped as a toolkit to 3rd
parties without sources is a very, very dirty thing.

Can you choose another library (open source, for instance) or develop the
thing in house?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “David Burg”
To: “Windows System Software Devs Interest List”
Sent: Monday, June 06, 2005 7:03 PM
Subject: [ntdev] VS C++ 2003 vs WinDDK 2k3 SP1, incompatible compiler mangling?

> Hello all,
>
> I ran today in a problem when trying to link with WinDDK 2k3 SP1 linker an
> application build with WinDDK 2k3 SP1 compiler and a 3rd party library built
> with VS C++ 2003. It looks to me the name mangling is different and
> incompatible, leading to errors such as:
>
> error LNK2001: unresolved external symbol “__declspec(dllimport) public:
>__thiscall std::basic_string,class
> std::allocator >::basic_string> std::char_traits,class std::allocator >(char const *)”
> (_imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@QAE@P
> BD@Z)
>
> (A huge amount of them, got at the end:
>
> ddkbuild complete
>
> ABuildUNTi386 - 3212 error(s), 89 warning(s))
>
> Using dumpbin on the 3rd party lib and on the msvcprtd.lib of WinDDK 2k3
> SP1, the naming conventions looked different to me. Checking VS C++ 2003
> libs, their msvcprtd.lib looks much much different (for instance, 1.3 Mb
> instead of the 800 kb of the WinDDK version). The x64 and IA64 versions of
> the libs do not have the same issue as the Platform SDK 2k3 sp1 includes
> libs compatible with WinDDK. But there is no i386 version of msvcprtd.lib in
> this Platform SDK.
>
> Working with the 3rd party, we couldn’t find any compiler option on any side
> to make them work together, so the 3rd party is working on learning WinDDK
> and producing a new version of its lib, a WinDDK-compatible one. Needless to
> say this is lot of work.
>
> Does anyone has an easier solution?
>
> Best regards,
>
> David Burg
>
> ----------------------------------------------------------------
> David Burg
> Software Development,
> InCD and Low Level Drivers Project Leader
>
> Nero AG
> Im Stoeckmaedle 18 fax: +49 (0)7248 928 299
> 76307 Karlsbad email: xxxxx@nero.com
> Germany http://www.nero.com
> ----------------------------------------------------------------
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

5

Dear Maxim,

It’s not a dll, it is a .lib file (for static linking then).

Best regards,

David Burg,
Nero AG.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, June 06, 2005 6:46 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] VS C++ 2003 vs WinDDK 2k3 SP1, incompatible compiler
mangling?

Exporting the C++ mangled names from the DLLs shipped as a toolkit to
3rd
parties without sources is a very, very dirty thing.

Can you choose another library (open source, for instance) or develop
the
thing in house?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “David Burg”
To: “Windows System Software Devs Interest List”
Sent: Monday, June 06, 2005 7:03 PM
Subject: [ntdev] VS C++ 2003 vs WinDDK 2k3 SP1, incompatible compiler
mangling?

> Hello all,
>
> I ran today in a problem when trying to link with WinDDK 2k3 SP1 linker an
> application build with WinDDK 2k3 SP1 compiler and a 3rd party library
built
> with VS C++ 2003. It looks to me the name mangling is different and
> incompatible, leading to errors such as:
>
> error LNK2001: unresolved external symbol “__declspec(dllimport) public:
>__thiscall std::basic_string,class
> std::allocator >::basic_string> std::char_traits,class std::allocator >(char const *)”
>
(_imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@QAE@P
> BD@Z)
>
> (A huge amount of them, got at the end:
>
> ddkbuild complete
>
> ABuildUNTi386 - 3212 error(s), 89 warning(s))
>
> Using dumpbin on the 3rd party lib and on the msvcprtd.lib of WinDDK 2k3
> SP1, the naming conventions looked different to me. Checking VS C++ 2003
> libs, their msvcprtd.lib looks much much different (for instance, 1.3 Mb
> instead of the 800 kb of the WinDDK version). The x64 and IA64 versions of
> the libs do not have the same issue as the Platform SDK 2k3 sp1 includes
> libs compatible with WinDDK. But there is no i386 version of msvcprtd.lib
in
> this Platform SDK.
>
> Working with the 3rd party, we couldn’t find any compiler option on any
side
> to make them work together, so the 3rd party is working on learning WinDDK
> and producing a new version of its lib, a WinDDK-compatible one. Needless
to
> say this is lot of work.
>
> Does anyone has an easier solution?
>
> Best regards,
>
> David Burg
>
> ----------------------------------------------------------------
> David Burg
> Software Development,
> InCD and Low Level Drivers Project Leader
>
> Nero AG
> Im Stoeckmaedle 18 fax: +49 (0)7248 928 299
> 76307 Karlsbad email: xxxxx@nero.com
> Germany http://www.nero.com
> ----------------------------------------------------------------
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@nero.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

David Burg wrote:

Hello all,

I ran today in a problem when trying to link with WinDDK 2k3 SP1 linker an
application build with WinDDK 2k3 SP1 compiler and a 3rd party library built
with VS C++ 2003. It looks to me the name mangling is different and
incompatible, leading to errors such as:

error LNK2001: unresolved external symbol “__declspec(dllimport) public:
__thiscall std::basic_string,class
>std::allocator >::basic_string>std::char_traits,class std::allocator >(char const *)”
>(imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@QAE@P
>BD@Z)
>
>

This does not indicate a name-mangling problem. Notice that the linker
was correctly able to decrypt the decorated name. If there was a
name-mangling problem, it would have reportsd the unresolved external
symbol as__imp??0?$basic_string…etc…

This looks like a simple library list problem. This entry point is
defined in msvcprt.lib. Are you linking with that?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

Tim Roberts, xxxxx@probo.com, wrote:

This looks like a simple library list problem. This entry point is
defined in msvcprt.lib. Are you linking with that?

Dear Tim,

Yes, I am linking with msvcprtd.lib (d because building debug)… from the
DDK, not from VS 2003. Here is the interesting build log extract:

Microsoft (R) Incremental Linker Version 7.10.4035
Copyright (C) Microsoft Corporation. All rights reserved.

-MERGE:_PAGE=PAGE
-MERGE:_TEXT=.text
-SECTION:INIT,d
-OPT:REF
-OPT:ICF
-IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221
-INCREMENTAL:NO
-FULLBUILD
/release
-NODEFAULTLIB
-debug
-debugtype:cv
-version:5.2
-osversion:5.2
/functionpadmin:5
/safeseh
/opt:nowin98
-merge:.rdata=.text
/pdbcompress
-STACK:0x40000,0x2000
/tsaware
-subsystem:console,4.00
-base:@C:\WINDDK\3790.1830\bin\coffbase.txt,usermode
-entry:mainCRTStartup
C:\WINDDK\3790.1830\lib\wnet\i386\BufferOverflowU.lib
C:\WINDDK\3790.1830\lib\crt\i386\msvcrtd.lib
C:\WINDDK\3790.1830\lib\crt\i386\msvcprtd.lib
C:\WINDDK\3790.1830\lib\wnet\i386\advapi32.lib
C:\WINDDK\3790.1830\lib\wnet\i386\kernel32.lib
C:\WINDDK\3790.1830\lib\wnet\i386\int64.lib
C:\WINDDK\3790.1830\lib\wnet\i386\ntdll.lib
C:\WINDDK\3790.1830\lib\wnet\i386\shell32.lib
C:\WINDDK\3790.1830\lib\wnet\i386\shlwapi.lib
C:\WINDDK\3790.1830\lib\wnet\i386\comctl32.lib
C:\WINDDK\3790.1830\lib\wnet\i386\uuid.lib
C:\WINDDK\3790.1830\lib\wnet\i386\ole32.lib
C:\WINDDK\3790.1830\lib\wnet\i386\oleaut32.lib
C:\WINDDK\3790.1830\lib\wnet\i386\winspool.lib
C:\WINDDK\3790.1830\lib\wnet\i386\wtsapi32.lib
C:\WINDDK\3790.1830\lib\wnet\i386\oldnames.lib
C:\WINDDK\3790.1830\lib\wnet\i386\user32.lib
C:\WINDDK\3790.1830\lib\wnet\i386\version.lib
[…]
error LNK2001: unresolved external symbol “__declspec(dllimport) public:
__thiscall std::basic_string,class
std::allocator >::basic_stringstd::char_traits,class std::allocator >(char const *)”
(_imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@QAE@P
BD@Z)
[…]

Best regards,

David Burg

----------------------------------------------------------------
David Burg
Software Development,
InCD and Low Level Drivers Project Leader

Nero AG
Im Stoeckmaedle 18 fax: +49 (0)7248 928 299
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com
----------------------------------------------------------------

8

David Burg wrote:

Tim Roberts, xxxxx@probo.com, wrote:

>This looks like a simple library list problem. This entry point is
>defined in msvcprt.lib. Are you linking with that?
>
>

Yes, I am linking with msvcprtd.lib (d because building debug)… from the
DDK, not from VS 2003. Here is the interesting build log extract:
[…]
error LNK2001: unresolved external symbol “__declspec(dllimport) public:
__thiscall std::basic_string,class
>std::allocator >::basic_string>std::char_traits,class std::allocator >(char const *)”
>(_imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@QAE@P
>BD@Z)
>
>

OK, I was wrong. This exact entry point is NOT found in the DDK’s
msvcprt.lib (although there are eight names that match the first 80
characters). It’s in the VS 2003 msvcprt.lib. And if I compile a
program that does this:

std::string xyz(“string”);

(which is what that function is), the DDK’s compiler calls a different
entry point from the VS2003 compiler.

That’s a tricky problem.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

McNamee, John suggested:

Your third-party library provider needs to build against the
headers/libs in the DDK. This requires installing the DDK, but doesn’t
require converting to build.exe. They should be able to do it from
Visual Studio by adjusting the directory paths (Tools | Options |
Projects | VC++ Directories). They’ll also need to add
BufferOverflowU.lib as an Additional Dependency to any EXE/DLL VS
project.

So they did. And they report a surprizing linkage issue on their side now.
The linker complains it can’t find CWnd::KillTimer. The MFC header
(afxwin2.inl in C:\WINDDK\3790.1830\inc\mfc42) from DDK says:

_AFXWIN_INLINE BOOL CWnd::KillTimer(UINT_PTR nIDEvent)

dumpbin /exports of ddk’s mfc42d.lib (in C:\WINDDK\3790.1830\lib\mfc\i386)
says:

3400 ?xxxxx@CWnd@@QAEHH@Z (public: int __thiscall
CWnd::KillTimer(int))

DDK Linker is seeking xxxxx@CWnd@@QAEHI@Z

Then we noticed afxwin.h expects _AFX_ENABLE_INLINES to be defined. What is
the right way to turn _AFX_ENABLE_INLINES on?

Best regards,

David Burg

David Burg
Software Development,
InCD and Low Level Drivers Project Leader

Nero AG
Im Stoeckmaedle 18 fax: +49 (0)7248 928 299
76307 Karlsbad email: xxxxx@nero.com
Germany http://www.nero.com

10

AFX_ENABLE_INLINES is defined in afxver.h. It only gets set for free
builds; checked builds don’t use MFC inlines. Did your library vendor
do a debug build?

-----Original Message-----
From: David Burg
Sent: Tuesday, June 07, 2005 1:23 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] VS C++ 2003 vs WinDDK 2k3 SP1, incompatible
compiler mangling?

McNamee, John suggested:

Your third-party library provider needs to build against the
headers/libs in the DDK. This requires installing the DDK, but
doesn’t
require converting to build.exe. They should be able to do it from
Visual Studio by adjusting the directory paths (Tools | Options |
Projects | VC++ Directories). They’ll also need to add
BufferOverflowU.lib as an Additional Dependency to any EXE/DLL VS
project.

So they did. And they report a surprizing linkage issue on their side
now.
The linker complains it can’t find CWnd::KillTimer. The MFC header
(afxwin2.inl in C:\WINDDK\3790.1830\inc\mfc42) from DDK says:

_AFXWIN_INLINE BOOL CWnd::KillTimer(UINT_PTR nIDEvent)

dumpbin /exports of ddk’s mfc42d.lib (in
C:\WINDDK\3790.1830\lib\mfc\i386)
says:

3400 ?xxxxx@CWnd@@QAEHH@Z (public: int __thiscall
CWnd::KillTimer(int))

DDK Linker is seeking xxxxx@CWnd@@QAEHI@Z

Then we noticed afxwin.h expects _AFX_ENABLE_INLINES to be defined. What
is
the right way to turn _AFX_ENABLE_INLINES on?