Access your desktop PC from your Pocket PC! (Part III)

(Continued from HERE.)

Auto-overriding System / Advanced / Performance / Settings / Visual Effects settings for speed: this group scrutinizes whether the given remote controller disables advanced visual effects like font smoothing etc. You can, for all applications, en/disable these effects; a decent remote application should disable them all to, in cases, greatly reduce bandwidth usage upon logging in. It's certainly possible: see for example what happens when the, in this respect, best pcAnywhere 12 client logs into a desktop that has all the effects enabled.

Disables wallpaper?: one of the most important activities a remote controller should do to conserve bandwidth is disabling the desktop wallpaper to, in cases, reduce bandwidth usage with tens or even hundreds of kilobytes.

Disables font smoothing (see an example here) / Cleartype (IE7: Tools / Internet Options / Advanced/ Multimedia / Always use Cleartype for HTML)?: font smoothing, which is a system-level setting, and ClearType, which is "only" used by applications using the HTML renderer component of Internet Explorer (Outlook Express, Outlook etc., in addition to Internet Explorer itself) . Unfortunately, the latter is disabled by only RDP; the former is disabled by more remote applications.

Disables "Show window contents while dragging"?: should you often drag remote application windows from one place to another with the "Show window contents while dragging" checkbox enabled in System / Advanced / Performance / Settings / Visual Effects, your bandwidth usage can dramatically increase with protocols / remote apps that don't automatically disable this. Unfortunately, even the RDP protocol is sensitive to this - and it doesn't automatically disable window dragging, which can cause a lot of problems because of the increased bandwidth usage.

Disables smooth IE scrolling?: if you enable Internet Explorer smooth scrolling in IE7, Tools / Internet Options / Advanced / Browsing / Use smooth scrolling, does the application disable it? Unfortunately, none of them does this, with the consequences visible in the "Sensitive to smooth scrolling and other animations?" test.

Connection model? group: in here, I've elaborated on the connection model the tested remote applications use.

In general, there are two main types, which has already been explained in the first section of this application: apps using direct connection where you must pass the remote client the direct Internet address of your remote desktop and apps that rely on a central dispatcher server hosted by the developer.

In the first test case, I give an overview of the model; with direct connections, I've also listed the port numbers to be forwarded, should you need to access these systems behind a firewall, where you can still ask the firewall to route the given ports to your remote PC.

LAN (internet-less)?: can you access these systems without your local area network (LAN) being connected to the Internet (for example, via BT PAN, Wi-Fi p2p or, with some special applications, even non-TCP/IP-based, that is, infrared / serial / parallel port connections) ? As can clearly be seen, it's only the three "true" Web-based applications (apps where you must use the main dispatcher to log in) that you must have a working Internet connection for, at least, the initial login.

