Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsVB SyntaxEnterprise DevelopmentDatabase AccessControlsCOMWin APICrystal ReportDeploymentGeneralGeneral 2
Related Topics
VB.NET / ASP.NETMS SQL ServerMS AccessOther Database ProductsMore Topics ...

VB Forum / General / July 2009



Tip: Looking for answers? Try searching our database.

Remote-Desktop "client/ server"

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Hans Achim - 01 Jul 2009 20:25 GMT
Hello!

I have had a query from a customer who is at a larger company where the
workers work on client computers, not on a single computer but with a
remote server.

The problem is that my application doesn't want to send keys (my app is
something like a text macro sender which can send text to other
applications using SendInput) in this scenario.

I searched the internet and found out that "WinSta0" is the only desktop
that can receive such input in a client/ server scenario and that my app
has to somehow create itself in "WinSta0", but I have no idea how I
should do that in VB6.

Regards
Hans
CY - 01 Jul 2009 21:59 GMT
Ehh... google.. http://www.vbaccelerator.com/home/VB/Tips/SendKeys_using_the_API/article.asp

//CY
Nobody - 01 Jul 2009 22:15 GMT
> Hello!
>
[quoted text clipped - 10 lines]
> has to somehow create itself in "WinSta0", but I have no idea how I should
> do that in VB6.

I think the problem is much simpler, or lets say, not related to windows
stations, unless your app is running as a service. When two applications are
running as the same user in the same session, they can talk to each other
fine. In Windows 2000+, you can't hook(SetWindowsHookEx) other processes
that are started using a different user, but you can still send messages(or
input). In Vista and after, you can't send messages to a process that is
running with higher privileges.

If each user is running a copy of your app, then all is well because both
apps(Yours and the one you are sending input to) are running as the same
user. If you have your app as a service, then it's complicated. If your app
auto starts from HKLM\...\Run key in the registry, Windows auto starts your
app for each logged on user(at the time of logon), and both apps again are
running as the same user, and all is well.

To better answer your questions, please answer the following:

What type of application you have developed? Standard EXE? ActiveX EXE?

How the application is started? By the user? By the Run key in the registry?

Is it running as a service?

What OS the customer is using?

I am doing something similar by using SendMessage(), and I have no problems
in Windows 2000/2003/2008 Servers.
Hans Achim - 02 Jul 2009 04:32 GMT
Hello!
My application is a standard exe. My application is started be the user
(however I'm not sure if the application that the user wants to send key
strokes to is also started by himself or by somebody with higher
privileges). My app is not running as a service.
They are using Windows Server 2003 in that company.
They say that running the MS OSk.exe doesn't have this problem, but my
app does.
Their IT guys are saying something like "We think that your app is only
using the operating system while the Microsoft OSK.exe does a transition".

In my opinion, it's because I am somehow not using WinSta0, but I could
be entirely wrong about it because I don't have any experience in this
area, and I am lacking any testing environment.

Regards
Hans
Nobody - 02 Jul 2009 16:49 GMT
> Hello!
> My application is a standard exe. My application is started be the user
[quoted text clipped - 10 lines]
> entirely wrong about it because I don't have any experience in this area,
> and I am lacking any testing environment.

This is not related to WinSta0. Actually, if you manage to run it in
WinSta0, your app will not appear or stops working. When a user starts an
application, it runs on the same window station as other programs used by
the same user on the same session, so there is no need to worry about window
stations.

To verify that both processes are running as the same user, ask the user to
start Task Manager, go to Processes tab, and enable "Show processes from all
users". Also, make sure that "User Name" and "Session ID" columns are
visible by going to View-->Select Columns. If both processes have the same
Session ID and User Name, then the problem is in how you are using
SendInput. Even though you have it working on your setup, you maybe not
doing everything necessary to use it. Please post the code you are using
around SendInput, including any translations you are doing

Also, you can download Windows 2008 Server from here:

http://www.microsoft.com/windowsserver2008/en/us/trial-software.aspx

You don't need another PC if you have one with more than 512MB of RAM. You
can use the free Virtual PC:

http://www.microsoft.com/windows/virtual-pc/

