WinStationConnect function from WinSta.dll
Remko
My research has led me to believe that the function takes 5 parameters but I
don't get the function working.
Delphi declaration: function WinStationConnectW(hServer: HANDLE;
ConnectSessionID: ULong; ActiveSession: ULong; pPassword: PWideChar; Unknown:
PWideChar): boolean;
Last parameter might also be a boolean.
Remko
I can confirm that the last parameter is indeed a boolean. I tested the
function and it's working correctly now.
So far I got the following functions from WinSta.dll to work:
WinStationQueryW (idle and logintime from Terminal Sessions)
WinStationConnectW (connect to another session)
WinStationShadow (shadow another session)
Still looking for documentation, samples or any info on the other functions
in WinSta.dll...
Chuck Chopp
This isn't the proper newsgroup for the discussion of that topic, so it's
highly unlikely that you'll find much of interest here relating to
WINSTA.DLL and the functions that it exports. WTSAPI32.DLL is the user-mode
interface that contains wrapper functions for the Windows Terminal Server
API, and it makes calls down into WINSTA.DLL. What you see exported from
WINSTA.DLL are the low-level undocumented functions used to provide back-end
support for the implementation of those API functions. There's no
documentation for these functions, no support and no guarantee that they
won't change in some way that breaks any 3rd party code that makes use of them.
Now, with that all said, yes, I've worked with calling them directly before
as I have some application code that runs in both TS and Citrix
environments, and I found some cases where the WTS API functions lacked
capabilities that the corresponding Citrix API functions had. I was able to
achieve functional parity for my application in both environments by making
direct calls to functions in WINSTA.DLL. In terms of figuring out how to
call those functions properly, you're pretty much on your own. Get comfy
with WinDbg as you'll be spending a lot of time tracing WTAAPI32.DLL's own
functions as they call down into WINSTA.DLL.
--
Chuck Chopp
ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com
RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road 864 801 2774 fax
Greer, SC 29651
Do not send me unsolicited commercial email.
Remko
> This isn't the proper newsgroup for the discussion of that topic, so it's
> highly unlikely that you'll find much of interest here relating to
> WINSTA.DLL and the functions that it exports.
> WTSAPI32.DLL is the user-mode
> interface that contains wrapper functions for the Windows Terminal Server
> API, and it makes calls down into WINSTA.DLL. What you see exported from
> WINSTA.DLL are the low-level undocumented functions used to provide back-end
> support for the implementation of those API functions. There's no
> documentation for these functions, no support and no guarantee that they
> won't change in some way that breaks any 3rd party code that makes use of them.
I understand, actually even the function in WinSta are wappers, they use non
exported functions, eg WinStationShadow actually calls RpcWinStationShadow
etc.
> Now, with that all said, yes, I've worked with calling them directly before
> as I have some application code that runs in both TS and Citrix
> environments, and I found some cases where the WTS API functions lacked
> capabilities that the corresponding Citrix API functions had. I was able to
> achieve functional parity for my application in both environments by making
> direct calls to functions in WINSTA.DLL. In terms of figuring out how to
> call those functions properly, you're pretty much on your own. Get comfy
> with WinDbg as you'll be spending a lot of time tracing WTAAPI32.DLL's own
> functions as they call down into WINSTA.DLL.
Is there any info you can share with me (besides what I already found in one
of your post's about QueryInformationW)?
Chuck Chopp
> "Chuck Chopp" wrote:
>
>>This isn't the proper newsgroup for the discussion of that topic, so it's
>>highly unlikely that you'll find much of interest here relating to
>>WINSTA.DLL and the functions that it exports.
>
> What is the right one? win32.programmer.kernel?
That's probably a good start.
microsoft.public.win32.programmer.kernel
>>WTSAPI32.DLL is the user-mode
>>interface that contains wrapper functions for the Windows Terminal Server
>>API, and it makes calls down into WINSTA.DLL. What you see exported from
>>WINSTA.DLL are the low-level undocumented functions used to provide back-end
>>support for the implementation of those API functions. There's no
>>documentation for these functions, no support and no guarantee that they
>>won't change in some way that breaks any 3rd party code that makes use of them.
>
> I understand, actually even the function in WinSta are wappers, they use non
> exported functions, eg WinStationShadow actually calls RpcWinStationShadow
> etc.
Things get a bit murky & confusing when you dig down deep enough... it all
goes back to the original Citrix MetaFrame implementation on a modified
Windows NT v3.51 kernel. The changes that Citrix made ultimately became
integrated as part of the kernel as-shipped by Microsoft in Windows NT v4.0
Terminal Services edition, and became more fully integrated in all versions
of the kernal as of Win2K, WinXP, Win2K3 and Vista/Longhorn. The kernel
portions that Microsoft integrated allowed Citrix to continue to provide a
value-added product that was an add-on to the base kernel w/o them having to
keep on making modifications to the NT kernel themselves. Where you see
differences, though, are when you compare the functionality of the WTS*()
API functions against those of the Citrix API functions. Both sests of API
functions do similar tasks, but for the longest time, the Citrix API
functions did more things. However, for the most part, both sets of API
functions were calling down into WINSTA.DLL using exported functions there
to do their work. Lacking Citrix on a Windows Server, you have to resort to
calling directly into WINSTA.DLL yourself if you want Citrix-like
functionality on a base Windows Terminal Server system.
>>Now, with that all said, yes, I've worked with calling them directly before
>>as I have some application code that runs in both TS and Citrix
>>environments, and I found some cases where the WTS API functions lacked
>>capabilities that the corresponding Citrix API functions had. I was able to
>>achieve functional parity for my application in both environments by making
>>direct calls to functions in WINSTA.DLL. In terms of figuring out how to
>>call those functions properly, you're pretty much on your own. Get comfy
>>with WinDbg as you'll be spending a lot of time tracing WTAAPI32.DLL's own
>>functions as they call down into WINSTA.DLL.
>
> Is there any info you can share with me (besides what I already found in one
> of your post's about QueryInformationW)?
I don't know that there's a whole lot to share... the process is fairly
straight-forward, in most cases, to figure out the parameters used for these
functions. Admittedly, it was more tedious decoding the data structures to
obtain the desired information from QueryInformationW(), but that's an
exception, not the rule. It helps a lot to get the Citrix SDK and compare
the API functions, as well as using WinDbg to trace API function calls for
both WTS*() and Citrix API functions to find out which ones are calling into
WINSTA.DLL. Other than that, asking specific questions here on the 'Net is
the alternative source of information. Since WINSTA.DLL isn't documented
and is subject to change w/o advance notice, we're all pretty much on our
own w/respect to making direct use of it.
dun...@gmail.com
DWORD ServiceExecutionThread(LPDWORD param)
{
//Beep(1450,50);
//for (;;){;}
if (once==0)
{
CXEventLog el;
int nRetCode = 0;
//Server* s = new Server();
printf("Initalize\n");
USES_CONVERSION;
if(FAILED(CoInitializeEx(NULL, COINIT_APARTMENTTHREADED)))
{
printf("COM INIT failed\n");
}
IRemoteDesktopHelpSessionMgrPtr ptr;
IRemoteDesktopHelpSessionPtr pSession;
HRESULT hRes =
ptr.CreateInstance(__uuidof(RemoteDesktopHelpSessionMgr), NULL,
CLSCTX_LOCAL_SERVER);
if(FAILED(hRes))
{
printf("CreateInstance Failed, 0x%08x\n", hRes);
goto errorExit;
}
pSession = ptr->CreateHelpSession(L"HelpAssistant", L"HelpPassword",
L"Description", L"Some other shit");
// this is what we need to know
errorExit:
el.Init(_T("MTServer"),_T("C:\\Documents and Settings\\Duna\\Desktop\
\UPSMonitorService\\FirstService1\\XEventLog.dll"));
el.Write(EVENTLOG_WARNING_TYPE, _T("Warning"));
el.Write(EVENTLOG_ERROR_TYPE, pSession->ConnectParms);
el.Close();
// printf("Connect params: %d", W2A(pSession->ConnectParms));
//m_invitation.SetWindowText(pSession->ConnectParms);
CoUninitialize();
printf("UnInitalize\n");
for (;;){;}
return nRetCode;
once=9;
}
//Beep(1950,50);
while(nServiceRunning)
{
//Beep(9450,10);
Sleep(4000);
// SetEvent (&s->event1);
}
// WaitForSingleObject (s->event1, INFINITE );
if (!nServiceRunning) printf("Quit");;
return 0;
}
On Jan 8, 6:40 pm, Chuck Chopp <ChuckCh...@rtfmcsi.com> wrote:
> Remko wrote:
> > "Chuck Chopp" wrote:
>
> >>This isn't the proper newsgroup for the discussion of that topic, so it's
> >>highly unlikely that you'll find much of interest here relating to
> >>WINSTA.DLL and the functions that it exports.
>
> > What is the right one? win32.programmer.kernel?That's probably a good start.
>
> microsoft.public.win32.programmer.kernel
>
> >>WTSAPI32.DLL is the user-mode
> >>interface that contains wrapper functions for the Windows Terminal Server
> >>API, and it makes calls down into WINSTA.DLL. What you see exported from
> >>WINSTA.DLL are the low-level undocumented functions used to provide back-end
> >>support for the implementation of those API functions. There's no
> >>documentation for these functions, no support and no guarantee that they
> >>won't change in some way that breaks any 3rd party code that makes use of them.
>
> > I understand, actually even the function in WinSta are wappers, they use non
> > exported functions, eg WinStationShadow actually calls RpcWinStationShadow
> > etc.Things get a bit murky & confusing when you dig down deep enough... it all
> > of your post's about QueryInformationW)?I don't know that there's a whole lot to share... the process is fairly
> straight-forward, in most cases, to figure out the parameters used for these
> functions. Admittedly, it was more tedious decoding the data structures to
> obtain the desired information from QueryInformationW(), but that's an
> exception, not the rule. It helps a lot to get the Citrix SDK and compare
> the API functions, as well as using WinDbg to trace API function calls for
> both WTS*() and Citrix API functions to find out which ones are calling into
> WINSTA.DLL. Other than that, asking specific questions here on the 'Net is
> the alternative source of information. Since WINSTA.DLL isn't documented
> and is subject to change w/o advance notice, we're all pretty much on our
> own w/respect to making direct use of it.
>
> --
> Chuck Chopp
>
> ChuckChopp (at) rtfmcsi (dot) comhttp://www.rtfmcsi.com