on the wish of the one or other user I extended the RDP AutoLogin code and we now reached level 4.

The new code simply has only one extension, it supports the color depth selection. Also the color depth and other settings are visible on the dialog of Remote Desktop Mobile, the settings itself are done via the Default.rdp file. But you are right, RDP_AutoLogin also controls some of the dialog items directly.

Source code

...
Domain:s:
ColorDepthID:i:3
ScreenStyle:i:0
DesktopWidth:i:640
DesktopHeight:i:480
UserName:s:rdesktop
...
ServerName:s:192.168.128.5
SavePassword:i:1
...

The color depth setting supports two modes, 8 Bit with 256b colors (ColorDepthID:i:1) and 16 Bit with ~65000 colors (ColorDepthID:i:3).

Source code

REGEDIT4
 
[HKEY_LOCAL_MACHINE\Software\RDP_autologin]
"FitToScreen"="1"
"FullScreen"="1"
"Status"="connecting..."
"Save Password"="1"
"Domain"=""
"Password"="Intermec+2004"
"Username"="rdesktop"
"Computer"="192.168.0.130"
"DesktopWidth"=640
"DesktopHeight"=480
"startOnExit"="\\rdp_keepBusy.exe"
"execargs"="noRDPstart"
"UseMouseClick"="0"	//added with version 3 to switch between mouse and keyboard simulation
"ColorDepth"=1		//added with version 4 to enable switching between 8 and 16 Bit colors

The code changes are small. Some code addition to read the value from the registry and some to write the rdp file:

Source code

void readReg(){
...
        //ColorDepth new with version 4
        if(RegReadDword(L"ColorDepth", &dwTemp) == 0)
            dwColorDepth=dwTemp;
...
}
void writeRDP(){
...
			else if(wcsstr(rdpLines[c].line, L"ColorDepthID")!=NULL){
				wsprintf(szTemp, rdpLines[c].line, dwColorDepth);  //3=HighColor(16Bit) or 1=(8Bit) color
			}
...
}

Additionally I have added a new project to the solution to enable to set all the settings not only via the registry but using a GUI application. RDP_Autologin_Settings is born:

As you see, there is also a small file browser integrated. The default OpenFile dialog of Compact Framework does not allow you to browse all directories, but only “\My Documents”.

RDP AutoLogin Settings Editor (exe): DOWNLOAD:RDP AutoLogin Settings editor - (Hits: 33, size: 10.45 kB)
source (Visual Studio 2008 WM5 SDK project): DOWNLOAD:RDP AutoLogin Settings editor Source Code - (Hits: 28, size: 21.23 kB)

RDP_AutoLogin (exe): DOWNLOAD:RDP AutoLogin Executable - (Hits: 30, size: 6.78 kB)
source (Visual Studio 2008 WM5 SDK project): DOWNLOAD:RDP AutoLogin Source Code - (Hits: 26, size: 56.85 kB)

RDP_KeepBusy (exe): DOWNLOAD:RDP KeepBusy (executable) - (Hits: 24, size: 3.17 kB)
RDP_KeepBusy (vs2008 WM5 SDK project): DOWNLOAD:RDP KeepBusy Source Code - (Hits: 27, size: 12.92 kB)

Have fun

Josef

Bookmark It

there are now more and more full VGA rugged devices coming. And some customers are still using Remote Desktop Mobile to run there application on the small screens. Unfortunately some of the coders use application screen layouts hard coded to QVGA (240×320). Now with a VGA capable Windows Mobile device they get weird screens on the device.

The client (Remote Desktop Mobile) sends the server information about there screen sizes. As a VGA device can display 480×640 pixels, the hard coded 240×320 applications only use a quarter of the screen. The texts are very small and more or less unreadable.

The terminal server gets client resolution information:

Unscaled (left) VGA display of a QVGA application (with “Fit remote desktop to screen” NOT CHECKED) and on the right the same application with internal autoadjust to workscreen size:

As you can see in the right image above this line, it is no problem to show a form designed for QVGA to scale nice with the use of some code (as using WorkingArea.Width/Height and a table layout). But in the left image you see what happens to hard coded designed applications.

If you have the source code, you should change the design of your dialogs to be resolution aware, so it scales fine for QVGA and VGA (and whatever comes next).

If you do not have the code or can not change the application, you have to tell Windows Mobile to behave like the Remote Desktop Mobile application is NOT HI_RES_AWARE. That means you need to hack the exe file. I took a look at the Windows Mobile 6.5.3 wpctsc.exe (the Remote Desktop Mobile executable) and did not find the HI_RES_AWARE resource, so the OS must use the other mark to see that wpctsc.exe is HI_RES_AWARE. And yes, indeed, the PE header shows that wpctsc.exe has a subystem version of 5.2. With some PEInfo tool, you can hack the major subsystem version and just change it from 5 to 4.

When you start a application that is not HI_RES_AWARE, the Windows Mobile 6.5.3 OS will scale all UI elements for the application and the app will look fine and not only fill a quarter of the VGA screen. After changing the major subsystem version number, the first thing you will notice is the more coarse display of the menu items in the menu bar:

Left is the HI_RES_AWARE original app and on the right we have the hacked one (take a closer look ate the ellipses around the menu items).

When you use the hacked, not HI_RES_AWARE, application, the terminal server will see the client supports QVGA only (Client Resolution) and your hard coded application screens will look the same as on a QVGA capable device:

The attached wpctsc.exe is the hacked one with a subsystem major version number of 4 instead of 5. Use this on your Windows Mobile 6.5.3 device at your own risk. The file is not signed as the device I work with are not requiring signed exe files. The change to the exe file (after I dumped the OS files to my PC using itsutils) was simply done with mgeeky’s PEinfo code at GitHub.

If you can not copy the file on top of the original one on the device (\Windows\wpctsc.exe), you can use the syscache feature. Copy the wpctsc.exe to \Windows\System\SysCache directory and reboot the device. If the directory does not exist you just have to create it manually.

If you want to get the old wpctsc.exe back, just delete the file you copied. As the original wpctsc.exe is part of the OS (a XIP file), you can not delete the file but you can copy a file with the same name on top of it. When you delete this copied file, the original is back in place. So, there is no harm in testinng the exe.

Bookmark It

as MS does not change it, the Remote Desktop Mobile application still disconnects a session after 10 minutes idle time.