Usable through ActiveSync'ed PDA's to access the same desktop the PDA is connected to? (With direct connections using local IP’s (192.168.55.100 with pre-WM5 and 169.254.2.2 with WM5 - see this for more info on the latter) : many Pocket PC users would like to remote control their desktop computers via USB, via ActiveSync. Fortunately, all remote control solutions support this - after all, an ActiveSync USB connection is a full TCP/IP connection; if you enter the above IP's as the server address, you'll be able to connect to the desktop. Also, if you have Internet access, you'll be able to use Web-based applications to access your desktop too from a USB-connected Pocket PC.

Note that there are specialized (not “generic†remote desktop access-oriented) Pocket PC applications which, unlike with the real “usability†(which isn't much more than just a W?BIC! (Why? Because I Can!) geek toy) of the "remote control via USB" solution, do add a lot of functionality to desktop computers: Innobec SideWindow, PPC Tablet Remote Control Suite by A&A Computer Services etc, and the multimedia and scripting controller applications (for example, Pebbles Remote Commander, Salling Clicker, PuppetMaster). I'll elaborate on these tools in a later roundup.

Able to log in when the user is not / no user is logged in (can you register the server as a Windows service?)?: a decent remote controller application should also (automatically or configurably) register itself as a system service so that it's started even without any Windows user's logging in. This is of tremendous importance with all password/login-protected desktop PC's. You shouldn't rely on not rebooting your desktop either to avoid the need for this: there will inevitably be for example critical XP updates that do reboot the PC. That is, if your desktop Windows you'd like to remotely access doesn't log in automatically, make double sure you configure your remote controller server to be started as a service. Fortunately, all of them can be configured this way - most of them even defaults to being started as a service.

Dynamic IP announcement support?: Should your remote desktop be connected to the Internet via a, say, DSL line, your IP address will most probably change, in general, once a day. With built-in dynamic IP announcement support (in which, z2 is excellent), you can very easily announce your IP every, say, 15 minutes. You will, then, be able to access this IP stored on a central server and accordingly set the address to connect to in the remote client.

Note that you will still be able to use your remote desktop on a dynamic IP with remote control software not supporting dynamic IP announcement because there are a lot of third-party software (not related to remote controlling) that do the trick. However, the easiest is to have support built-in.

Callback support through firewalls (HTTP(S) gateway)? If there is a central one, speed?: Battling the problem of dynamic IP's is a piece of cake with third-party dynamic IP accouncer applications and even more so with built-in support for this.

Firewalls and NAT'ed (Network Address Translate) networks, on the other hand, are much more complicated.

If you're still allowed to define port forwarding (please see the list of ports to be forwarded in the first row of this group), you can still connect to firewalled machines even when you only run a remote controller application not having a central login server on the Internet (and maintaining a constant HTTP(S) connection).

If, on the other hand, you can't use port forwarding (which is very common with, say, public Wi-Fi or mobile phone based networks), the only way to access an, in this way, NAT'ed desktop remotely is using a constant HTTP(S) connection. The Web-based three "true" applications support this; so does, with a callback trick, z2. With apps that lack this functionality, you will want to use third-party applications like Barracuda HTTPS tunnel or the gateway solutions officially offered for some enterprise-targeted applications like NetOp Remote Control 9.0 and pcAnywhere 12.0.

In HTTP(S) gateway mode, if it uses the provider’s central server, does it try to use direct connections when there can be also direct, non-HTTPS connections between the client and the server for speed and to make users confident the server can’t eavesdrop into the conversation?: if you do need to communicate via a central HTTP server (which is the case with the three true Web-based services), do you have the chance of speeding up your connection if your remotely controlled desktop PC isn't NAT'ed.

As can clearly be seen, with the highly recommended LogMeIn, direct connections are automatically used when they're allowed. They also greatly speed up the connection. If you need to access / search PIM stuff and emails remotely, the highly recommended I'm InTouch also supports this - but you will need to manually enable it (see the included screenshots). Finally, GoToMyPC doesn't allow for direct connections at all - not that it'd cause any problem (the central server of GoToMyPC is blazingly fast).

I've tested the support for this with two tests. First, I've run my remotely accessed desktop in a totally NAT'ed environment - that is, in an environment that makes it impossible to make direct connections to the desktop PC. In this setup, I've checked with 'netstat' whether I have any kind of direct (one that isn't routed through the software developer's central server) callback connections to my (non-NAT'ed) client PC. (I haven't had any with the three true Web-based apps.)

Then, I've reconfigured my local network to completely expose the remotely controlled PC; that is, I've relocated it from a NAT'ed network to have a direct Internet connection. I've re-run netstat to see whether I had a direct connection then.

Service group: in here, I've elaborated on the memory usage (see my remarks on the LLE memory usage!) and the easiness of stopping / restarting / enabling / disabling these services. Note that, while LLE not only occupies a LOT of precious RAM memory but also has some 2…10% constant CPU usage, no other remote server applications behave this bad. This is why there is no "CPU usage" row - they were all under 1% (that is, impossible to measure).

Memory usage: as can be seen, none of the server applications are memory hogs. Most of them consume 12 or less Megabytes; VNC servers being the best in this respect (they only consume 3.5 Mbytes at most). The only exception is the otherwise, PIM / e-mail access-wise, excellent I'm InTouch, which has a memory usage of about 36 Mbyte. You may want to keep this in mind if you, for example, only have 256 Mbytes of RAM in your XP box - there, every Megabyte counts.

Easy to stop/ restart?: seeing how hard is it to stop the CrossTec app (and start GoToMyPC once you kill it) I've also included this test in the chart. In here, I explain how the server-side listening services can be en/disabled and/or started / stopped.

Misc group: everything not categorizable under the other categories.

Built-in landscape switching support? (They’re all compatible with OS-level Landscape modes; here, I only list explicit ability to switch to there under pre-WM2003SE OS’es): as has already been pointed out, all the remote controller applications are landscape-ready. Some of them, in addition, also support in-program switching to Landscape mode, which will surely be welcome by pre-WM2003SE users.

Note that while the two Mochasoft applications are capable of doing this, you may still not want to use this feature with them because doing this will really slow down the rendering (and increase the CPU usage, which will also mean faster battery depletion). This also means if you have a device with WM2003SE or a later operating system, use its built-in Landscape support, not that of the Mochasoft apps.

Dedicated chat support, using a simple textual protocol to communicate to greatly simplify chatting between the remote user and the local terminal user?: some applications support the use of dedicated chat windows, which aren't (necessarily) part of the desktop. With these chat windows, you the remote user can communicate with the user sitting in front of the remote desktop using dedicated chat windows. Supporting these is advantageous in two respects:

1. they are far more responsive than simply, say, using a, say, file edit window / Word document to communicate because the characters you enter, as you do it in a local (non-remote) text input component, are echoed right back to you.
2. When two users try to chat via, say, an open Word document, surely "race for controlling the cursor" events happen.

Server / Client install method: in here, I've elaborated on how the server-side (on the remote desktop) and the client-side (on the Pocket PC) component need to be installed, which will be very important for particularly newbie Pocket PC users not wanting to manually install / configure anything.

With web-based applications (including RemotelyAnywhere in this case), everything is easy: both the server and the client are auto-installed. With RDP-based applications, the server component is already installed on desktop Windows XP Pro PC's and you only need to install the client (if it's not already available - with the built-in TS client, it's already there if you prefer using it). With everything else, you must install both the server and the client by hand.

Where to navigate to to log in?: in here, I've elaborated on where the client must be directed to (what kind of address it must be given) or, if it's a Web-based remote controlling solution, where the Pocket Internet Explorer browser on the client must be directed to.

Overall rendering speed: here, I've elaborated on the overall rendering speed. Note that the results assume you don't use any kind of smooth scrolling or other techniques; otherwise, for example, the RDP4-based Mocha client wouldn't have received a "Good".

Double monitors (extended desktops)?: many desktop Windows users extend their desktops to multiple monitors in Display / Settings / Extend my desktop onto this monitor. In here, I've elaborated on how the remote controllers support extended desktops. If you plan using VNC, checking out the results will be particularly beneficial.

Full screen support?: as you probably have noticed, the taskbar (the bar at the top) and the command bar (the one at the bottom) take up a lot of precious screen estate on the Pocket PC, particularly in Landscape mode. In here, I've elaborated on whether the applications support hiding these bars. In a nutshell, weaker applications don't do this; better ones do. The latter (for example, z2, the four Web-based applications, .NET Viewer and PT PO) let for (almost) completely hiding all GUI components. Please consult the mini-tutorials in this row to find out how you can do this.

Copy-paste between client and remote desktop (clipboard synchronization): Clipboard synchronization is a really important feature all remote desktop controllers should support. Unfortunately, few do.

In-program disconnect (except for manual disconnect from inside Start menu – that is, the session)?: some remote controller apps are very dumb and don't even let for in-application disconnecting / exiting. In cases (when, to reduce bandwidth consumption, it's essential to disconnect as quickly as possible and shutting down the application with, for example, an external task manager application takes a lot of precious time), this may be problem. This is why I've also included this test in the chart.

Server-side configuration capabilities: as a final test in the Misc group, I've elaborated on what you can configure on the server, showing example screenshots of everything. If you do browse them, you'll get a picture of the server's capabilities I haven't otherwise elaborated on in this roundup.

Accessing other resources on the remote desktop group: in here, I've elaborated on accessing files (for file transfer between the remote desktop and the local Pocket PC), e-mails and Personal Information Management (PIM) stuff like calendar / contacts and, finally, monitoring the remote desktop without logging in and starting, for example, the task manager in there. These functionalities are all very important.

Accessing other resources on the remote desktop: File transfer between client and remote desktop: File transfer is of extreme importance between the client and the remote desktop. Unfortunately, few applications support it and those that do and are Web-based (I'm InTouch and LogMeIn; unfortunately, GoToMyPC doesn't support file transfer on the Pocket PC) currently only support downloading from the desktop to the client. The I'm InTouch folks announced they will also implement uploading, though.

Of the non-Web-based applications, only PT PO and z2 support file transfer. With all the other solutions, you'll need to choose third-party solutions:

1. Installing an FTP server on your desktop computer and accessing it via an FTP client (including most Web browsers, if you only plan to fetch files from your desktop but not upload anything in there) on your Pocket PC. Please read this article for more information on the currently available FTP clients and this article on the downloading capabilities and speed of current Pocket PC Web browsers.
2. If the above way isn't the one to go on (because you either don't want to struggle with another server application on your desktop PC, find it unsafe or it's so badly firewalled / NAT'ed that you couldn’t directly connect to it), mail the file from your remote desktop (after logging in there) to yourself if you also have direct (for example POP3 / IMAP / Exchange) mail access on your Pocket PC. Then, just fetch the file from your mailbox. This is, of course, much more complicated a task than using a built-in file transfer utility in a remote controller application - or, for that matter, a local FTP client on the Pocket PC. Also, it'll result in a really increased bandwidth usage, not only because of the need to manually log in to the server and mail the file to yourself, but also because of the ASCII conversion, effectively adding some 30-40% to the original size of the attached file. This means in these cases look for a solution with built-in file transfer right from the beginning.

