Just a conceptual question...

[Hotice]

I know that you could get a username with:

TCHAR name[UNLEN + 1];
DWORD size = UNLEN + 1;
if (GetUserName((TCHAR *)name, &size)
{
//some stuff here...
} //end if 

but, in this sense, DWORD simply becomes a 32-bit integer. In this sense, could I minimize my dependence on other files by simply declaring const unsigned size = 257;? UNLEN is just a macro defined in Lmcons.h (and we all know that the only thing macros do is code replacement!)
EDIT: For some reason, GetUserName EXPECTS a DWORD (and nothing else:( )

[freddie1]

What you are asking isn't all that unusual in that a lot of us thought that way when we were starting out. In other words, "Why make it complicated when it could be simpler?" Unfortunately, if you tried to do what you are describing with every library you wish to use, you wouldn't get very far until you realized you were attempting to do a practically impossible task. Not theoretically impossible mind you, just practically impossible. Best bet is to just include through include files everything you need so your code compiles. Unused material won't add to code size, as the compiler and linker system will optimize everything out which isn't being used.

In the particular case of GetUserName(), the 2nd parameter is an [in, out] parameter (Do you know what that means?), and will receive the size you are allocating for the 1st parameter, and return through itself the actual written size.

[Hotice]

So what you are saying is that size will recieve the four bytes that will be the username? If so, question answered. Thanks, man!

[S G H]

Yeah, it does.
But, let DWORD be a unsigned long.
On a 64-bit machine, is a unsigned long still 32-bits wide?

[freddie1]

So what you are saying is that size will recieve the four bytes that will be the username?

No, as the documentation states, upon calling this function, you tell Windows the size in TCHARs of the buffer you are going to provide to the OS to return the string. In the first parameter you provide the address of this buffer. The OS then determines the length of the string it is going to copy to name. If the buffer is equal to or larger than the full string, it will copy to your buffer the whole string. If the buffer you have provided isn't big enough (as specified by the info you passed in in size), then it won't over-run the buffer, and will truncate the string so as to prevent memory corruption beyond the provided buffer. In any case, it will return in the size parameter, the length actually copied. It is really very, very, very, simple. And the documentation is very, very, clear ...

lpnSize [in, out]

On input, this variable specifies the size of the lpBuffer buffer, in TCHARs. On output, the variable receives the number of TCHARs copied to the buffer, including the terminating null character.

This is one of the most common 'design patterns' used by the Windows Api. For example, check out GetCurrentDirectory(). First parameter is a pointer to the string buffer. Second parameter an [in, out] where you tell windows how much room you've made, and Windows tells you back how much it used of what you supposedly gave it. And if you lie, bad things will happen. You'll be punished. Or at least you used to be punished. In Windows 95 you got the blue screen of death. In Windows 2000, an ignorant message telling you you've corrupted memory at such an such an address, and your program will be shut down. In Windows XP a SLIGHT APOLOGY. And in Windows 7 a sincere apology, with an attempt made to make up for it happening. Microsoft mellowing out with age.

I don't believe any of the standard non-pointer C/C++/Api data types exapand with 64 bit EssGeEich. All the pointer data types do though, even opaque pointers such as Window Handles of one type and another. All last week I played with 64 bit Windows. Was fun. I've little to no need of it though.

[S G H]

Idk if it's in the standard but I heard an integer's size is commonly a pointer's size, and a long integer must not be of less size of an integer.

[freddie1]

Just last week I installed GNU's new 64 bit compiler ...

http://mingw-w64.sourceforge.net/

... and compiled this as x64 ...


C:\Code\CodeBlks\SizeOf>g++ SizeOf.cpp -o SizeOf.exe -mconsole -Os -s

#include "Windows.h"
#include <cstdio>

int main(void)
{
 printf("sizeof(int)      = %d\n",sizeof(int));
 printf("sizeof(long)     = %d\n",sizeof(long));
 printf("sizeof(DWORD)    = %d\n",sizeof(DWORD));
 printf("sizeof(HWND)     = %d\n",sizeof(HWND));
 printf("sizeof(DWORD32)  = %d\n",sizeof(DWORD32));
 printf("sizeof(DWORD64)  = %d\n",sizeof(DWORD64));
 getchar();

 return 0;
}

And here's the output. Read 'em and weep ...

C:\Code\CodeBlks\SizeOf>SizeOf.exe
sizeof(int)      = 4
sizeof(long)     = 4
sizeof(DWORD)    = 4
sizeof(HWND)     = 8
sizeof(DWORD32)  = 4
sizeof(DWORD64)  = 8

[S G H]

I think I was wrong. But, anyways, a pointer to a DWORD is requested, and in case any change (very impossible) happens, you should get ready to use DWORDs and not unsigned longs.

I'd mention HWND's are currently pointers to __HWND, so that's the size of a pointer.