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

Print This Post Print This Post


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.

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  reshacker_2

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.

DOWNLOAD:wpctsc.exe with major subsystem version number = 4 - (Hits: 1444, size: 40.21 kB)


  1. [...] So I did some googling and found a fix via this blog. [...]

  2. Josef says:

    If you have the C/C++ source code and use VS2008 for compile/link then you may use this trick to fake WM6 and let it scale your app:

    The default linking of VS2008 uses a SUBSYTEM major version of 5, which tells the WM OS that it is a HIRES_AWARE app :-(

    By adding an ‘advanced’ linker command line option of “/SUBSYSTEM:WINDOWSCE,4.2″ you tell the VS2008 linker to embed a major subsystem number of 4 which indicates the WM OS that the app is not HIRES_AWARE and must be scaled :-)

    Ensure you do not have the CEUX / HIRES_AWARE resource in your exe!

  3. Daniel says:


    I am trying to do the solution above. The problem I have is that it won’t let me create the syscache directory under windows\system. Says “the new folder could not be created in this location”. Anyone else had this problem and know of a fix?


Leave a Reply