I'm trying to compile the SysInternals Native app[^] for XP x64 (and other Windows x64 ), so I can create an app which can run during boot-time (similar to chkdsk), but am not having much luck. As SysInternals have stopped supplying native.xip, you can get it from http://www.dowers.net:8080/ftp/Programs/InsideWin2000/Sysinternals-Website/NATIVE.ZIP[^] I've installed the Windows Server 2003 DDK, and have started a Windows Server 2003 Free x64 Build environment (using the shortcut). I've then copied all the Native sources and makefile to ddk\inc, as instructed to do so at the bottom of the linked article. However, when I run build.exe, I get two identical errors:

C:\WINDDK\3790~1.183\inc>build
BUILD: Adding /Y to COPYCMD so xcopy ops won't hang.
BUILD: Using 4 child processes
BUILD: Object root set to: ==> objfre_wnet_AMD64
BUILD: Compile and Link for AMD64
BUILD: Computing Include file dependencies:
BUILD: Examining c:\winddk\3790~1.183\inc directory for files to compile.
c:\winddk\3790~1.183\inc - 1 source files (82 lines)
BUILD: Saving C:\WINDDK\3790~1.183\build.dat...
BUILD: Compiling (NoSync) c:\winddk\3790~1.183\inc directory
1>errors in directory c:\winddk\3790~1.183\inc
1>c:\winddk\3790~1.183\bin\makefile.new(1106) : error U1050: Setting TARGETPATH=
C:\WINDDK\3790~1.183\lib in .\sources is not valid - please use obj.
BUILD: nmake.exe /nologo BUILDMSG=Stop. -i NTTEST= UMTEST= NOLINK=1 NOPASS0=1 PA
SS1_NOLIB=1 AMD64=1 failed - rc = 2
BUILD: Compiling c:\winddk\3790~1.183\inc directory
100>c:\winddk\3790~1.183\bin\makefile.new(1106) : error U1050: Setting TARGETPAT
H= C:\WINDDK\3790~1.183\lib in .\sources is not valid - please use obj.
BUILD: nmake.exe failed - rc = 2
BUILD: Compile errors: not linking c:\winddk\3790~1.183\inc directory
BUILD: Done

0 files compiled - 2 Errors

What exactly does the error mean ?

1>c:\winddk\3790~1.183\bin\makefile.new(1106) : error U1050: Setting TARGETPATH=
C:\WINDDK\3790~1.183\lib in .\sources is not valid - please use obj.

How can I fix it ? Is there any good informatio

Thanks David! :)

I remember reading an article about how to correctly program for all font sizes and DPI's (eg. 96 and 120), but I can't find the article anywhere (it may not even be on CP). Can anyone help me with a link to an article, or even book reference, about making your UI compatible for all font sizes and DPI's ?

What about modules/classes ?

We all have common modules/classes/includes that we use in various projects, but people structure their code differently. For example, you could: 1) Have folders called Include and Modules, which contain the common code and then add search paths to your development environment so they get picked up. 2) Like (1), but for every project you copy over the includes/modules you require to the project folder (eg. Common\Include, Common\Modules, or just Common), and then use these copies. (1) has the advantage that any fixes/changes made to the includes/modules are immediately propogated to the projects that use them, without the need for any other work. The downside is that one of these fixes/changes may break a project (eg. due to it relying on certain behaviour) (2) has the inverse of the pros and cons of (1). Are there any other ways of working that you use ? Which model do you follow, and why ?

I've been thinking a similar thing that I might have to use some C++ features to achieve what I'm after. The idea of a template class is good, but the FuncArr[] can only be initialized with static data (ie. known at compile time). Hmmm, time to put my C++ hat on :)

You are correct, and that is the problem. If I don't cast it to the correct type when calling GetProcAddress(), I will have to cast it later on when I call the function pointed to by the pointer. Either way, I will need to cast it at some point. Otherwise I don't think it will let me call it with the relevant parameters and return type. I will have to do some testing to be sure, but my current understanding makes me think it won't work.

FARPROC is defined as a function pointer to a function that receives no input, and returns an int (ie. int func(void)). Therefore, this cannot be used for functions whose parameter list and return type are different (eg. char* func1(int)).

Unfortunately not, as you get a compiler error: error C2440: '=' : cannot convert from 'FARPROC' to 'p2DLLFunc1'

Oh, I didn't realise the fortran.exe program gets the input for the two filenames.

Roger Stoltz wrote:

My point is you can't! Try prefixing a call to e.g. strlen() with the scope resolution operator. You'll get a compiler error.

Not if the source filename extension is .cpp

modified on Tuesday, December 9, 2008 5:18 AM

Roger Stoltz wrote:

