Native app using WNET DDK for W2K, nasty problem (solved)

Hi,

since I have tried to investigate this nasty problem for hours already, I thought I’d share it with you. In fact this could be considered a bug in the DDK, but the question is whether the bug is located in the LIB file or in i386mk.inc? Read on …

If you tell BUILD from the WNET DDK to use the W2K settings to build a native application this fails with the reason that “_NtProcessStartupForGS@4” could not be resolved. It does not matter whether you try to set UMENTRYABS in the SOURCES file, the problem persists. After some investigation I found that the file i386mk.inc enforces buffer overflow checking by linking against bufferoverflow.lib! However, the bufferoverflow.lib in the W2K directory does not contain any implementation of NtProcessStartupForGS (the ones for WXP and WNET do!), while i386mk.inc still insists to use this function as the entry point to the executable:


UMENTRY=-entry:NtProcessStartupForGS@4

What a mess. There are two possible solutions, each with their advantages and disadvantages.

Solution#1: add the following line to your SOURCES file


BUFFER_OVERFLOW_CHECKS=0

This is the simpler of the two solutions, however you lose the advantage of buffer overflow checks …

Solution#2: create a new .c/.cpp file and add it to the “SOURCES” line inside the SOURCES file. In my case it is the file called startup.cpp:


extern “C” void NtProcessStartup(void * StartupArgument);

extern “C” void NtProcessStartupForGS(void * StartupArgument);

void NtProcessStartupForGS(void * StartupArgument)
{
NtProcessStartup(StartupArgument);
}

The pointer arguments are intentionally untyped. There is no necessity to include any header file in this module if they are untyped. What we do is defining the NtProcessStartupForGS() using the proper linkage (so the linker will be happy) and call NtProcessStartup(), forwarding the parameter.
Here the disadvantage is again that the buffer overflow checking is gone. However, putting the code in this module into ifdefs depending on the OS version for which the build is might be *the* way to make your project compatible among different target OS versions most easily.

Hope this is useful to someone else - now not being forced to investigate that long :wink:

Oliver

PS: The following were set in the SOURCES file:
TARGETTYPE=PROGRAM
USE_NTDLL=1
UMTYPE=nt
… and I was using nt.lib for the convenience main() function.

PPS: For search the engines to be happy … the error message was:
LINK : error LNK2001: unresolved external symbol _NtProcessStartupForGS@4
objfre_w2k_x86\i386\smss.exe : error LNK1120: 1 unresolved externals


May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.net