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

Print This Post Print This Post

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:

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: 1561, size: 40.21 kB)

 

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 rdp_480x800_but_is_480x640

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 rdp_480x800_fit2screen_but_is_480x664

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

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 rdp_480x800_fit2screen_and_Fullscreen

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

rdp_480x800_Fullscreen_device_screen rdp_480x800_Fullscreen

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

6 Comments

  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:

    Hi,

    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?

    Cheers,
    Daniel

  4. Sam says:

    Hi
    I was really quite hopeful about this – but maybe I misunderstood
    Running WM6.5.3. on HD2 (480×800 res) and trying to connect to Windows server 2008.

    Before using your version, the RD display was missing the RH 1″ or so. (About 6 chars in old DOS terms) Something is not quite right (and so your fix may not be appropriate) because the server reports the client (HD2) has having a display of 480×696 (and not 480×800 which the device says it has)

    Anyway, I tried your version (created SysCache, copied in the program and ran it directly from there) but all it did was create a small (I’m guessing around or 200×350) window in the bottom RH corner of the screen. I guess maybe I have to put it in the Windows director for it to work?

    I rebooted and tried again (in case this is necessary to get it to use the cache version) but no difference.

  5. josef says:

    Hello sam

    I am sorry, but I do not understand what you are writing.

    The patched version is used to make the OS see the app (wpctsc.exe) as not hi-res aware and the Terminal Server gets a lower res reported by the client. You can check the res reported to the server on the Terminal Server.

    The rest of my article is written about bad-designed host applications that do not scale but have a fixed size. If a host app is designed for QVGA and you connect with a (hi-res aware) VGA client, the app’s display will be small (a quarter of the VGA screen). When you connect with a hi-res aware client from a device with 480×800, the display will get more worse with host applications that have a fixed screen size programmed.

    You should re-design the host app to dynamically resize itself to the available screen.

    Further on the options Full Screen and Fit Remote Desktop to Screen will vary the layout.

    If possible add some screen shots of the device’s screen and the TS client information.

    ~Josef

Leave a Reply