Although there is a solution for Windows Mobile 6.1 (http://www.hjgode.de/wp/2009/09/18/wm6-1-remote-desktop-client-disconnects-after-10-minutes/) based on the posting of Rafael (MS Support), this will not work with Windows Embedded Handheld (WM6.5).

The TSSHELLWND will not react on mouse_event and you have to replace the calls by SendMessage and send the WM_MOUSEMOVE to the Terminal Server Input window.

The attached application will do so but it will start only on Int*rm*c devices. It sends a mouse_move message all 4 minutes to the TS input window and so the idle timer will not timeout.

If you ever need to stop RDMKeepbusy from running in the background, you will need StopKeepBusy which is part of the executable download.

For visual control, RDMKeepbusy shows a small blinking line in the task bar:
green = Remote Desktop window found and input window is active
yellow = Remote Desktop window found, but no input window active
red = Remote Desktop window not found

Bookmark It

Intro and Background

Some times ago I found that message of Jay Sorg and retrieved a copy of his code for a native rdesktop win32 version. I played a little and got the code compile with Visual Studio 2005 with the Windows Mobile SDK.

I tried to implement windows clipboard support to enhance the transfer of texts between the client and server, but unfortunately I was not successful yet. Hopefully someone jumps in and helps enhancing the code and adds some features.

Rdesktop is open source and you can go with the wince implementation here, but if it does not work for you, you have either change the code yourself (and publish it) or find someone that is able to do for you.

There is a template uiports/xxxwin.c in the actual rdesktop source you can use as a starter to compile the actual rdesktop version for windows mobile if you manage to get all the dependencies to work. If you success, forget this post and go with this version (maybe you leave me a note?).

Why another Remote Desktop/Terminal Server Client?

The Windows Mobile Remote Desktop Client (or Remote Desktop Mobile, RDM) lacks some useful features available in the Windows CE version or the Desktop Windows version:

• No automated login
• No kiosk mode
• Function keys are not sent to server
• …

The first item is essential if you like to start a Terminal Server session without user intervention.

The second item is important for using RDM in a production environment.

The third item is useful to run applications on the Terminal Server (TS) that use Function keys.

Commercial RDM

There are some commercial remote desktop clients available for windows mobile:

• Mochasoft RDP client
  “Windows 200x servers and terminal servers are not supported, as to a Microsoft patent license.”
• zaDesktop
  This is currently in an early state.
• RDP Finster
  Not really clear where this comes from.

I assume some of the commercials are either using mstscax or rdesktop code. Some time ago MS published the RDP documentation. Maybe the commercial apps did start from there. Going with the TSC COM library mststcax would be great, but who has the doc for this? For desktop PCs it is documented but not for windows mobile. If someone has a doc to this leave me a note. Then we can start to write a TSC around this library.

There are also some rewritten TSC for the desktop not using mstscax. One is called ProperJavaRDP and maybe a good starting point to rewrite a dotnet based native TSC for windows mobile.

Usage of the free opensource rdesktop-ce

You can start winrdesktop on windows mobile either with an ini file or with command line arguments:

Sample winrdesktop.ini

(place either in program dir or in root)

[main]
server=192.168.128.5
port=3389
username=YourUserName
password=YourPassword
bpp=16
geometry=1024x768
#fullscreen

server : provide the server IP or DNS host name
port : provide the port to use for RDP, usually 3389
username : provide the login user name for the terminal client session
password : provide the password of the user
bpp : define the bits per pixel to be used (number of colors per pixel)
geometry : define the size of the remote desktop window width x height An application to be used on windows mobile devices should match the screen size of the device. For example 240×320 (QVGA). Otherwise the user has to scroll the window to get access to all of the remote screen.
fullscreen : currently not supported

UPDATE 23. nov 2010:

fullscreen now supported. Fullscreen will switch rdesktop to not show a caption and no menu bar. If geometry matches the device’s screen size, there will also be no scrollbars.

This screenshot was taken of an app I wrote running on a Windows 2003 server of a QVGA device with following winrdesktop.ini:

[main]
server=192.168.128.5
port=3389
username=rdesktop
password=rdesktop
bpp=16
geometry=240x320
fullscreen

Rdesktop usage

Command line

WinRDesktop [-g widthxheight] [-t port] [-a bpp]
    [-f] [-u username] [-p password] [-d domain]
    [-s shell] [-c working directory] [-n host name]
    server-name-or-ip

options are the same as in winrdesktop.ini plus:

-d domain : specify the domain of the user login
-s shell : define a shell to use on TSC
-c working directory : define a working directory for the session
-n host name : specify the host name to use for the client (visible on TSC)

Restrictions of current code

See googlecode issues for a list of known restrictions.

Downloads

Windows Mobile Executable and INI sample file at googlecode
Source code: see googlecode

Bookmark It

• screen_width and height for WriteRDP()
• read FitToScreen from reg in readReg()
• check for already running process of startOnExit in startTSC(). Although I think check for running a process multiple times should be done in the target process.

Update 16. may 2011: converted code for VS2008(windows mobile 6 sdk), see Downloads at bottom

UPDATE 23 june 2010: new registry option to switch between MouseClick and Keyboard simulation:

REGEDIT4
[HKEY_LOCAL_MACHINE\Software\RDP_autologin]
"FitToScreen"="1"
"FullScreen"="1"
"Status"="connecting..."
"Save Password"="1"
"Domain"=""
"Password"="Intermec+2004"
"Username"="rdesktop"
"Computer"="192.168.0.130"
"DesktopWidth"=640
"DesktopHeight"=480
"startOnExit"="\rdp_keepBusy.exe"
"execargs"="noRDPstart"
"UseMouseClick"="0"    //added with version 3 to switch between mouse and keyboard simulation

Some days ago I published my RDP_Autologin code: RDP_Autologin

As there were some screen metrics hardcoded and more and more devices come with a VGA screen the hardcoded QVGA values will not match. So I extended the first version and implemented some additional logic and settings.

First, the emulated screen tap has been adjusted to depend on the device screen width and height. For that I included the HIRES_AWARE resource to get the real screen size.

...
	DWORD dX = (0xFFFF / iScreenWidth) * (80); // changed from 13 to width=240, 1/3=80
	DWORD dY = (0xFFFF / iScreenHeight) * (iScreenHeight - 13);
...
BOOL getScreenSize(){
	int iScreenX = GetSystemMetrics(SM_CXSCREEN);
	int iScreenY = GetSystemMetrics(SM_CYSCREEN);
	DEBUGMSG(1, (L"\ngetScreenSize: x=%i, y=%i\n", iScreenX, iScreenY));
	if(iScreenX>0)
		iScreenWidth=iScreenX;
	if(iScreenY>0)
		iScreenHeight=iScreenY;
	if(iScreenX+iScreenY > 0){
		_itow(iScreenWidth, sScreenWidth, 10);
		_itow(iScreenHeight, sScreenHeight, 10);
		return TRUE;
	}
	else
		return FALSE;
}
...

The rdp file defaults for desktop width and height will also be calculated but you can set the default to use via the registry.

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\RDP_autologin]
"startOnExit"="\Windows\rdp_keepbusy.exe" "DesktopHeight"=dword:000001E0 "DesktopWidth"=dword:00000280
"Computer"="192.168.0.2"
"FitToScreen"="0"
"FullScreen"="0"
"Username"="rdesktop"
"Password"="xxxx"
"Domain"=""
"Save Password"="1"
"Status"="connecting..."

