There are now more and more full VGA rugged devices coming. And some customers are still using Remote Desktop Mobile to run their 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 their 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 cannot 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 subsystem 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 an 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:
On the left is the HI_RES_AWARE original app and on the right, we have the hacked one (take a closer look at 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 cannot 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 cannot 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 testing the EXE.