Client-side remote / monitoring tools?: ever wanted to avoid having to, say, use the Task Manager in a full remote session? Ever wanted to avoid remote registry editing in a remote session because of the amount of, say, registry tree navigation involved, which results in greatly slowed down operation when done remotely? With RemotelyAnywhere, it's possible. The local HTML interface offered this application, which is compatible with even the dumbest Pocket Internet Explorer, offers you the chance of doing all this stuff locally, without having to log in to a real remote session and accessing these monitoring / registry editing tools in there.

Access to other PIM resources?: should you want to access and, what is more, search your mail or other personal calendar / contacts / tasks data stored in your Outlook or Outlook Express, you'll want to take a look at I'm InTouch. It has really excellent PIM access capabilities.

Note that you can do the same with actually logging in to your remote desktop and doing the same PIM stuff in there via Outlook (Express), but it's, of course, a much more awkward solution with orders of magnitude more bandwidth usage - remotely accessing / using for example Outlook will always be much harder than through a Pocket PC-optimized, locally running interface.

User interaction group: in here, I've elaborated on how more than one user can elaborate on the same remote desktop. In the first case, I've listed whether the user sitting in front of the desktop computer can interact with the remotely connecting one and, in the second case, I've elaborated on whether more than one remote user can use the same desktop using the same remote control application. (With different servers, it's possible to do this, even if the given server wouldn't allow multiple logins. Then, however, you're faced with the need of setting up more than one server, which isn't necessarily what you want to do.)