As you can see, I added a line where you can specify an application that will be started at the end of the autoconnect process: startOnExit.

Downloads:

evc4 source code: DOWNLOAD:rdp autologin 2 evc4 source code - (Hits: 379, size: 113.37 KB)

Armv4i executable: DOWNLOAD:rdp autologin 2 Armv4i executable - (Hits: 404, size: 6.47 KB)

NEW: Version 3 adds new option to let the app use MouseClick or Keyboard Simulation

Update 18. nov 2011: DOWNLOAD:Updated rdp_auologin (screen_width/height) - (Hits: 46, size: 159.78 kB)

Exe File (ArmV4i) DOWNLOAD:RDP Autologin Version 3 - New version with Mouse or Keyboard simulation switch in registry: UseMouseClick=DWORD 0/1 (Hits: 335, size: 6.56 kB)

eVC4 source code DOWNLOAD:RDP AutoLogin version 3 source code - eVC4 source code for my RDP_AutoLogin version 3 (Hits: 200, size: 131.73 kB)

NEW: VS2008 code and exe DOWNLOAD:RDPautologin Visual Studio 2008 code (and Release\\exe) - (Hits: 135, size: 144.01 kB)

Update 4.march 2011: Please also see http://blogs.msdn.com/b/raffael/archive/2009/09/11/remote-desktop-mobile-rdp-client-disconnects-after-10-minutes-of-inactivity.aspx about idle timeout

Bookmark It

As you may know, Remote Desktop Mobile (RDM) does not support auto-login. But sometimes you may want a user does not change settings and is directly connected to a Terminal Server. Ruggedized devices are often used in warehouses and the IT structure uses a terminal server to gather data and manage goods. Although I think Windows Mobile is not the right OS for such barcode scanner devices, you may have no choose and have to use a handheld computer with Windows Mobile instead one that uses Windows CE. The RDM or Terminal Service Client provided with Windows CE devices is much more flexible and can be configured by the OEM to enable you to auto-login into a Terminla Server (TS).