Virtual PC 2007 requires XP minimum. If you have Windows 2000, use Virtual
PC 2004.
Hans Achim - 02 Jul 2009 23:07 GMT
Then how come that OSK.exe from MS does this implicitly at startup?

I debugged it, it goes something like this (sorry, it's a really rough
mixture of C++, VB.NET and VB6):

        hWinSta = GetProcessWindowStation()
        lHandleToWindowsStation0 = OpenWindowStationW("WinSta0", 0,
MAXIMUM_ALLOWED)
        m_lHandleToWindowsStation0 = lHandleToWindowsStation0

        If lHandleToWindowsStation0 Then
            SetProcessWindowStation(lHandleToWindowsStation0)
        End If
     TrySetDesktopThread(foovar1,foovar2)
    End If
'-------------------------------------------------------------------------------------------------

public function TrySetDesktopThread(byval uVar1,Byval uVar2)
     Dim result As Integer
     Dim v3 As IntPtr
     Dim v4 As IntPtr
     Dim v5 As UInteger
     Dim v6 As IntPtr
     Dim v7 As Integer
     Dim Dest As Char
     Dim hDesktop As IntPtr
     Dim pvInfo As SByte
     Dim nLengthNeeded As UInteger

     v7 = dword_101ED2C
     Dest = a2
     *CType(a1, _DWORD) = 0
     v3 = OpenInputDesktop(0, 0, H2000000u)
     hDesktop = v3
     If v3 OrElse v4 Then
        GetUserObjectInformationW(hDesktop, 2, pvInfo, H12Cu, nLengthNeeded)
        If Dest Then
         Dest = (const Char *) And pvInfo
        End If
        If wcsicmp((const Char *) And pvInfo, "Default") Then
         If wcsicmp((const Char *) And pvInfo, "Winlogon") Then
            If wcsicmp((const Char *) And pvInfo, "screen-saver") Then
             *CType(a1, _DWORD) = (wcsicmp((const Char *) And pvInfo,
"Display.Cpl Desktop") <> 0) + 4
            Else
             *CType(a1, _DWORD) = 2
            End If
         Else
            *CType(a1, _DWORD) = 3
         End If
        Else
         *CType(a1, _DWORD) = 1
        End If
        v5 = GetCurrentThreadId()
        v6 = GetThreadDesktop(v5)
        CloseDesktop(v6)
        SetThreadDesktop(hDesktop)
        result = 1
     Else
        result = 0
     End If
     Return result
Nobody - 03 Jul 2009 01:11 GMT
> Then how come that OSK.exe from MS does this implicitly at startup?
>
> I debugged it, it goes something like this (sorry, it's a really rough
> mixture of C++, VB.NET and VB6):

I am not sure how you get that information, and what were you debugging.
However, it seems to be the typical code used by services to interact with a
user, which you don't need. See "Interacting with the User in a Service" in
MSDN Library.

If you want to know if both your app and the target process are running as
the same user, call these functions for each process:

' Get User SID
OpenProcessToken(TOKEN_QUERY)
GetTokenInformation(TOKEN_USER)
NtCompareTokens()
EqualSid()
CloseHandle()

' Get Window Station name
GetProcessWindowStation()
GetUserObjectInformation(UOI_NAME)
CloseHandle()

' Get Desktop name
GetThreadDesktop()
GetUserObjectInformation(UOI_NAME)
CloseHandle()

' Get SessionId
ProcessIdToSessionId()

So if all the above are the same, then you don't need the code that you
posted, and the problem is related to SendInput, and how the target
application handles it. For instance, make sure that GetForegroundWindow()
returns the correct window.
Hans Achim - 03 Jul 2009 22:23 GMT
Thanks... the user is not too co-operative, and I am not sure if I could
re-arrange the companies hardware structure here with VMWare.
Hans Achim - 06 Jul 2009 15:00 GMT
Hello!

I have started my exe via CreateProcess, and it works fine now, except
that Ctrl+a, Ctrl+c are not recognize in the remote session while all
other characters work fine.

Also I have to use the UNICODE flag, else nothing will be sent.
Do you know this behaviour?

I am using Karl Peterson's SendInput:
http://vb.mvps.org/samples/SendInput

Regards,
Achim
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.