🚀 go-pugleaf

WTSQueryUserToken is dealt with in another reply.

As you most likely already know, most of the Windows headers are 
modifications of ones provided by Microsoft (they copyrighted the API and 
have sued companies who independently developed their own headers).  I can 
confirm what you found from what is on my machine.  The winwlx.h header does 
not have an extern "C" guard.  However the wtsapi32.h header does have it.

WTSGetActiveConsoleSessionId is, as mentioned before, found in import32.lib, 
a library which the IDE includes by default in a build.  If you are building 
from the command line then check that import32.lib is included in the list 
of libraries used in the link phase.

There is nothing odd, questionable or wrong with your explicit linking of 
WTSGetActiveConsoleSessionId.  What you did merely duplicates what the 
Windows loader does when implicitly linking via an import library.  In fact 
it might actually speed loading of your gina dll if the function is called a 
lot because the loader doesn't have to fix up the function address at each 
point where WTSGetActiveConsoleSessionId is called.

.  Ed

> Mike Collins wrote in message
> news:480758e5@newsgroups.borland.com...
>
> Hay Ed thanks for the pointer, I actually resolved it by dynamically 
> loading it, like this:
>
>   typedef DWORD (WINAPI *WTSGETACTIVECONSOLESESSIONID)(VOID);
>   WTSGETACTIVECONSOLESESSIONID lpfnWTSGetActiveConsoleSessionId = NULL;
>   lpfnWTSGetActiveConsoleSessionId = 
> (WTSGETACTIVECONSOLESESSIONID)GetProcAddress(GetModuleHandle("kernel32.dll"), 
> "WTSGetActiveConsoleSessionId");
>
> The project that i'm calling it from is a gina and i had to do some 
> playing around to get the dll to export the named functions correctly i.e.
> extern "C"
> {
>   #include <winwlx.h>
> };
>
> otherwise winlogon would not load it correctly - maybe this is the cause. 
> However, I still stuck with the WTSQueryUserToken issue.  Any thoughts?