Anyone knowing RDP-based solutions knows both these painfully lack this functionality. Therefore, you'll need to go for an alternative solution if you do need these. All non-RDP-based solutions support co-accessing the same desktop with the physically in front of it sitting user; more than one remote user, on the other hand, is a bit more complicated question.

Login group: in this group, I've elaborated on whether the particular remote controller solution remembers login names and even passwords. When you remote control more than one desktop with the same program, I also scrutinized whether the given application supports storing the IP and, preferably, the login / password of more than one controlled desktop computer.

I highly recommend the mini-tutorials in here on creating favorites for Web-based applications (they are of really GREAT help if you don't want to enter your login / password all the time) and saving the remote desktop address / password pair in PT PO.

Windows accounts? That is, can you log in using any existing Windows user login / password pair (you don't need to come up with a new username and/or password but can use your familiar Windows one)?: this shows whether you need to come up with a password (and, probably, a new username) for logging in, or, you can use your Windows username / password.

Multimedia: in here, I've listed specially multimedia-related issues.

Sound redirection from the desktop to the client (and, possibly, vice versa): you may also want to listen to what the remote desktop is playing. This has happened at least to me several times while (not directly - that is, not via applications like WMRecorder) recording some MP3 streams or the input from the line input (a local FM radio) into a local file. In special cases, you may want to listen to the remote desktop user himself, speaking into the microphone of the desktop computer (and making sure microphone input is enabled even in playback mode).

Unfortunately, while, for example, the desktop (including Linux with all its mobile incarnations running on, for example, the Sharp Zaurus) and the WindowsCE.NET Handheld PC RDP clients both support sound redirection, the one included in PPC2k2…WM5 doesn't. Unfortunately, while using this client, you can't even start applications using the sound output. That is, for example in one of the above-mentioned cases (recording a stream with transcoding) can in no way be done via TSC. You must use some other remote control application if you still want to do this.

Note that two enterprise-targeted applications (CrossTec and Danware) support bidirectional voice chat (especially for remote maintenance & help) in the desktop version. Their Pocket PC version, unfortunately, doesn't support this.

Possible to start sound apps on desktop?: see the explanation of the previous test.

Video playback?: some users have reported inability to play back videos (to at least see some frames - of course, using 8-bit color depth and possibly slow lines, videos can easily become ugly slideshows) with some remote controllers. This is why I've also introduced this test. Fortunately, I've encountered no problems in any of my tests - all clients are capable of transferring videos to the client. This is in strong contrast with, say, Pocket PC remote controllers unable to show for example the HTC Camera screen (see this for more info on the latter).

Special client-side input group: in this group, I've examined how the tested applications handle more elaborate input scenarios: double and right clicks, tap-and-hold events, what special keys (not available on the local, default, Pocket PC Software Input Panels (SIP's)) they are able to send over to the desktop etc.

