- Windows CE Programming - http://www.hjgode.de/wp -

Remote Desktop Mobile on VGA devices: QVGA applications do not scale well

Hi

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:

[1] 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:

[2]  [3]  [4]

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 [5]. 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:

[6]   [7]

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:

[8]   [9]

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 [10].

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.

Update 18. june 2013:

Here is an alternative way for changing the subsystem version number

Using ResHacker and EditBin

Depending on the exe file you have to remove the CEUX/HIRES_AWARE resource from the exe file and/or change the subsystem version number.
The below will not work for .NET applications as these are executed by the .NET runtime.

Use EditBin to down the major subsystem version number below 5.0

First start your vcvarsall.bat normally located at “C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC”. This will setup the search path to let cmd find editbin and runtimes.

To lower or change the subsystem version number use following command:

editbin.exe yourexefilename /SUBSYSTEM:WINDOWS,4.20

this will return:

Microsoft (R) COFF/PE Editor Version 11.00.50727.1
Copyright (C) Microsoft Corporation.  All rights reserved.

LINK : warning LNK4241: invalid subsystem version number 4.20

Do not care, the version number is changed.

Test your patched exe on a device. If it shows strange you may have to use the following editbin command:

editbin.exe yourexefilename /SUBSYSTEM:WINDOWSCE,4.20

Test your patched exe again. This time it should work OK.

Use ResHacker to remove CEUX

Start ResHacker and then look for the CEUX resource entry. Double click down to the deepest branch of CEUX and then right click the binary entry and select [Delete Resource].

reshacker_1 [11]  reshacker_2 [12]

Repeat that if the CEUX has another branch. When all branches are deleted, the CEUX entry will disappear.
Save your new exe file with a different name and test it on a device.


wpctsc.exe with major subsystem version number = 4 (1836 downloads)

 

UPDATE 21. may 2014

HI-RES annoyances with Windows Mobile Remote Desktop application

Now you got a device with a larger resolution than 480×640 but MS Remote Desktop does not really care.

rdp_480x800_but_is_480x640_device_screen [13] rdp_480x800_but_is_480x640 [14]

Although the device has a resolution of 480×800, wpctsc.exe connects with a resolution of 640×480! The upper and lower area shows a white blank screen. Neither Fullscreen nor Fit Remote Desktop was selected in Options of Remote Desktop Mobile (RDM).

Now, can we get better? Yes, a bit:

rdp_480x800_fit2screen_but_is_480x664_device_screen [15] rdp_480x800_fit2screen_but_is_480x664 [16]

Again the Terminal Server (here a 2003 one) does not get a request for the correct resolution. The resolution is only 480×664, normally it should be 800-72 (menubar)-36 (HHTaskBar)=692. Again we get a small blank area, this time only at the bottom.

The last test is with the options Fullscreen and Fit Remote desktop to screen set.

rdm_options [17]

Now we get the full resolution (480×800) of the device reported on the terminal server and there is no blank area:

rdp_480x800_fit2screen_and_Fullscreen_device_screen [18] rdp_480x800_fit2screen_and_Fullscreen [19]

And last but not better: option “Fullscreen” set and “Fit remote desktop” not set.

rdp_480x800_Fullscreen_device_screen [20] rdp_480x800_Fullscreen [21]

Now we get 640×480 reported on TS and nice blank areas in RDM.