Regarding the use of any of the functions for "ending" a thread, neither of them should be used. You should simply return from the thread controlling function

Indeed, and the only bulletproof method for knowing when a thread has finished, is to Wait...() on the thread handle. :)

If it runs OK from the command-line, why don't you pass in the filenames on the command-line when you call CreateProcess() ?

But you can call C library functions from C++ programs. So in this case, would you prefix C library function calls with :: ?

Roger Stoltz wrote:

should use the beginthread and endthread

You should use beginthreadex() as it gives you more control, and endthreadex() as endthread() is fundamentally flawed.

modified on Tuesday, December 9, 2008 4:45 AM

How about C and C++ standard library function calls ?

For one of my projects I've created a class wrapper around some functions contained in a DLL. To use these DLL functions, I instantiate an object of the type class wrapper, and then call the member function LoadDLL(). LoadDLL() calls ::LoadLibrary() for the DLL, and then calls GetProcAddress() for each DLL function I wish to wrap. If any of the functions couldn't be found, I wish to FreeLibrary(), and return false. At the moment I do something along the lines of:

typedef void (*p2DLLFunc1) (void);
typedef char* (*p2DLLFunc2) (void);

bool CDLLWrapper::LoadDLL()
{
bool bResult = false;

m\_hmoduleDll = ::LoadLibrary(\_T("DLLName"));
if (NULL != m\_hmoduleDll)
{ // DLL loaded successfully. Now get addresses of all functions we are supporting
	m\_funcDLLFunc1	= reinterpret\_cast<p2DLLFunc1>(GetProcAddress(m\_hmoduleDll, \_T("DLLFunc1")));
	m\_funcDLLFunc2	= reinterpret\_cast<p2DLLFunc2>(GetProcAddress(m\_hmoduleDll, \_T("DLLFunc2")));
	m\_funcDLLFunc3	= reinterpret\_cast<p2DLLFunc1>(GetProcAddress(m\_hmoduleDll, \_T("DLLFunc3")));
	
	if (	NULL != m\_funcDLLFunc1	&&
		NULL != m\_funcDLLFunc2	&&
		NULL != m\_funcDLLFunc3)
	{ // SUCCESS: All wrapped functions found in DLL
		bResult = true;
	}
	else
	{ // FAILURE: Could not find one or more wrapped functions
		::FreeLibrary(m\_hmoduleDll);
	}
}

return bResult;

}

However, when lots of functions are being wrapped the above method is a bit tedious and can be error prone. Instead, I would like to do it with a lookup table, like so

bool CDLLWrapper::LoadDLL()
{
struct MyLUT {
TCHAR* tcFuncName;
funcDLLFunc;
int iFunctionSignatureType;
}; // struct MyLUT {

static	MyLUT	arrWrappedFuncs\[\]	=	{	\_T("DLLFunc1"),		m\_funcDLLFunc1,	0
							\_T("DLLFunc2"),		m\_funcDLLFunc2,	1
							\_T("DLLFunc3"),		m\_funcDLLFunc3,	0
}; // static	MyLUT	arrWrappedFuncs\[\]

const	int	iNUM\_WRAPPED\_FUNCTIONS	= sizeof(arrWrappedFuncs) / sizeof(MyLUT);

bool	bResult = false;

m\_hmoduleDll = ::LoadLibrary(\_T("DLLName"));
if (NULL != m\_hmoduleDll)
{ // DLL loaded successfully. Now get addresses of all functions we are supporting
	bResult = true;	// Assume success
	for (int i = 0; i < iNUM\_WRAPPED\_FUNCTIONS; ++i)
	{
		switch(arrWrappedFuncs\[i\].iFunctionSignatureType)
		{
			case 0:
			{
				arrWrappedFuncs\[i\].funcDLLFunc	= reinterpret\_cast<p2DLLFunc1>(GetProcAddress(m\_hmoduleDll, arrWrappedFuncs\[i\].tcFuncName));				
			}
			break;
			
			case 1:
			{

Thanks for helping me to think it through. In summary then: :: only needs to be placed in front of Win API functions when they are called from within class member functions, otherwise it's not necessary (ie. when calling a Win API function outside of a class).

modified on Tuesday, December 9, 2008 2:41 AM

The problem with not putting the :: in front of Win API's when calling them is that you could introduce a subtle bug; the code would compile OK with you thinking your code was calling the Win API, but instead would actually be calling the member function by mistake.

Is this safe ? int iOffset = 192; LARGE_INTEGER liOffset = { static_cast<LONGLONG>(iOffset) }; or should the following be used instead ? int iOffset = 192; LARGE_INTEGER liOffset; liOffset.QuadPart = static_cast<LONGLONG>(iOffset);