[General Topics] Menneisyys:
Note that there are specialized Pocket PC applications with, 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, that 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 controller desktop PC isn't NAT'ed.

As can clearly be seen, with the highly recommended LogMeIn, direct connections are automatically used when they're possible. 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 now I have a direct connection.

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 accessing-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 won't want to use this feature with them because doing this will really slow down the rendering. That is, 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:

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.

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.