OK, the challenge was to automate the startup and login of RDM on a Windows Mobile 6.1 device. I started using embedded Visual C++ 4.0 although this is outdated by VS2005 and VS2008.

The idea was to launch the exe, fill in the values and click the Connect bar.

Finding the connect dialog window

Normally, on desktop windows, windows and there childs are located in there own tree (see desktop PC spy++ screenshot). On WM61 I found, that the RDM window (class=”TSSHELLWND”) and the Connect dialog (class=”Dialog”) are located side by side below the desktop window (see cespy screenshot). This makes it hard to find the right dialog, especially as the Connect Dialog does not have a unique window title (window text). The windows can be identified as belonging together by there processID.

RDM Connect Dialog

Filling the fields

Knowing the right window I was able to set the text entries by knowing there controlIDs (dialogs use ctrlIDs for easier access of the data, see scanTscDialog() in tscDialog.cpp). So the tool I did can fill in all connection details using SetWindowText().

Execute the Connect

The fields are filled with the connection details and now I needed a way to simulate a click onto the connect button (which is a menu in reality) to let the dialog execute a connect. I tried several approaches, the best is to use keyb_event although it works also by sending the TSC window the WM_USER message that is posted by the menu click. I found this WM_USER message within messages of cespy as I tapped on [Connect].

 //Solution three, best solution, ensure you use the scancode value too! AFAIK the scancode for F1 is always 0x70
keybd_event(VK_F1, 0x70, 0, 0);
 Sleep(30);
 keybd_event(VK_F1, 0x70, KEYEVENTF_KEYUP, 0);

I was unable to send TSSHELLWND nor the Dialog a click onto the menu option [Connect]. The menu seems to be not owned by either of these two visible windows. The menu bar looks like owned by the desktop window.

Sending the SoftKey1 (F1) was also unsuccessfull for window handles of TSSHELLWND and the Connect Dialog.

The pitfalls

Everything seems to work OK, but sometimes the tool was unable to fill the fields and execute the connect. I did search several hours and then I found, that the registry and a file is involved in the connect.

The tool always failed to autoconnect after the first clean boot. So I did a snapshot with the famous free SSNAP by “S-K tools” and found the changes that caused a manualy connect to be successfull.

Registry changes

First, the registry will get be changed, if you manually connect. As I did not like to have my tool to emulate a user typing into the fields using keybd_event, I added code, that does the same changes to the registry (see writeMRU() function in code). There are some more changes in registry, but fortunately I did not have to implement these too (see comments in “tscDialog.cpp”).

RDP file default.rdp

When you fill the connect dialog and then press [Connect] RDM will save your values in a file \Windows\default.rdp. You may know, that rdp files are commonly used on desktop windows to save/load Remote Desktop Session connection data. Yes, WM6.1 does use a similar technique.

The tool had to provide a default.rdp with the data of the connection settings. So I wrote a function to create and write this file from scratch on every start (see writeRDP() in tsc_dialog.cpp and rdp_file.h). As options, like “FullScreen” or “Fit to Screen” are also controlled by the rdp file, I was able to control these settings by code.

Conclusion

So far the tool works. Dont download if you dont like spaghetti. The code is written as grown.

Usage

Write the correct values for the connection to the registry

[HKEY_LOCAL_MACHINE\Software\RDP_autologin]
"FitToScreen"="1"
"FullScreen"="1"
"Status"="connecting..."
"Save Password"="1"
"Domain"=""
"Password"="xxxxxxxxxx"
"Username"="rdesktop"
"Computer"="192.168.0.130"

Then simply start the tool. First it will terminate a running instance of RDM. Then it starts a new instance and starts to fill the fields and do the connect.

Warranty

No warranty, code is provided as is. Hopefully it is usefull for the one or other.

Changes

Some values are hard coded, ie the control IDs used. These IDs may be different on other devices or within other RDM releases. So far the code works on my testing device. If you need to change the control IDs you may use the scanTscDialog() function to get the actual codes listed in the debug window.

Have fun!

Bookmark It