Right clicks: most applications are capable of communicating right clicks. The only notable exception is the H/PC client running on the Pocket PC.

Double left clicks: they have no problems with quickly clicking the screen in rapid succession to emulate double left clicks (to, for example, quickly highlight words, sentences and/or paragraphs of text). Some of them even support sending them from a menu.

Tap-and-hold (like text moving in Word): With several of the remote controller apps (most importantly, RDP-based clients), a simple, quick tap on the screen equals with a left click and tap-and-holding a right click; with some others (most importantly, the Web-based applications belong to this category) you click a left/right state toggler icon to quickly switch between issuing left and right clicks when you tap the screen.

When you use an application (for example, the built-in TSC) belonging to the first category, you can't use tap-and-hold events, unlike with a real mouse. In this test, I've tested (with the help of Microsoft Word - I've checked whether the Move text - where to? message appears in the left bottom corner) whether this is possible with the given client. (Sorry for the language of the example screenshots (I have a Finnish-language MS Office on my notebook): “Mihin siirrytään?†is Where to move? in Finnish.))

Special keys: as has been already mentioned in the group introduction, SIP's lack many special keys available on real desktop PC keyboards: Alt, function keys, Windows; Insert; Escape and some special, well-known combinations of these; for example Alt-F4, Alt-Tab and Ctrl-Alt-Del. In here, I've listed what special keys can be sent to the remote desktop. As can be seen, the built-in TSC in Windows Mobile doesn't support sending any special keys. Again, note that you can still access the remote desktop Task Manager by tap-and-holding, that is, right-clicking the taskbar; therefore, the lack of the Ctrl-Alt-Del support isn’t that disastrous. It's only the otherwise, because of RDP4, not recommended Mocha RDP client that is considerably better in this respect. Web-based applications weren't particularly good in this respect either; some of them only supports Ctrl-Alt-Del but not, say, function keys. The absolute killer is PT PO. Note that with PT PO, it's a bit complicated to bring up these special keys - see the mini-tutorial in the next, national character test row on how this must be accomplished.

National characters entered on SIP: if you only enter English characters on your keyboard, you will hardly notice the lack of national character support. If you do need to enter these characters, you should base your choice also on the given product's being able to send over accented / national chars. Unfortunately, not all of them do - for example, one of the most recommended apps, LogMeIn, doesn't.

In these cases, you will want to cast a glance at XDA-Developer forum member Mokus‘ remote desktop-side macro app. It will require you to enter a, say, dot before all your accented chars. See this for more info.

Is it possible to “hover†the cursor from the client without USB / external mouse / hx4700 touchpad? (The latter works with everything): you may also want to position the mouse cursor without actually sending a click. Unfortunately, none of the controllers support this - except for PT PO when you use hardware buttons for the two mouse buttons.

A quick remark about the alternative technologies: if you happen to have an HP iPAQ hx4700 (the only one Pocket PC with a touchpad) and you enable the touchpad mode in the Nav Point Mode applet, you will be able to position the cursor anywhere (to, for example, see the cursor position-based tooltips, animations etc), in most remote controller apps. Note that, with LogMeIn (this may also mean RemotelyAnywhere because of the same GUI engine), any kind of viewport scrolling (which is especially easy and fast with the hx4700 in cursor mode) will stop this functionality of the cursor to work (because of the changed coordinates). The best way to make it work again is sending a mouse click anywhere (that is, you don't need to log in again).

I've also made some tests with an external USB mouse on the Pocket Loox 720. As opposed to the hx4700 touchpad, I've had severe problems with this setup: the local cursor coordinates didn't match the remote ones and, therefore, the mouse was useless. This, however, doesn't necessarily mean no USB or external (for example Bluetooth) mouse will ever work as intended: I may just have been unlucky with my PL720.

Server-side tooltips displayed? : you may well know tooltip windows - they are widely used in desktop Windows. In this case, I've explicitly tested whether the given remote controller application is able to display these on the client side. As can be seen, not all of them do. Also note my extensive remarks on z2 RemotePC.

Hardware button shortcuts: in here, I've elaborated on what you can use the hardware buttons of the Pocket PC for. Unfortunately, as can be seen, it's only with PT PO and z2 RemotePC that you can make use of them; with the other clients, their functionality remains the same as in the operating system itself.

Cursor tracking?: finally, I've tested whether remote controllers are dynamically able to follow the cursor and the text input caret. Doing this is highly useful particularly with QVGA clients. Unfortunately, only pcAnywhere and z2 is capable of this; the former tracks the mouse (useful when the remote user wants to see what the desktop user does) and the second finds the text caret (useful when you enter text and it scrolls out of the window but you don't want to waste too much time on finding it manually with the scrollbars).

Resolution, zoom, color group: in this group, I've elaborated on issues like whether the remote desktop is switched to a given resolution upon connection, whether the client is able to do any zooming and the like.

Remote desktop resolution?: is the remote desktop resized when the remote client connects to it or does it stay at the original size? In most cases, the latter is preferable, particularly with clients that also allow for sharing the screen with the local user of the remote desktop.

It's only RDP that resizes the remote desktop: the built-in TSC to VGA and the Mocha client to SVGA size. All other solutions keep it at its original size.

Forcing the remote desktop size to the available view – on the server? ("Limit size of server desktop to fit on this screen?") (1:1 pixels and no client-size rescaling): in here, I've listed whether the given controller can be made to force the remote desktop side to fit into the available client screen estate without the need for any kind of zooming or scrolling. As can clearly be seen, it'ss only the built-in TSC and GotoMyPC that are able to do this. Remember, however, not to enable this feature on QVGA devices - only on VGA ones!

Rescaling on the client side so that the desktop image is visible (and editable) on the client w/o scrolling?: TSC has always lacked "scale (zoom out) to the available screen estate" functionality; the other RDP-based client, the Mocha client, already knows this; as with most the non-RDP-based alternatives. This functionality is especially useful, particularly on VGA devices, to be instantly able to navigate on the full desktop screen without the need for any scrolling.

Client-side zooming?: in here, I've listed whether the client is able to zoom and if it is, what zoom steps are available. (Note that z2 is able to zoom in/out with not only icons but also hardware buttons, as has already been stated in the "Hardware button shortcuts" row.)

Remote desktop resolution settable?: some applications (LogMeIn and RemotelyAnywhere) are able to dynamically set the remote desktop resolution (even using Portrait resolutions if you prefer staying in that mode to avoid for example eyestrain because of lower-quality screens being not very eye-friendly in Landscape mode - see for example this for more info) from inside the applications. Note that the standard resolution (re)setting (Settings / Control Panel / Display / Settings) works with most other applications too, except for, of course, RDP-based ones; the worst that can happen is that the client (automatically) reconnects (as with the case with, say, PT PO). This also means the local remote desktop user may change the desktop resolution any time, even with hardware keyboard-based shortcuts (for example, the one on UXGA notebooks to quickly switch to SVGA mode - and back); the clients, in general, will automatically notice and apply the changes.

Scrolling on page: if you don't stick to scaled full-desktop modes (and, especially on low-resolution QVGA devices, this will be the case most of the time), you will end up having to scroll a lot.

Traditionally, scrollbars have always been used by Windows Mobile applications to scroll (pan) around. They, however, do take a lot of precious screen estate, even with the well-known "thin scrollbar" registry hacks. This is why some (most importantly, three of the four web-based applications and PT PO) offers an alternative method of scrolling: tap-and-holding the screen on one of the four edges. Some other solutions (for example PT PO) offer "minimaps" and some others (the two Mochasoft apps) stylus-based quick (this solution is considerably faster than the tap-and-hold method) dragging. TSC, in addition to scrollbars, also offers five "quick positioning" icons on the command bar to quickly move to one of the corners or the center of the desktop.

Color depth: finally, the color depth. As can be seen, as far as RDP is concerned, TSC in PPC2k2…WM5 only supports 8-bit color depth; so does Mocha. Better VNC-based solutions and three of the four Web-based solutions also support better (with more colors) color depth modes; so does one of the most recommended titles, z2 RemotePC.

3. Verdict

As a very short, "executive" summary (not taking niceties like international character input into account - if you do need to input characters like them, do consult the chart very thoroughly to be able to find the best applications capable of this),

1. if you need the cheapest and easiest possible solution with a very flexible networking interface, go for LogMeIn Free. It behaved very nicely in almost every respect and, again, you can't beat the price.
2. If you're forced to use RDP (that is, the built-in Remote Desktop in Windows), try to get a WM6 (Crossbow)-based Windows Mobile device because of the vastly enhanced RDP client shipped with the new operating system. (If you only have a Pocket PC with a previous operating system, make sure you install vijay's full screen hack and/or consider switching to the MochaSoft client. However, you should seriously consider switching to an alternate solution because both solutions are still inferior to the better protocols / clients in many respects.)
3. If you're forced to use VNC (because, say, you've already installed a VNC server your desktop computer and don't want to install another one), go for PT PO (preferably with either UltraVNC or, even better, PTeSVNC as the server); it is a very solid and capable product
4. If you don't need through-firewalls functionality (or, alternatively, you're ready to configure the client to call back your client) and the higher bandwidth usage isn't a problem, z2 Remote PC will be one of your best friends: it has a LOT of additional, important niceties and is comparatively cheap
5. If you (also) need to access PIM stuff in your Outlook (Express), go for I'm InTouch. If you don't need the remote controller capabilities of the latter (because they're still a bit weaker than those of, say, LogMeIn), then, you will only need to pay $50 for the version that "only" supports accessing PIM stuff. Pair it with the LogMeIn Free (if you don't need file transfer) or LogMeIn Pro (if you do need file downloads from your desktop) and you have a killer combination for a still pretty low price.
6. If bandwidth usage is of paramount importance and not even PT PO's Tight mode is bandwidth-friendly enough and the high annual subscription price (and the lack of built-in file transfer on the Pocket PC) isn't a problem, give a try to Citrix's GoToMyPC.

