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

Show quote Hide quote 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.

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

Show quote Hide quote 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.

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

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.

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.

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

Removing too many hyphens
Printing contents of a picture box
Package & Deployment
Perplexing Problem - Need Help
PowerBASIC
String Memory Recovery
Copy & Move files
Checkbox - how to clear without triggering click event
Date and regional settings problem
Type comparison