C ++ Windows代码链接为64位，但不是32位

Question

I have code written in C++ on windows. My code compiles and links when I compile it as x64 but not when I change the build configuration to x86.

The failure is a linking error.

I'm using the function RtlIsNameInExpression from ntdll.

When I compile it in 32bit mode I get a linkage error (LNK2019) of unresolved external.

Any ideas why this might happen?

10x

Answer 1

first of all - how you declare function and which symbol can not found linker ?

declaration must be

extern "C" NTSYSAPI BOOLEAN NTAPI RtlIsNameInExpression(
                               _In_     PCUNICODE_STRING Expression,
                               _In_     PCUNICODE_STRING Name,
                               _In_     BOOLEAN         IgnoreCase,
                               _In_opt_ PWCH            UpcaseTable
                               );

i can guess that you miss NTAPI ie __stdacall keyword if you copy-paste from here . for x64 exist only one calling convention, but for x86 exist different between __stdcall and __cdecl for example. this can explain why this found in x64 but not found in x86

what error give you linker (not compiler !) ? unresolved external symbol __imp__RtlIsNameInExpression ? (if yes you really forget __stdcall set) or __imp__RtlIsNameInExpression@16 ? in this case you declare function correct, but your ntdll.lib not containing this symbol. (may be you use old ntdll.lib for xp ? ) simply search __imp__RtlIsNameInExpression@16 string as is in ntdll[p].lib - are it found ? if not you have old (xp) version of ntdll i guess.

Answer 2

The answer is in the online documentation for that function:

This function has no associated header file. The associated import library, Ntdll.lib, is available in the Microsoft Windows Driver Kit (WDK). You can also call this function using the LoadLibrary and GetProcAddress functions to dynamically link to Ntdll.dll.

If you can't add the ntdll.lib file from the WDK to your link command, then you need to use the LoadLibrary-GetProcAddress approach.

Also from the same section of documentation:

The functions and structures in Winternl.h are internal to the operating system and subject to change from one release of Windows to the next, and possibly even between service packs for each release. To maintain the compatibility of your application, you should use the equivalent public functions instead. Further information is available in the header file, Winternl.h, and the documentation for each function.