Again and again, this short verdict should NOT be blindly obeyed. You should consult the comparison chart and, based on your requirements and the information there, decide for the remote controller application that best fits your needs. There are no all-in-one "best" applications; albeit, some of them are pretty close. Therefore, you must spend some time with the chart to make an optimal decision.

4. Final words

I know the article is pretty overwhelming for a novice. No matter how hard I've tried, I just haven't had the time to make it more beginner-friendly. What's more, the article is some 91 kbytes (without whitespaces) - including sections on the basics of networking would have resulted in its growing even more.

If you do not understand something, let me know - don't be afraid of posting your question (in public - please do NOT mail me in private because I'm already overloaded with private mails!), I will do my best to answer them. Please also make sure you also try to digest my networking-related articles (there are numerous of them; follow for example the links in my Multiplayer Gaming Bible and in the Web Browsers category of my Smartphone & Pocket PC Magazine's Expert Blog.)

UPDATE (01/05/2007): Readers’ feedback:

XDA-Developers 1 2, AximSite, BrightHand, FirstLoox, HowardForums.

AximSite frontpage; Clinton Fitch's recommendation in microsoft.public.pocketpc.

UPDATE (02/10/2007): Updated the article with WM6- and PPC Tablet 4-related info. I also recommend this remote desktop access-related post in the microsoft.public.pocketpc newsgroup; it may turn out to be useful for many. Finally, should you want to change the port number in the TSC client, you'll need this utility; also see this post.

UPDATE (12/02/2007): PPCT frontpage, WM6-wise

UPDATE (02/03/2007): At last, a REALLY decent RDP (Terminal Server) client for WM5!