A lot has been changed after publishing my well-known Pocket PC Browser Bible (see the links in the final section) over a year ago. Windows Mobile 5 (WM5 for short) has hit the market with, on the engine level, vastly (and I really mean this!) improved Internet Explorer (ignore people that say the opposite - it's only at the GUI level that it hasn't changed much. The underlying engine is much better.) Minimo (which is a PDA port of the well-known, popular desktop browser Mozilla / Firefox) has been constantly improving and, now, it's really becoming a decent alternative to all the other Pocket PC browsers on many PDA models. So has Access' NetFront, the other alternate browser: there has been a major (3.3) release in the meantime. Last but not least, well-known multiplatform Web browser developer Opera AG has released no less than two Pocket PC-compliant browsers, Opera Mobile and Opera Mini, the former being, more or less, a Pocket PC browser based entirely on the desktop core, meaning superior compatibility with Web standards and the latter being a super-lightweight Web browser running even on a "dumb" Java mobile phone. It's only the developers (Bitstream) of Thunderhawk that haven't really done almost anything in the meantime (except for adding left-hand landscape support for HTC Wizard / Universal / TyTN etc. users).
This (and some additional bug reports & fixes I've promised for example for some AximSite forum members) made it necessary to completely rewrite the section on everything downloading- and resource saving-related.
This includes everything that results in a file saved to your PDA: saving the Web page you're browsing and would like to have a local (offline) copy of; an image in a page you'd also like to save to your PDA for further use or a file download (for example, an Over-The-Air (OTA) CAB installer file downloaded off a developer's homepage or a central CAB repository.)
Also, the article contains a lot of low-level compliance and bug reports. Very few people do know the HTTP protocol (the underlying protocol of the Web) inside out: the Windows Mobile community has the luck of having me as the resident expert on these questions. This means I also elaborate on HTTP compliance issues and also explain why some Web servers don't work with some current Pocket PC web browsers. This chapter will be a must particularly for the Opera, Microsoft, Bitstream and Access folks and everyone that would like to know why some web sites (for example, RapidShare) refuse to work with the browsers of these companies. This section also explains why you can't directly download .CAB files off certain Web sites when you use NetFront, Thunderhawk or Internet Explorer, unlike on your desktop. I provide a full list of the available solutions to these problems as well - that is, if you've ever had problems with CAB files not downloading in your Pocket PC Web browser, you'll find the solution in the third chapter.
Finally, I've made a LOT of new benchmarks on new WM5 devices / ROM versions to see how browsers behave on current devices and operating system versions and which one to choose if you want to download a file as quickly as possible.
Note that this review is in no way a complete overview / comparison of all the new, lately-introduced features of the available Web browsers. I'm still waiting for some new versions of some major Web browsers (for example, the official WM5 AKU3 Internet Explorer Mobile with, at last, vastly enhanced AJAX / JavaScript support); it's only after their debut that I'll publish a brand new, generic roundup. This roundup is all about saving something to the PDA, let it be a web page, an image or a file and discussing everything related to downloading files off the Web. You may want to check out the Web browser reviews I've published in the meantime - albeit not in an all-in-one, big roundup comparing all the new browser versions in one article, they contain all the information not contained in this article.
In the first chapter, I elaborate on generic resource saving capabilities like image saving, current Web page saving, link target saving and link copying - probably the most important areas of improvement in the last year. In the second and third chapters I elaborate more on strictly file saving issues; the second will be mainly of interest to people that want to have the best / fastest / most reliable HTTP (Web) download tool on their Pocket PC and the third will concentrate on compatibility issues and common problems. The latter will be a bit more technical than the first two chapters and explains on the protocol levels why some browsers are unable to download files off certain pages or for example doesn't offer the server-side name for a given downloaded file. It will be of paramount interest to affected Web browser developers (Microsoft, Opera, Bitstream and Access).
While the article is self-contained and, therefore, not necessarily requires the reader to read my earlier articles (most importantly, the Browser Bible), checking them out is still thoroughly recommended. Please consult the last, "Recommended links" chapter for the links.
1. Generic browser resource saving capabilities
Most (no wonder these features are in high demand among computer users) Web browser users have at least once wanted to save resources off the Web to the local computer (here: a Pocket PC PDA).
1.1. The three types of resources
Resources, as has already been pointed out, can be of three types on the Web (I use a slightly simplificated approach to be as clear as possible - that is, I don't include intricacies like how for example Flash animations or videos can be fetched from the Web. Consult for example this article on this question.):
images themselves contained in Web pages
web pages (HTML files) containing some text, links and inline images
files on the Web (for example ZIP and CAB files) you'd like to download.
On desktop browsers, you may already know how you can save these kinds of resources onto your computer.
1.1.1. Images
For example, if you want to save a single image in the desktop version of Internet Explorer, you right-click the image and choose Save Image As in the context menu as can also be seen in this screenshot. (Note that, from now on, I link in a lot of screenshots like this; for brevity, I won't, in most cases, mention they're screenshots. Therefore, if you see a link in this article (including the comparison / feature charts), it will most probably be an image link that you will really want to click if you want to see in real what I'm referring to.)
1.1.2. Web pages
The same stands for saving a Web page for offline access (or, when you know it'll change / will be removed and, consequently, want to save it before it happens). To do this inside the desktop Internet Explorer 7, just go to Page and choose Save As (or, in the previous - up to 6 - Internet Explorer versions, File / Save As). In there, you can name the file you're saving and can also change the format you're saving it in: an one-file, really useful Web Archive (.MHT) format, a single HTML without inline images or other related resources (for example, JavaScript or Style sheet includes) or full HTML's with all the related resources (which, then, will be put in a subdirectory of the target directory).
After saving a Web page, you can safely archive / transfer these files - all you will need to do to see them is clicking them. With non-MHT files (there is only one browser on the Pocket PC, NetFront, that does support MHT files), you can even use Pocket PC web browsers (except for the external server-based Opera Mini and Thunderhawk) to read your saved HTML files after transferring and clicking them in File Explorer on your Pocket PC. (Note that there are several other tools (non-browsers) on the Pocket PC to read local, offline HTML files, uBook and Mobipocket Reader being the two most important.)
1.1.3. Files
Third, when you right-click a link to a file you'd like to save (without, for example, directly passing it to an application that knows how to handle it - for example, a MP3 file to Windows Media Player, a PDF file to Adobe Acrobat Reader etc), you can save it in the desktop Internet Explorer by choosing "Save Target As..." in the context menu. Note that with some (mostly binary) contents, you can safely (left) click the link for the same effect on the desktop to be presented the same download dialog box.
On the Pocket PC, particularly with the built-in Pocket Internet Explorer (PIE) (it's called Internet Explorer Mobile (IEM) starting with WM5; this is why I'm referring to it under both names. Also see this article on this and similar name changes if interested), the situation may be different due to the core, in this case, not at all welcome differences between the desktop and Pocket PC versions.
1.1.4. Getting a link of a page or resource
Finally, when you want to, say, e-mail a friend the address (URL) of a Web page or a resource you've found, you can easily do this in the "traditional" way: left-click the link and, then Copy the new URL address to the clipboard (so that, from there, you can easily Paste it to the mail) by highlighting the contents of the address bar of the browser and, then, choosing Copy (or pressing Ctrl-C on the keyboard).
There is, however, a much more elegant and simple solution: instead of left-clicking (following) the link leading to the given resource / page, right-click it and select Copy Shortcut in the context menu. This will not only save you time (you don't need to wait for the page to load - if you don't cancel it in between), but also will work with all kinds of resources, unlike the former, which can not be used if, for example, the accessed contents aren't on a new page but dynamically offered or the content will be passed straight to, say, Windows Media Player.
This functionality may prove useful in other situations too; for example, when you need to use external tools (for example, EZDownload or WinMobile Download Accelerator, which will be discussed later, in Chapter 2) on your Pocket PC requiring the address of a downloadable file on the Web.
So, you'd like to see how you can do these four activities on the Pocket PC? The next sections discuss this.
1.2. Desktop Windows, Pocket PC and resource saving / link address copying to the clipboard
The following chart shows what Pocket PC (and, for that matter, desktop Windows) Web browsers support these kinds of functionalities and how you can access them. As with all my comparison charts, I've tried to make this chart as user-friendly as possible; this is why I've even included screenshots showing how the given functionality can be accessed in different desktop and Pocket PC browsers. (Click the provided links to see them.)
I've also added some version change information in here (as with the other charts); for example, with NetFront and "Copy link address to clipboard?", "new in 3.3" means this functionality was introduced in (the latest) version 3.3 and, therefore, doesn't exist in the previous, 3.2 version. These remarks will be highly useful if you plan to stick with the older version because of the upgrade fee and would like to know what isn't available in it.
Note that the chart doesn't contain PIE plug-ins, only top-level, stand-alone browsers; plug-ins will be discussed in the following section.
As with all the charts, plus (+) means existing feature while minus (-) means the lack of it. OS stands for Operating System (WM2003SE, WM5 etc).
THE CHART IS HERE - CLICK THE LINK!
As can clearly be seen, all the three major desktop Windows browsers support all these (in the desktop word, basic) functionalities. Not so with Pocket PC browsers, not even with desktop ports: for example, the current (8.6) version of Opera Mobile (which is a "dumbed-down" port of the excellent, highly, particularly for (W)UXGA users, recommended desktop Opera browser) doesn't support any kind of explicit resource saving or link copying and the same stands for the free Firefox / Mozilla clone Minimo. Thunderhawk is in the same league and, because of the very simple engine, it's highly unlikely it'll ever support this functionality.
NetFront supports everything; unfortunately, it's only able to save Web pages into MHT files (and not to simple HTML files), which means non-MHT-capable Web browsers (all the other Pocket PC web browsers) will be unable to read the pages it saves, unlike with HTML. (However, there are certain "hacks" that may help circumvent this problem - for example, saving a linked Web page as a file if you have some link pointing towards it or searching for the given Web page in the NetFront file cache.)
Finally, the built-in PIE/IEM is pretty incapable too; it's as late as in WM5 that it has received image saving capabilities. In previous operating systems, you don't have any way of saving images (unless you manually browse the file cache and look for the given resource - more on this later in the section devoted to this question). In this respect, the PIE plug-ins discussed in the next section help a lot: they implement most, or, with the more advanced ones, all the missing functionalities.
(A quick note: with Opera Mini, the free, Midlet-based Web browser running on a wide variety of devices (not just Pocket PC's but also your Java-capable smartphones or even dumb phones), image / link downloading doesn't work in IBM J9 5.7.2 (I've tested this on both WM2003SE and WM5). It, however, is working great in the latest, 6.1 version (tested on WM5). Therefore, you must upgrade J9 to the latter version if you want to access this functionality. Please see this tutorial for more info on version 6.1, the installation etc. Note that you won't have any kind of problems with the other, widely-known Pocket PC Midlet environment, the Intent Midlet Manager, which comes with most Pocket PC Phone Edition devices / ROM versions and, if you don't find it on your particular mobile operator ROM - as is the case with some US operators - is also accessible here as a download. Please read my generic Midlet article on its usage.)
1.3. PIE plug-ins and resource saving / link address copying to the clipboard
If you stick with PIE (and don't use another browser), you can still have additional capabilities with the help of the well-known PIE plug-ins, of which there are, fortunately, several, two of them being even free (ftxPBrowser and the free version of Webby). In the following chart, I list them all and also show (click the links in the chart for the demo screenshot) how the given functionality can be accessed. (Click the links in the first column to read the reviews / comparisons of the most current versions of all these plug-ins.)
THE CHART IS HERE - CLICK THE LINK!
Remarks:
As far as the current (D72) build of MultiIE 4 is concerned, it no longer has image saving capabilities (unlike the previous, 3.x series), which is certainly bad news. This means if you still have a pre-WM5 device, you need to either wait for a new version of the 4.x MultiIE series for this omission to be fixed or need to stick to the old, 3.x series. Unfortunately, MultiIE (along with Spb Pocket Plus) has never had the "Save Target As..." functionality either.
Webby (current version: 2.6) doesn't have explicit current web page/image saving capabilities either. Image saving is only possible under WM5, where PIE itself has image saving features (see the related screenshot in the comparison chart). Under previous OS’es, you can’t save images out of Webby.
Also note that its (existing) link target saving and link-to-clipboard copying features must be accessed in a radically different way than with the other browsers or plug-ins because it has no custom context menus and, therefore, everything must be done via traditional, "global", non-local / non-context menus.
Spb Pocket Plus, while having the other functionalities, painfully lacks the "Save Target As..." functionality, which all the other PIE plug-ins (except for MultiIE) have.
Also note that, as is mentioned ("only via Save Target As") several times in the chart, you can save HTML Web pages if the given browser / plug-in doesn't support Web saving, but it has the "Save Target As..." functionality. Then, you can still save a copy of the Web page - without images or anything related, of course. This, however, won't really help with for example (non-linked) images. This means you can't save images in any way under the MultiIE 4 + pre-WM5 PIE combination or in Webby. You should, however, not give up - there are ways of finding these resources with some additional tweaking (cache hunting), which I explain in the following section.
1.4. What should I do when I need to save some resource but my Web browser doesn't let for saving its type?
With browsers not supporting saving resources (for example the pre-WM5 PIE or Opera Mobile), there is another way of saving resource files by finding them and copying them off the local file cache.
(Quick note: in file caches, caching-capable Web browsers store the (recently) browsed Web pages and all the accessed resources. For example, if you don't disable displaying images and go a Web page that have five in-line images, six files will be created in the cache: the HTML file (the webpage itself, containing the text and the page layout markup) and the five images. Therefore, by manually browsing the cache, you can easily find all the (cacheable) pages, images and even other resources used by the HTML web page. This makes it possible to find resources in the file cache that, otherwise, would be inaccessible / not savable.)
This assumes the browsers
do have a local cache and
the files in there have the original, non-tampered (without, for example, added HTTP response headers - as is the case with NetFront) content
with either somewhat or vastly different names.
Depending on these three conditions, Pocket PC Web browsers belong to one of three groups.
1.4.1. Browsers lacking in (native) resource saving capabilities but having a local file cache that has all the files in the original, non-modified form
There are three browsers in this category. I've already written a fully-fledged tutorial on finding the resources these browsers store in the local file cache; please follow the links in the bulleted list below:
Opera: TUTORIAL: Here's how you can save images from inside best Pocket PC Web Browser, Opera Mobile!
PIE/IEM: Ever wondered why some of the Web pages saved with MultiIE or Spb Pocket Plus are completely unreadable? (alternatives: PPCT, AximSite, PPC Magazine, MobilitySite, FirstLoox) - it, in addition to explaining the GZIP problem, also contains a complete tutorial on manual page/resource finding and saving.
Minimo: you can easily browse the cache files of this browser. First, you need to enable the, by default, disabled caching in Preferences / Advanced. (Fortunately, now, caching works, as opposed to some earlier Minimo versions.) Then, all you'll need to do is scrutinizing the contents of the cache to find the files you want to save (it's a bit more complicated than with PIE/IEM or even with Opera Mobile because of the cryptic, machine-generated filenames Minimo uses in the cache.)
1.4.2. Browsers both lacking in (native) resource saving capabilities and NOT having a local file cache
With
Opera Mini (with this, you can save images but not explicitly pages or link targets) and
Thunderhawk,
you can't do the same because these browsers don't have local file caches. That is, in no way can you save for example the current Web page in either of these browsers - not even with looking for it in the (again, non-existing) cache.
1.4.3. The rest
Of the cases remaining, there is only one browser: NetFront. It, as of version 3.3, offers everything as far as resource saving is concerned (except for non-MHT - that is, HTML - saving). It also has a cache, which, as opposed to the first subcategory in this section, doesn't store the cached files in their original form but with the HTTP response headers embedded in them.
This means you won't necessarily want to use the binary files in there (as you already have "Save target as" functionality). Textual HTML files are different as you can very easily edit them and delete the additional HTTP headers. That is, if you REALLY need to export / save HTML files from NetFront (as opposed to saving pages in the default, only-supported .MHT format), browse the cache as with how the PIE / Opera Mobile / Minimo cache must be browsed by hand.
1.4.4. A comparison chart of the different caching cases
In the following comparison chart, I compare all these cases (whether a given browser has a cache, whether it contains the files in their original, non-modified form and, in addition, whether the filenames are easy to guess or have at least some kind of similarity to the original filenames). In addition, as a bonus, I've also added cache relocation information (and links to related articles), which can be VERY useful in a lot of cases, particularly on WM5-upgraded devices like the HP iPAQ hx4700 and the Dell Axim x50 series (see for example this article for more information on this problem).
Also note that, should you want to relocate the cache to even a volatile (one that gets deleted upon soft resets), but still highly useful RAMDisk, you can safely do this with ALL the cache-enabled Web browsers. This is pretty straightforward with Minimo (where you can select the RAMDisk from the drop-down drive menu), PIE and NetFront (please see the article relocating the Pocket Internet Explorer / NetFront cache (alternatives: PPCMag, iPAQ HQ, AximSite, FirstLoox, BrightHand) for a complete PIE / NetFront tutorial). With Opera Mobile, you need to do some additional work explained here. Make sure you only relocate the cache, not the history / cookie files (you don't want your cookies / browsing history to be entirely deleted upon soft resetting your device, do you?)
Note that I've also listed the three most important desktop Windows Web browsers - this information can be highly useful for you when you browse the Web and want to, say, save Flash animations or Java applet .jar archives for further use without third-party tools.
THE CHART IS HERE - CLICK THE LINK!
2. More thorough elaboration on "Save Target As..." and downloading in general; benchmarks
Particularly hardcore leecher... I mean downloaders (for example, people that would like to download hundreds of Megabytes off the Web on their PDA's) will find this chapter hugely useful. Based on the information contained here, you will be able to choose the best tool for a given task: if you can download a, say, 700 Mbyte .AVI with the fastest browser in, say, 10 minutes, why suffer with a slower browser that takes four or five times more time to download the same file?
Even if you "only" make smaller downloads right on your Pocket PC, you will want to read this chapter as it's full of tips, tricks and real-world benchmarks, explicitly telling you what browsers you should use and how, what to avoid and what pitfalls you may run into with some of them. After all, time is money - the faster the browser, the more efficiently it utilizes the available bandwidth, the better.
Note that, in addition to the desktop Windows and Pocket PC Web browsers, I have included two additional, stand-alone downloader applications, one of them (EzDownload; a free, fully WM5-compliant, slow, particularly when downloading files straight to storage cards, application; it, additionally, doesn't support a lot of other functionalities; for example, non-standard (non-80) Web server ports) being already known to the readers of my older, Web browser & downloading-related article. The other, new one is WinMobile Download Accelerator, which deserves special attention & treatment and will be introduced in the next section.
By the way, if you thoroughly read the above download-related article, you may rightfully ask why I have purposefully left out ViTO Downloader and ftxPBrowser from the current roundup. The reason for this is pretty simple: the former, ViTO Downloader is pretty unreliable (and hasn't been updated since my review); and the latter, ftxPBrowser, isn't at all WM5-compliant when it comes to downloading files. Needless to say, there is no new version of ftxPBrowser ; that is, the above-linked, previous review is still topical.
2.1. WinMobile Download Accelerator (WMDA) 1.8.1.0 (Build 2805)
This is, as has already been pointed out, a standalone downloader app (not a plug-in). It's a bit pricey ($20.00) and can be pretty slow in some downloading situations but well worth the money if you want to stick with "pure" PIE / IEM (without using PIEPlus or Webby, which are, currently, the only WM5-compliant PIE plug-ins with Save Link Target functionality; or, without switching to, say, Opera Mobile or NetFront, which both have much better download compatibility / capabilities) and often run into problems like "the CAB file I've clicked is displayed and not downloaded".
It's unique in that it's the only Pocket PC download application to support multisegment downloading (see the next section on what it means and when it can be advantageous). This means it's particularly recommended if
you often download files from slow(er) Web pages where multisegment downloading may be of use
you use plain PIE / IEM (NOT with a Save Target As-capable PIE plug-in like PIEPlus 2.0+ or Webby) and often have problems with rendered (and not downloaded) binary files
As opposed to what the developer's homepage states, it's not only compatible with WM2003 and WM2003SE, but also with WM5.
It's pretty extensively configurable; for example, you can even supply server auth code and enter referrer explicitly, which is very important with several Web sites (see the Caiman section in Chapter 3 for more info). Some other screenshots: 1 2 3.
Note that it also integrates into PIE / IEM, even under WM5, unlike EzDownload. That is, if it intercepts a download request (you click or, to the Address bar, enter a link that, for example, ends at .EXE or any predefined, freely editable "binary" extension), its dialog will come up and will be used for downloading. This can be configured in Tools / Options / IE; it's also here that you can supply a referrer (just like with EZDownloader).
The download extension list can be freely edited and new extensions added; for example, if you want to add CAB to the list (so that, when you click a CAB link, it'll be downloaded by WMDA and, if you aren't lucky, just rendered as a text file by PIE), just add ".CAB" to the list as can be seen in here. Then, the text/plain-related problem of PIE (of which I'll speak in the next, third chapter) won't be an issue any more - whenever you click a link that ends in .cab, it will be passed to WMDA for download. (Note that the same doesn't apply to NetFront or Thunderhawk - WMDA doesn't integrate into any other Web browser.)
2.1.1. Where can WMDA be really useful? Multisegment download and the (dis)advantages
You may have already heard of desktop Windows-based download managers like FlashGet and/or GetRight. The former is free software, the latter commercial. Give (one of) them a try if you're a serious downloader - you'll really like the really enhanced speed. Both support all the three major desktop Windows browsers: Internet Explorer, Firefox and Opera.
These plug-ins really speed up most transfers by using multisegment (parallel) downloads, which means the client not only downloads the given file in one thread, but in several.
On the Pocket PC, there is a similar solution delivered by WMDA. I've done a lot of tests to find out how good and reliable it is. I've also made some extensive benchmarks comparing the one-threaded and the (by default) five-threaded multi-segment mode of it with both fast and slow sources.
When accessing really fast (over 30 kbytes/s transfer speed) sources, you will NOT want to use it because it's definitely slower than the native download speed of ANY Pocket PC Web browser. However, if you are downloading something from a very slow HTTP server, the situation will be different: I've measured about two times shorter download times with WMDA than with any other Web browser (Opera, IEM, NetFront etc. - with slow sources, these one-threaded / one-segment browsers all produce roughly the same transfer speed).
The benchmarks of accessing (downloading from) fast servers will be in a later section elaborated on (because, unlike with the "slow" case, then, there may be considerable differences in how quickly a given Web browser downloads files off fast servers, which also necessitates a big chart listing a lot of cases and benchmark results).
The "slow server" case is certainly worth elaborating on: it's downloading from servers with slow connections that WMDA really excels (and, in addition, helping with downloads that, otherwise, would result in the browser's trying to render the binary contents of the file instead of downloading it).
For the slow test, I've used two well-known (at least from here Europe) "slow" servers: that of revolutionary software front and Octopus Studio (see the Definitive Roundup of All Pocket PC Dictionaries Part I - WordNet-based English Dictionaries and the Pocket PC Wikipedia Bible for more information on their, in cases, excellent products).
With the former site, I've chosen this file for testing; with the latter, this. Both are around 8 Mbytes. For the test, I used my Dell Axim x51v and downloaded to main storage (in this case, there is little importance of this because of the slow speed - it's only with fast downloads that the device model and the target of the download may have any effects on the overall speed, not with comparatively slow, 10-20 kbytes/s downloads.)
I've conducted the tests several times (listing all the individual results in the table cells below) to get as usable results as possible and to "weight out" the extremes. Note that cells with only one benchmark result can be safely ignored because the non-segmented download time benchmark results wildly vary. The results are given in minutes:seconds; the smaller, the better.
THE CHART IS HERE - CLICK THE LINK!
As can clearly be seen, with both servers, WMDA resulted in a clear speed increase in both cases. With the Revolution.cx file, it took less than 4:16 in all cases to download the file, while, with Opera Mobile, at least 60% of the transfers took more than 5 minutes (once even 11 minutes). The case is very similar with the octopus-studio.com tests.
2.1.1.1. Usability matrix - when WMDA should be used?
I've also created a matrix showing when using WMDA may be really a good idea. (Note that it does not contain the case of binary-files-not-offered-for-download case, which can be an issue with a plug-in-less PIE. If you have PIEPlus 2.0+ or Webby, you won't need WMDA to fix the above problem; in all other cases, you will, unless you're ready to hunt the file cache by hand.)
In the matrix, I show four cases: accessing slow/fast servers through slow/fast connections. All this compared to the speed offered by regular, traditional one-segment-download Pocket PC Web browsers (except for the slow Thunderhawk, which is even slower than WMDA in the "fast server" case).
Note that
I've assumed the server allows for multisegment downloads. Many don't. With them, you won't be able to use WMDA (or, you will be able, but in one-segment mode only, which will result in a really bad (further) speed decrease and, in addition, an additional byte containing a zero byte added to the file. This both means in this case you will not want to use WMDA but use "traditional" downloading methods / browsers instead).
I assumed slow client Internet access is in the range of GPRS speeds (3-5 kbyte/s) - that is, at least 3-4 times lower than the throughput of the slow server (which I considered to be between 5-20 kbyte/s, which is pretty common - see the above-tested two "slow" servers). By fast Internet access, I mean over 1 Mbps speeds; the same stands for fast servers.
That is, the chart:
THE CHART IS HERE - CLICK THE LINK!
That is, you should only consider using WinMobile Download Accelerator if you aren't downloading from fast servers (where you can download with more than 20-30 kbytes a second from). In all other cases (accessing a fast server), WinMobile Download Accelerator will deliver clearly inferior speed than all the other solutions (except for the even slower EzDownload and ThunderHawk), as will be clearly seen in the forthcoming, "fast server" download benchmarks.
2.2. Downloading in general - chart
In this chart, I've collected everything that has direct impact on downloading. These are not benchmarks but generic features (and, with the last column, possible sources of problems / slowdowns).
Explanation for the chart:
Resuming, stored download list: The first column (pause/resume) elaborates on whether the transfers are stored through restarts (which would be highly preferable and is also implemented by all decent desktop-based third-party accelerator plug-ins). As can clearly be seen, only WMDA supports this.
The second column shows whether a partial download can be resumed (which the HTTP protocol supports; so do desktop browsers). Unfortunately, only WinMobile Download Accelerator and EZDownload support this.
Multisegment (multithreaded) downloads: The third column shows whether the given application supports multisegment (multithreaded) downloads, which can considerably speedup transfer with slow(er) Web servers. As can be seen, it's only WinMobile Download Accelerator that supports this.
2.2.1 Implicit buffering in built-in storage?
The fourth column, "Implicit buffering in built-in storage?" is one of the most important: it addresses a common question / problem with built-in (or, in cases, third-party) Windows Mobile Web browsers and downloader applications: When you download a file to a storage card, does the given Web client use the built-in storage as a temporary storage medium and only flushes the (temporary) contents to the storage card when it's absolutely necessary (or at the end of the transfer). The two approaches (buffering-less and one that does use in-storage buffering) have radically different consequences.
Advantages of the buffered mode:
It may be, in cases, considerably faster than the non-buffered case. This would particularly be the case with RAM-based storages in operating systems prior to WM5 (see the benchmark results of the WM2003 iPAQ 2210 and the WM2003SE PL720: PIE is at least three times slower with them when writing to the storage card directly). In WM5, however, it's no longer the case: buffered solutions are not necessarily faster than non-buffered ones. (Unfortunately, none of the Web browsers that do use buffering use the dynamic RAM for this purpose, only the file system. This could be later worked on in later IEM or WMDA versions.)
Disadvantages of the buffered mode:
On WM5-upgraded devices that have slow-to-write and even-slower-to-delete flash ROM (Dell Axim x50 series, HP hx2xxx and hx4700), using these applications may result in lengthy filesys.exe sessions, which you don't necessarily want. (This is why, while benchmarking the built-in IEM of the WM5-upgraded hx4700, filesys.exe-based compactions have always kicked in during downloading the 8Mbyte-long test file)
If the built-in storage is smaller than the file to be downloaded, there may be problems (or at least severe slowdowns) when the built-in storage memory runs out (see the PIE/IEM- and WMDA-related comments).
The two applications that use the built-in storage for buffering behave differently in the second case. IEM under WM5 (under previous OS'es, PIE doesn't buffer) is very well written; when the memory fills in, it flushes everything out to the target card and then, continues downloading without any problems, crashes or CRC errors. The only problem you'll then encounter will be the drastically (about three times) reduced transfer speed.
WinMobile Download Accelerator, the other application that does in-storage buffering, behaves differently: when it completely fills in the built-in storage, the transfer just stops with an error message. This is very bad news: this means you will never be able to download bigger files than the current size of your free storage, unlike with all the other Pocket PC-based downloader solutions. Fortunately, this can be fixed by relocating the cache to a large, well-optimized memory card - with some (additional - fortunately, not really bad) speed hit.
2.2.2 The chart
THE CHART IS HERE - CLICK THE LINK!
Note that "See with PIE" with Opera Mini means the latter uses the PIE / IEM engine to download files / images. This means all benchmark / resumability etc. data are the same with the two browsers.
Now, let's have a look at how the browsers and downloader apps fare over fast connections, with fast servers. It's in here that there will be major differences, as opposed to the three other cases (where either the client or the server is slow - or both).
2.3. Downloading speed benchmarks
While with short downloads and/or downloads over a slow link (for example, if you have a slow GPRS connection), browsers behave exactly the same way, over very fast connections, accessing servers that also have a fast Internet connection, there can be huge differences between different Web browsers.
My benchmark results are contained in the next comparison chart, where each column contains the time needed to transfer a given test file off a local Web server on my desktop on the (freshly hard reset and containing only the tested applications) test device. I've benchmarked both built-in storage (which is RAM with pre-WM5 devices and flash ROM with WM5 ones) and a storage card (which was the same in all cases; always freshly formatted with exactly the same parameters).
Note that, with WM5 devices, I haven't tested the, otherwise, excellent RAMDisks because they are inherently small (6...10 Mbytes at most) on current, "official" WM5 devices (not the MDA III with the "hacked" WM5, where you can create even a 96 Mbyte-large RAMdisk because of its huge, 128M built-in RAM) and, therefore, of little utility in trying to speed up transfers.
Making clear distinction between the given memory types available in a given device is very important. As you may already know (and has already been pointed out in many of my WM5-related articles), writing to dynamic RAM is by far the fastest process. Writing to flash ROM-based memories (this includes both storage cards and built-in storage on WM5 devices) is, in general, slower than writing to RAM. This is why the "slow", over three years old, WM2003-based HP iPAQ h2210 smashed the WM5-based competition in all transfer tests into the main storage.
In the tests, I've used this file on a local Web server (with Thunderhawk, I used the, in size, comparable Minimo 0.016 CAB file because the central Thunderhawk server had problems with accessing my local desktop). Do NOT try to benchmark your browsers directly from this Web site as it may have slow international bandwidth. Make sure you upload it to a site (for example, one on your desktop computer your PPC directly connects to through USB or any Intranet web server at work) that you can access very fast so that there won't be bottlenecks in the achievable transfer speed.
Finally, as has already been pointed out, I also made sure I used the same storage card in all the devices so that the different card characteristics (write speed) don't cause any difference.
THE CHART IS HERE - CLICK THE LINK!
As can clearly be seen, there are huge differences in how different devices behave. For example, on the Axim x51v and the iPAQ hx4700, there are almost no differences. On the HTC Wizard, on the other hand, the differences between the only really fast-to-download Opera Mobile and the rest are really big.
It's also worth pointing out that on all the three WM5 devices, unlike with pre-WM5 OS'es, PIE / IEM-based downloads are almost equally fast when downloading to a storage card and when to the built-in memory (unless the latter has less free space than the file you're downloading to the memory card - then, even three-fold differences in speed can occur). This is because, as has already been pointed out, under WM5, IEM buffers in the main storage first and only flushes to the card at the end of the transfer (if the main memory doesn't fill in entirely in between); hence the similar (and, compared to pre-WM5 devices, in general - except for the Wizard - much better) results.
EZDownload fared equally bad on all the test devices when writing directly to a memory card; particularly on the HTC Wizard. It's best to avoid it completely, unless you, for some reason, really need it. Writing to RAM is of acceptable speed on pre-WM5 devices (but in no way as good as with any other application - except for WinMobile Download Accelerator, which is equally slow when accessing fast servers). Generally, download add-ons are much slower than other solutions.
As a rule of thumb, if you need to choose the fastest browser for downloading (from fast sites over fast connections), Opera Mobile is your best bet. It, incidentally, was much-much slower in the beta versions (see the previous download speed tests). It was really worth pointing out the bad transfer speed of Opera Mobile back in January: it has gained a great speed upgrade, which makes it for example on the HTC Wizard by far the best browser. This, of course, greatly depends on your particular model: as can clearly be seen in the chart, the x51v and the hx4700 has pretty similar speeds with all the Web browsers (except for, again, the slow Thunderhawk), so has the iPAQ h2210. It's only with the Loox and the Wizard that there are really huge differences between downloading efficiency.
Also note that I haven't included Opera Mini in this chart - as has already been pointed out, it uses the PIE / IEM engine for downloading and, therefore, has the same speed as PIE / IEM.
Note that I've not only made extensive benchmark tests but also CRC checked every downloaded file on all test devices to see whether they contain bit errors. I haven't encountered any problem (except for the additional byte (containing a zero EOF byte) of WinMobile Download Accelerator in the not recommended, very slow one-threaded mode).
2.3.1. A quick comparison of current and previous Opera Mobile and PIE/IEM versions
As has already been mentioned, the new version of Opera Mobile and PIE/IEM versions are radically different from the previous ones when you download straight to a memory card. The (really welcome!) changes, just to recap, are as follows:
THE CHART IS HERE - CLICK THE LINK!
3. "Why can't I download CAB / other binary files in PIE / any file off some sites?" - compatibility issues
Now that we know
how the available self-standing browsers and PIE plug-ins support saving resources (even with manual file cache browsing when there are no other choices)
what WMDA can be used for, how the different Web browsers and Web downloader utilities compare to each other and which of them runs on which Pocket PC model the best,
let us switch to a slightly different area: that of compatibility issues. There will be several of them.
3.1. „Content-Type"-related problems (AKA "When I click a CAB link, it's not downloaded but shown!")
First, I'll explain one of the most common problems of PIE/IEM, Thunderhawk and NetFront users: the problem of non-savable CAB files.
That is, when you click a CAB file on a Web to be downloaded (so that you can save it in the local file system and execute it there for the given Pocket PC application to be installed), PIE, Thunderhawk and NetFront, in cases (with some servers), renders (shows) the contents of the CAB file, instead of letting the user download it.
Of course, the problem not only applies to CAB files, but also other types of files; for example, the MDX files on octopus-studio.com (for example, the file used in the WMDA-related section to measure the download speed of the given Web browsers compared to WMDA) also suffer from the same problem.
The reason for this is very simple: the servers don't set one of the returning HTTP response headers, Content-Type, correctly, but leave it at the (for unknown / not manually configured file types) default text/plain type.
While the desktop IE (along with all the two other Web browsers) correctly handle these files, this is not the case with three Pocket PC Web browsers, the built-in PIE (yes, unfortunately, there are some algorithmic differences between PIE and the desktop IE), Thunderhawk and NetFront. These, when they receive content marked as plain text (that is, having the text/plain header in the answer of the Web server), will blindly render it (instead of presenting the user a save dialog) even if it's binary in reality.
Current examples of Web servers that return CAB and/or other, similar files as text/plain is that of the above-mentioned Octopus Studio site (with an example file here, linked from here), FinchSync (example file here) and TasksPlus (example file here). The last two examples are also linked from the Application category of FreeCabs.
To fix these problems is fortunately pretty easy if you have PIE:
consider using a link target saving-capable PIE plug-in (as far as WM5 compliant ones are concerned, PIEPlus and Webby (even the free version of the latter); under previous OS'es, you may also use the free ftxPBrowser)
alternatively, you can manually browse the cache to find the CAB file or,
if you have either Spb Pocket Plus or MultiIE (two PIE plug-ins NOT allowing for directly saving link targets but allowing for saving the current page directly, verbatim, without modifying it contents), you can use them to save the currently "rendered" binary file as a HTML web page. You'll only need to rename this file with a file extension-capable, third-party file explorer like Total Commander or Resco File Explorer and, then, you'll have the original binary file
if you often download from slow sites over a not very slow local connection, you may want to consider giving WMDA a try: it not only helps with downloading from sites with (comparatively) slow connections, but also integrates into PIE, making downloading even easier than with EzDownload (there is no need to copy any target / file URL to the clipboard). It's also considerably faster than EzDownload.
finally, if the pretty bad transfer speed isn't a problem (or not so important as not paying anything for any third-party, commercial utility like WMDA or the four above-mentioned utilities, you don't want to use the free version of Webby and don't want to manually search the cache either), you may also want to give a try to EzDownload. Then, you just copy the address of the current CAB / other binary file off PIE's Address bar to the clipboard, and invoke EzDownload.
Note that with Thunderhawk, you can't do anything to remedy this situation. It doesn't have any kind of cache to browse or current Web page saving capabilities.
NetFront, fortunately, has "Save link target" functionality in the new, 3.3 version; that is, you'll be able to directly save a linked binary file by not clicking it, but tap-and-holding and selecting Save / Link Target in the pop-up menu. The situation is different with earlier (even 3.2) versions without the explicit "Save link target", and not even cache hunting helps as it does have cache but it modifies all cached files (by adding the HTTP response headers to them) and doesn't offer verbatim saving capabilities.
Finally, don't forget to tell the webmaster of the site that your PIE / TH / NF receives binary files as textual to either adding the given file extension to the known so-called "MIME type" configuration file as either application/octet-stream (real-world examples of servers using this: 1 2 3 4 5 6) or, even better (because, then, PIE / IEM won't ever attempt to parse them for a known file type), application/ANYTHING where ANYTHING can really be anything; for example, x-MyDummyMimeType. In the latter case, it's preferable to start it with x- to show it's a custom (non-standard) type. Note that with CAB files, it's customary to use one of the following three MIME subtypes (in place of "ANYTHING"): vnd.ms-cab-compressed (as with this server; example download), x-msdownload (as with the PocketGear server; example here) and x-compressed (as with the Minimo server; example download ). (Incidentally, this excellent article suggests the usage of the x-download subtype.)
3.2. Double requests upon file download - the RapidShare problem
In the above-linked AximSite thread, I've been told of a strange problem affecting Opera Mobile and NetFront, making it impossible to download anything off the well-known file distributor service RapidShare.
I've found the protocol-level cause for the problem after some investigation: NetFront and Opera Mobile, when downloading any resource, resends the requests (in both GET and POST mode) sent out right after the download starts. This is what causes the RapidShare service to immediately close the transfer and just return an error page. (NetFront reissues exactly the same request (for example, two times the same POST), while Opera Mobile, if it sent out a POST request first, sends out a GET second - to the same URL. Both issue additional no-cache headers in the second request when needed.)
Note that the desktop Opera doesn't suffer from this problem - only Opera Mobile.
This means if you have problems with these browsers and RapidShare (or, for that matter, any Web page that only accepts one download request and just returns an error page upon the second), use an alternate Web browser like the built-in PIE or Minimo. Note that, specifically with RapidShare, Thunderhawk won't work either because it won't be able to count down - its JavaScript compliance is limited.
(Some debugging screenshots of what's happening, using the excellent, albeit expensive and easily crashing debugger proxy Charles (this time, I haven't used my debugger proxy). With PIE, the POST request sending the captcha code and the direct URL of the file to be downloaded is here; here's the response (the file itself), after which PIE doesn't send out another request(s). The initial request is exactly the same with the (buggy) NetFront; so is RapidShare's response. However, right after starting the download by the user, NetFront issues a second request for the same resource, which results in an error page to be returned by the server.)
3.3. Referrers passed to download? The Caiman problem
I've (re-)tested the "Referer" problem of PIE explained here (please read it for further info) with all the new browser versions. The best news is that, except for, it seems, Thunderhawk, none of the major browsers have related problems - including, fortunately, WM5. Kudos to Microsoft - PIE / IEM is really getting more and more stable and standards-compliant.
(This, of course, still means you can't use PIE under previous operating systems on sites requiring explicit Referer passing. There, use alternate browsers or some download managers which also allow for Referer setting.)
3.4. Comparison chart
In the following chart, I've listed all the above cases, with some additional ones. These explain whether a given Web browser parses the contents of a given Web resource returned with the application main MIME type and either the well-known widely used octet-stream subtype or with a deliberately unknown subtype. I've also thoroughly tested where the Web browsers look for type information and where they get their filenames from. I don't explain these columns as they are "only" of interest to Microsoft, Opera, Bitstream and Access developers and anyone knowing the HTTP protocol well enough to understand the separate cases. These columns are of no interest to ordinary, non-geek people - not even with explanation.
Note that, as usual with my thorough protocol compliance tests, I’ve used a custom-developed HTTP server emulator to test all this. It (the source – as usual, I release it as sources so that you can also have a look at it) is available HERE and should be used the following way:
the first parameter should contain the name of the file to return. This makes it possible to test the browsers with a lot of different types of files – image files, PDF files etc. The point in this the ability to find out that, say, does the browser try to find out the real type of files that are sent back as application/octet-stream or, horribile dictu, application/HERE-IS-SOME-UNKNOWN-SUBTYPE. (Also see the second parameter on setting this type)
if the second parameter is a single Y, application/octet-stream will be returned as the file type; otherwise, the custom and by Web browsers unknown application/x-download. The point in this parameter is that, testing the Web browsers with both combinations, you can see whether they differ in how they handle different subtypes of the application MIME type. Implementing and testing this was really useful and instructive: as you can see in the “Save (+) or render (-)., depending on the type” group, PIE treats files of type application/octet-stream differently than files with an unknown subtype.
Finally, the third parameter is either a “Y” (then, it returns the real name of the file) or a custom-given name in the Content-Disposition header. For example, if you supply an “anything.dic” name as this parameter, it’ll return this name and not the real name of the file. Implementing this conditional, I was able to test whether the Web browsers do parse the contents of the file to find out whether it’s of a different type than its name suggests in the Content-Disposition header. The results gained by using the two possible cases can be seen in the first two columns (“Peeks into file to decide its type to override the type given by C-D filename / URL?” and “Takes into account C-D filename?”) of the “It decides for the content type & gets the filename by...” group.
There was another test I’ve made (you can do the same too), which is listed in the last (“Takes into account last URL part? (Not usable with, say, servlets!)”) column. If you supply an additional path information to the URL (in the form of, say, http://test-PC-address:82/bogusfilename.bogusextension), fooling the Web browser into thinking it’s requesting a file off the server with the filename bogusfilename.bogusextension, you can test whether it tries to set the name and the type of the saved file based on this information.
THE CHART IS HERE - CLICK THE LINK!
Note that C-D stands for the Content-Disposition HTTP response header, which tells the client (in the "Attachment" property) what filename a given, dynamically served and/or generated file (that is, one whose name can't necessarily be guessed from the request URL sent by the client) should be saved at. (See this for more info.) Unfortunately, Opera Mobile (unlike the desktop brother) just ignores this header; this is why it doesn't know under what name a given file should be saved at.
3.5. Summary chart: the differences between desktop and mobile versions
Now that we've seen the Pocket PC-based and the desktop Opera and Internet Explorer are different in some respects even on the protocol level, let's have a summary of these differences. This will be of great help to Web authors wanting to make sure their Web contents are accessible by both desktop and Windows Mobile clients:
avoid only relying on the client's ability to get the filename off the C-D HTTP request header of dynamically created files: try to use a bogus filename at the end of the invoking URL because it's from there that Opera Mobile tries to extract the filename from
upon receiving double requests in rapid succession for a given resource, don't return an error page (instead of the requested resource) to the second request but return with the same resource (the RapidShare problem with NetFront and Opera Mobile)
never use the text/plain type because it'll make PIE / IEM and NetFront try to render the page without actually checking for being binary. Even application/octet-stream should be avoided (use application/SOME-UNKNOWN-TYPE instead) if you don't want PIE / IEM to try to even peek into the file to find out what type it is. Try to keep your MIME type configuration as up-to-date as possible and make sure you include file extensions of all binary types you or your users put on your / their homepage(s).
THE CHART IS HERE - CLICK THE LINK!
It's worth pointing out that the desktop Mozilla / Firefox and the Pocket PC Minimo work exactly the same way in every respect - as has always been the case. Great, promising work - certainly the dream of webmasters sick of profoundly different desktop and mobile versions!
4. Recommended links
The Web Browsers category on my blog
How can you avoid the consequences of a new, file download-related bug I've just found in Pocket Internet Explorer? - now deprecated
Beware of downloading large files straight to memory cards, even over fast connections! It can take ages! - now deprecated
Downloading files with PIE (alternatives: PPCT, AximSite, PPC Magazine, FirstLoox, BrightHand). (Pretty outdated!)
Do you know ftxPBrowser? - somewhat deprecated: no WM5-related compatibility info; however, it provides a good overview of the features of the browser
Here's how you can save images from inside best Pocket PC Web Browser, Opera Mobile! - still topical
New version 1.06 of Great Alternate Web Browser NetFront is out! A full review - with some page loading / rendering data
Link collection to the latest Pocket PC Web Browser reviews (will update some time)
Relocating the Pocket Internet Explorer / NetFront cache (alternatives: PPCMag, iPAQ HQ, AximSite, FirstLoox, BrightHand)
Bible of Web Browsers (alternatives: MobilitySite, AximSite, FirstLoox, PPC Magazine, BrightHand) – over a year old, but still contains topical info
UPDATE (10/14/2006): PPCT frontpage; added an explanation of the HTTP server emulator.
(Finally, guys, sorry for posting the article in so many pieces. Have to slice it up because of the 10k char limit)
EDIT (01/05/2007): Updated version posted; for the time being (because of the hurdles involved with cutting the article into 10k slices), to http://www.pocketpcmag.com/blogs/index.php?blog=3&p=1571&more=1&c=1&tb=1&pb=1 only. I'll only update the article below when I have some time for slicing the article.
I’ve long been promising a generic roundup on the ways of accessing desktop PC computers from Pocket PC’s, mostly because there aren’t really usable and/or up-to-date all-in-one articles on the subject, let alone comparative ones.
Getting this roundup ready took me a lot of time (over six weeks): much more than I’ve originally expected. The reason for this was that I’ve made some really serious bandwidth usage and networking model tests so that I can provide you as much objective, comparative information as possible. I also very thoroughly tested the protocols used by these applications to find out internal weaknesses or lack of optimization. I’ve also been in really busy correspondence (asking about every single problem / question I’ve run into in their applications) with most of the authors of these titles; I’d like to thank Carsten Alsted Christiansen and Csaba Tutsek from Danware, Ditta Khan from NetSupport Ltd, Jan Frydendal from MochaSoft and Julie Geer & Heidi Wieland from Citrix Systems for their answering my questions. (The Symantec folks don’t have a working E-mail address and their online chat support (yes, it's outsourced to India), to put it mildly, leaves a lot to be desired. As far as Laplink is concerned, I haven’t received any answer to my mail sent to [email protected] on 12/11/2006.) Also, special thanks goes to Minakshi Pai of 01 Communique and “Dave” from Parys Technografx for not only answering my questions, but also listening to my recommendations and ideas, some of them having already been incorporated into the most recent versions of these applications.
I’d also like to send special thanks to AximSite god akheron (he was of tremendous help in, for example, hunting for the trial version of pcAnywhere), H/PC Factor moderator (and also well-known contributor on many Handheld PC-related boards / forums) cmonex and forum member TFGBD for their help in their forums.
One of my main objectives with the thorough measurements was to provide an up-to-date bandwidth consumption report. Up to now, to my knowledge, it's only Jason Nieh that has published really usable bandwidth usage reports (I really recommend the articles on his just-linked homepage if you're into the subject). His, so far, most important PDA-related article, "Improving web browsing performance on wireless PDA’s using thin-client computing" (direct link to the article), which was published in 2004, contains pretty outdated and no-longer-topical information. With my measurements, I think I could produce a decent and, what is more, up-to-date overview of the bandwidth usage of current, real Pocket PC applications. By the way, still as far as Jason Nieh's PDA-related work is concerned, I especially recommend his article "pTHINC: A Thin-Client Architecture for Mobile Wireless Web" on a promising initiative. I really hope it will be released some day as a freeware or even commercial product.
First, let me point out that I’ve “only” reviewed and compared “full” remote control solutions in here. This means I have not included multimedia- or scripting-only controllers. They will be reviewed in my forthcoming roundup. That is, if you “only” want to remote control, say, your desktop Windows Media Player or run your scripts when initiated from your Pocket PC, you may want to wait for the next article. (It’s, generally, much easier and much less resource-, including bandwidth, intensive to remote control a multimedia app or server-side scripts with a dedicated application than via a generic remote access application. That is, you won’t really want to remote control for example your WMP via, say, VNC.)
Also note that it’s not here that I have elaborated on the opposite direction; that is, controlling the Pocket PC from a desktop PC (or another Pocket PC). Please read this article for more information on this subject, making sure you also follow the links to my older articles.
Last but not least: most of the tangible information is in the 120 kbyte-long comparison and benchmark chart. In the non-chart-based part of this review, I only give a terse, broad, but in no way thorough overview of what the reviewed applications are all about and how they compare to each other. It’s also in here that I elaborate on the underlying protocols (RFB (in VNC), RDP (in Terminal Server/ Services aka (Microsoft) Remote Desktop)), the way you can decrease bandwidth usage (which is of paramount importance when you use, say, a non-unlimited mobile phone-based connection) etc. Most of the comparative, real, quantitive information and hundreds of screenshots (many of them functioning as a mini-tutorial showing how the mentioned/ discussed functionality can be enabled in a given application), however, are in the chart. Therefore, make sure you, for example, open the chart in a maximized browser window. If you have an UXGA (1600*1200) or an even wider screen (WUXGA, for example), then, you’ll be able to see all the 18 columns at once while still being able to read the text. With lower-resolution screens, you’ll end up having to scroll horizontally to be able to read all the information (and many state (W)UXGA screens are useless and should be avoided... ). Sorry for that: comparison / feature charts like this are still the best, the most compact and reliable way to compare products and list all their capabilities, unlike plain text-approaches many other reviews use. Note that I also thoroughly explain below how the chart should be read in a later section.
1. Introduction
The aim of remote access applications is the same: to provide you access to your desktop computer(s) (in here, I'll refer to them as "remote desktops") when you’re away from them. You can control them from your client PC (or, in this case, Pocket PC) directly. That is, you can see the remote desktop on your (local) client PC (Pocket PC) as if it were running locally, right on your client and not somewhere else on the Internet far away. With some really advanced clients, you can also do direct file transfers, clipboard synchronization (for example, if you have a loooooong e-mail address in a local file / database on your local client (Pocket) PC, you only copy it to the local clipboard and, then, just synchronize the clipboard so that it also becomes available on the remote clipboard; this way, you can avoid having to re-enter it on the remote desktop by hand), remote administration and Personal Information Management (PIM) data (calendar, contacts and even mails) access in addition to “plain” remote controlling.
There are, basically, two kinds of remote access / control applications: 1. Web-based ones and 2. non-Web based ones.
In general, the former
are much easier to set up on both the server and the client (except for, maybe, RDP-based, already built-in solutions like the RDP-based "Remote Desktop" in Windows XP Pro and Terminal Services Client (TSC) in most client-side Pocket PC’s). In most cases, when you plan to install the server on your desktop computer you want to access remotely, you just navigate to the homepage of the developer and let it download a server to your desktop PC, which, then, you just install (the latter is, in most cases, just clicking the “next” button and entering the username and/or password you’ll want to use). Furthermore, as far as client installs are concerned on any desktop PC or Pocket PC you come by, you just navigate to the above page and try to log into your remote PC. This will trigger a fully automated client download and install.
give complete freedom to the subscribers in that they connect to their remote desktops really easily, independent of the networking model of their desktop (that is, these services even work over firewalled and/or severely restricted connections). All you need to do is making sure your computer you want to remotely access has Internet access. No need to configure any firewalls or to even know the actual Internet address of your computer, the central Web server takes care of all this. All you need to do is logging into your central account in the central Web server: it will connect you to your remote desktop.
That is, for a non-IT-professional, these kinds of remote access solutions are preferable to the other group, which, in general, requires manual server download, installation, configuration and, in cases, tuning. This is why, first, I discuss the first group.
1.1 Web-based end-user applications
1.1.1 LogMeIn
Probably the most important and most recommended Web-based application, unless you need advanced PIM / mail access functionality, is LogMeIn. It, basically, has two versions: the free LogMeIn Free, which only offers remote control (with all the advantages of web-based access: firewall support, on-the-fly, easy client install requiring almost no user intervention or setup etc.) and LogMeIn Pro, which, in addition to remote controlling your desktop, also supports file transfer (with desktop clients, bidirectional, with Pocket PC clients, download only) and, for non-Pocket PC clients,
Remote Printing to print remote files locally, on the printer attached to client
File Sharing to easily share large files, without uploads (similar to, say, MegaUpload)
Guest Invite to share the desktop for remote collaboration
File Synchronization to synchronize files & folders of the client and the remote desktop
Security (256-bit SSL encryption)
As can be seen, the Pocket PC version, unfortunately, is decidedly worse than the desktop PC one – as is the case with, unfortunately, most of the reviewed applications.
If you opt for going for the Pro version, you can bring down the price by just declining the LogMeIn Pro update after the Pro trial period is over (note that if you go right for the Free version, you get a Pro trial too). Then, you’ll be sent a mail that offers another 30% rebate, bringing down the annual price to $44.95. It’s a pretty friendly and highly recommended price if you take the price of the other solutions into account (and don’t need their unique features; for example, the PIM access features of the two times more expensive I’m InTouch or the excellent bandwidth usage of the four times more expensive GoToMyPC).
Note that earlier versions had problems with WM5 AKU2 devices. This has been fixed in later versions and isn’t an issue any more.
More info: The free version of the LogMeIn service has also been mentioned in the “What Is The Best Free Service?” thread at PPCT.
Some screenshots (note that you'll find a LOT more in the comparison / feature chart!): Local client install to add computers; after it’s installed, it’ll prompt you. The server-side settings dialog is browser-based as can be seen in here.
Verdict
A well-behaving, stable, useful application. The free version is probably the most recommended, really-easy-to-set-up-and-access application, working in any networking environment, for casual, not necessarily power users not wanting to have external PIM access.
1.1.2 GotoMyPC by Citrix
This Web-based remote access solution has by far the best bandwidth usage of all the solutions. This means about third or even fourth the bandwidth usage of comparable solutions. This is, unfortunately, a bit worsened by the idle bandwidth usage (see the chart for numeric results), of which I'll speak later more. The other, major disadvantage of this solution is the price (the monthly rate is $19.95, the annual plan $14.95 a month) – it’s way more expensive than other Web-based solutions. For example, it’s about four times more expensive than LogMeIn Pro and two times more expensive than I’m InTouch and RemotelyAnywhere. With the Pocket PC client, it doesn’t offer file transfer or other advanced functionalities either, unlike most of the alternatives.
A quick tip: Upon registering for a trial version, by default, you need to supply your card number for the trial. If you don’t want to use the card (because, for example, you are worried about forgetting to decline the subscription before the trial period is over), you’ll be offered a 30day/180 minutes, cardless plan. Alternatively, you may also want to go here for a version that doesn’t require inputting a card number. Finally, if you just stop the registration process on the credit card setup screen, after about three weeks you’ll receive a mail offering you the card-less registration page URL.
After letting the app install the client, a GoToMyPC icon will be put in the Start Menu / Programs. By just clicking it, PIE will be fired up and you’ll be taken to the online GoToMyPC login screen.
As far as the astonishingly good bandwidth usage is concerned, I’ve directly asked the Citrix folks whether they use the infamous ICA protocol (also see this and this discussion). It is NOT using ICA, despite what I would have thought.
Note that the client no longer needs Java support to run, as opposed to older versions (see for example this for more info on the past versions).
More info: Reviews of the service are here and here; an ad is here.
Verdict
Go for this title if you want to have absolutely the best bandwidth usage and responsiveness and the high subscription price isn’t a problem. If you, on the other hand, don’t need to use a really bandwidth-saving method and/or would prefer a cheaper solution, look elsewhere – alternative solutions are not only much cheaper (if not free as is the case with LogMeIn Free), but also offer far more (file transfer with all alternative Web-based solutions – except for LogMeIn Free -, PIM / e-mail access with I’m InTouch etc).
1.1.3 RemotelyAnywhere 7.10.552
This Web-based service uses exactly the same Pocket PC GUI as LogMeIn and, therefore, is pretty similar to that of GoToMyPC. For example, the file transfer screen and waiting dialogs are the same as with LogMeIn. As with LogMeIn, it has chatting and it has very similar menus and can, for example, dynamically change the remote desktop resolution. The control interface is exactly the same as with LogMeIn; so is the file manager. Unfortunately, there’s no file upload here either.
The most unique feature of RemotelyAnywhere is the remote administration interface, which is accessible even on a Pocket PC. No other Pocket PC-based remote controller offers the same functionality. This means you will want to consider using RemotelyAnywhere if you want to access your desktop(s) through a local admin interface to, for example, remotely access the registry, the service list and other properties of a given desktop computer.
Connection model-wise, unlike on the GUI level, it’s really different than any of the other applications in the Web-based section. While it must be installed from the Web (the $99 – note that there’s a 25% rebate if you sign up for two years at once - Workstation Edition is available here and the Pocket PC client (as with all the other Web-based services, it uses auto-installation) here), you don’t need to visit the Web site of the developer to log into your remote desktop. Instead, you will need to connect to your remote desktop directly, by entering its (current) Internet address into your Web browser running on your client. This means, for example, you don’t need to have an active Internet connection to access your remote desktop and that your connections will be always direct, meaning no additional slow-downs caused by routing your traffic (or parts of it) through third-party centralized servers. This, on the other hand, also means you won’t be able to access your remote desktop unless you know its address (which may be problematic if it’s using dynamic IP’s) and it isn’t behind a non-port forwarding firewall.
All in all, the main differences between RemotelyAnywhere and LogMeIn / GoToMyPC / I’m InTouch are as follows:
RemotelyAnywhere can be directly connected – no need to log in to the online LogInMe / GoToMyPC / I’m InTouch service. This means it can be used over strictly non-internet-connected LAN’s (for example, Wi-Fi P2P or BT PAN connections) too
as can be seen in the left frame of the browser on desktop PC screenshots, it allows for using a lot of other technologies for accessing; for example, Java or even HTML (the latter is pretty useless though as it’s only static images that this returns, not dynamic, editable windows). On the Pocket PC, these won’t work; however, the (there, by default HTML + JavaScript-based) remote monitoring features do and are wonderful.
This means there are definite cases when you will want to prefer RemotelyAnywhere to LogMeIn and the other alternates: if you need LAN-based login and/or better access to direct system monitoring. This, of course, comes with a price, which is about twice of that of LogMeIn Pro and the complete lack of HTTP(S) tunneling.
Screenshots: Login on desktop; the main desktop interface with a lot of additional info. On the Pocket PC, the login screen and the main menu (second page). As can be seen, it has a LOT of goodies, for example, a registry editor (second screenshot showing it can even create new entries, values (second screenshot) and, of course, modify existing ones). An example of the Services dialog. The system info window on the PDA (second page).
Note that it’s, protocol-wise, is compatible with LogMeIn Reach (also see the pricing info here).
1.1.4 I’m InTouch by 01 Communique
This, compared to other Web-based solutions, moderately expensive (annually, $99.95) solution is, as far as strictly the remote controlling functionality is concerned, doesn’t really have much to write home about. Not so with remotely accessing and searching (!) PIM data (Outlook and Outlook Express contacts, calendar, mails). This means you should pay special attention to this product particularly if you need remote access to your PIM stuff and e-mails.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(The remote viewer running on Pocket PC)
Note that they have two products: the $99.95 “Deluxe” version with remote control, file transfer, Web camera & PIM access capabilities. They also have a “Standard” version for half the price, which “only” offers mail/PIM access and wireless notification capabilities. (See this for the pricing information.)
Example screenshots: Remote mail; SMTP server setup; it uses its own login / password; the client loading on the Pocket PC. The Viewer also must be supplied a password; this may be different from the server password. It also supports stealth mode and contains an update module.
More info: A review of an earlier version is here. Note that the (moderately) high memory consumption (about 35 Mbytes) also mentioned in the linked review is, unfortunately, still true.
Verdict
Go give it a try if you want to have as easy remote PIM access as possible. Otherwise, for example LogMeIn Free may prove to be a bit faster, more responsive (and free).
1.1.5 Laplink Everywhere (LLE)
This is also a Web-based access service. I don't recommend it, not even for desktop PC client users, let alone Pocket PC users: its only advantage over the other reviewed remote controller solutions is the ability to access the remote desktop via Google Desktop Search directly on your Pocket PC, without your having to log into your desktop and without using third-party Google desktop proxy solutions like Project Computing’s Google Desktop Proxy or DNKA.
I haven’t included this title in the main chart because it entirely lacks remote control capabilities on the Pocket PC – it’s only on the desktop PC that it has remote control-capable clients. Furthermore, the Laplink Companion Client (the native Palm and Pocket PC client to remotely access E-mails on your remote desktop), as of version 1.1.412.812, doesn’t even start under WM5 and, under previous operating systems, while it does start, it can’t connect to desktops – it always displays the “Security negotiation failed” error message. (Also note that the Pocket PC client stores the username under [HKEY_CURRENT_USER\ Software\ Sproqit Technologies\ Client\ Settings\ {EE585C94-E44D- 4537-A003-B1B9E747A875}] and, it seems, it’s not possible to manually add new entries / modify existing ones. It’s set by ActiveSync; this means you must install the PPC client directly from the desktop you’ll later want to access.) Unfortunately, the Laplink folks still haven’t answered my mail so I don’t know whether this problem will be fixed or not.
1.1.5.1 The LLE Web client
The only functionality that works on the Pocket PC are as follows: the above-mentioned Google Desktop-based Desktop search, Internet Favorites and Files links; all accessible via a Pocket Internet Explorer-compliant Web interface (Web Login screen; main menu). Of these, I elaborate on the first and the third; the second only lists the Internet Explorer favorites stored on the remote desktop.
Desktop searching: it’s one of the best things as it utilizes Google Desktop Search. If you haven’t already installed it, the client will display an error message (2 3). If you have installed it, you will also have access to this functionality – without your having to use the remote desktop to enter the expression to search for and see the results as can be seen in here and here (the search results on my remote desktop for “iPaq”). After clicking an e-mail link, the results are presented locally as can be seen in here and here. Of course, the “View in Outlook” link won’t work on the Pocket PC version (see the error message here)
Files: file transfer. As it’s based on HTML (again, this is the only way for a Pocket PC user to access remote files on a desktop), the engine isn’t so flexible as native apps. It doesn’t have file upload capabilities – not even on WM5 devices (WM5 PIE already has file upload capabilities), as is, unfortunately, the case with all the other Web-based remote controller solutions too (except for I'm InTouch, which is promised to receive upload capabilities in the future). When you click a file link, the “Send File” button after the refresh will only let for e-mailing the given file, not uploading. Other screenshots of the file transfer module: WM5 download 1 2; WM2003SE filelist
1.1.5.2 Problems with LLE
As far as the remote control modules of the desktop client are concerned, they aren’t very fast. They’re constantly using a HTTPS gateway connection, don’t even try to utilize direct connections to speed up the transfer and is definitely slower than any of the four other, strictly Web-based applications. (In this netstat screen, you can also see there’s no direct connection at the client – everything has go through the LapLink server. This may be great for corporate users but not for users that have no or configurable / flexible firewalls but not very good when you could also utilize much faster and more capable direct connections too.) The user remarks here also backup this.
Unfortunately, LLE is the worst remote access software product in server CPU usage too (as with all HTTPS tunnel-based/enabled solutions, it’s in constant connection with the LapLink server): it’s been constantly between 2 and 11% on all the test Windows desktop PC’s I’ve tested it on. No other HTTPS tunnel-based/enabled solutions (or, for that matter, ANY server-side app listening to incoming requests) behaved this bad in my tests - ALL of them remained under 1% CPU usage.
In addition, it’s a REAL memory hog! The cumulative memory usage of all EXE files in \Program Files\Laplink Everywhere\ and another, in cases, as large as 95M (!) memory hog in the Desktop Agent subdirectory take about 120Mbytes in all – it’s an order of magnitude more than most of the alternatives!
Also, unlike ANY of the always-connected, HTTPS-capable alternatives, it’s the only app to generate a LOT of idle bandwidth; about 39kbytes uplink / 50kbytes downlink in five minutes; that is, about 18 kbytes combined traffic a minute. This is plain unacceptable if your remote desktop has an expensive connection (for example, a non-unlimited GPRS / mobile phone-based Internet access).
Furthermore, it doesn’t let for fine-tuning server-side settings either; this means you can’t, for example, fine-tune the color depth it uses.
Finally, a very important warning: the Web login screen is at https://www.ll2go.com. There’s a Web page at http://www.l2go.com/ (with one ‘l’), which displays a HTTP authorization dialog upon connection. DO NOT EVER enter your Laplink password into this box! This may be a username / password phishing service, which takes use of many users’ forgetting to enter two ‘l’’s.
1.1.5.3 Additional information on LLE
Pricing:
One computer, one hour/month access, annual license fee $44.95
Unlimited access vs one hour / month: +$50
License for +2 PC: +$30
Monthly fee (as opposed to annual): 1.38 times more
Example screens of the setup: 1, 2, 3, 4; the desktop client: 1, 2, 3, 4, 5; the (VNC) login screen (it’s rendered improperly if you use bigger system fonts as can be seen in here – attention users with for example UXGA(+) screens!)
It, internally, uses three protocols: its proprietary Laplink protocol, the standard RDP and, finally, VNC.
There are differences between the RDP and the Laplink mode (all in, of course, only available in the desktop client version); for example, Remote Control 4 doesn't support clipboard synchronization, while RDP does; the latter doesn't support sound redirection and file copying (not even drive mapping is possible, unlike in real RDP). Remote Control 4 only supports the default 256-color mode; the RDP-based module supports 16 and 24 bits too (high / true color).
1.2 Non-Web-based applications
There are several applications that, unlike the previously reviewed ones, don’t use a central Web server for keeping track of a computer and client log-ins.
Some of them are based on the RDP (Remote Desktop) protocol (used by Terminal Server / Services in the Terminal Services / Server line of Microsoft Windows and Remote Desktop by Windows XP Pro / Vista); some of them (VNC clients) on Remote FrameBuffer (RFB) and some use a proprietary one. In the following, I devote three subsections to these three cases. There are major differences between these three cases, which is worth elaborating on because they have a direct, at times, unwanted effect (for example, RDP-based remote controlling locks the current user out of the desktop and sets the desktop size to, as far as Pocket PC clients are concerned, either VGA (640*480) or SVGA (800*600) resolution) on the behavior of all the applications based on these protocols.
First, how these protocols compare? I’ve constantly been asked on these; therefore, I elaborate on this question a bit more.
First, the RDP protocol differs a LOT from all the other protocols and has a lot of restrictions. While it’s already installed and available on Windows XP Pro (and enabling it is just some clicks as is explained here), it has some restrictions none of the other solutions have:
When a remote session is active, the remote terminal can’t be used by anyone – they will be locked out
As far as Pocket PC clients are concerned, the desktops will be resized to either VGA (640*480) or SVGA (800*600) size. This (particularly the former) may be just too small for some kind of applications you’d like to run. Furthermore, you can’t extend your desktop to your external monitors (which is supported by many other remote controller solutions) either. This may also be a problem in some cases.
With Pocket PC clients, it doesn’t even let for starting applications that require any kind of sound output. This, in cases, may also result in problems (for example, when you want to start a remote playback of a sound clip or recording some kind of sound input.)
They don’t let for remote desktop shutdown / restart, which may be a pain in the back too.
While RDP has its drawbacks, it has advantages too; in addition to the above-mentioned availability in many Windows operating systems (without your having to install any server component – you only need to enable them with a single checkbox tick), the really good bandwidth usage (the current, version 5 of RDP is very well though-out, which is not necessarily the case with alternative protocols). Therefore, you may really want to compare its disadvantages and advantages to those of the alternates - in a lot of cases, RDP may be the best solution.
Second, the second most important protocol is RFB, which forms the foundation for VNC (Virtual Network Computing) clients. When properly configured, with the proper clients, VNC (from now on, I use “VNC” to refer to remote controller products using the RFB protocol) can be even more bandwidth-friendly than the above-introduced Microsoft RDP protocol. VNC clients don’t suffer from the above-listed problems of RDP either and, therefore, may be a much better choice than the built-in RDP under some circumstances (for example, when you don't want to lock out the current user while you remote control the desktop). They, on the other hand, require a separate one-time server install and also require some knowledge of the available encoding methods and server-side scaling (so that you know which menu item to select) to minimize bandwidth usage.
1.2.1 RDP-based applications
Unfortunately, on the Pocket PC, all RDP clients are pretty restricted, compared to the desktop Windows (or, for that matter, Linux) counterparts – or, even those on the WindowsCE.NET 4.1+-based Handheld PC version discussed here. The latter is far superior to that of any current Windows Mobile-based implementation. Unfortunately, so far, the excellent folks at the just-linked HPC:Factor haven’t managed to “hack” the Handheld PC version onto the Pocket PC. You, however, may want to subscribe to the thread to see whether there is new information.
Note that SmartCell’s RemotePlus still (?) hasn’t been ported to the Pocket PC. Hope SmartCell does it some day: Pocket PC-based Terminal Server / Services clients are all pretty bad and a decent alternative would be more than welcome.
1.2.1.1 Terminal Services Client (TSC)
TSC is built-in in most Pocket PC’s starting with the Pocket PC 2002 operating system. (If you still can’t find it, just download it here and just install it on your Pocket PC). It’s a really-really bare-bone application, really inferior to the above-mentioned WinCE .NET version linked above and not even capable of full screen; if you do need full screen capabilities, read the following subsection.
1.2.1.1.1 vijay555's full screen TSC hack
Well-known Pocket PC developer & XDA-Developers moderator Vijay555 has fixed the above-mentioned problem of TSC’s not supporting full screen mode (also see this XDA-Dev thread and for example some cache size hacks at post number #14 there.)
Get version 0.46b. It’s, fortunately, much easier to use than most would at first think. You need to do the following:
copy vjfullscreentsc.exe to your \Windows\Start Menu\Programs on your Pocket PC and start it
execute it again (or, just click the very small, newly displayed two gray circles in the screen, just under the Start menu; in this screenshot, the mouse cursor is just over them), a menu will come up; in there, select Fullscreen TSC
it will load the TSC client (click OK)
from inside, just log in to the machine you’d like to
from the menu, you can hide the SIP (in the previous screenshot, it’s visible in the bottom right corner and can be pretty annoying if you don’t need to enter anything; then, now that the scrollbars aren’t visible either, you’ll make use of the full screen estate as can be seen for example here); if you get rid of the scrollbars then, you can scroll from here, from a submenu.
Note that, on QVGA devices,
the horizontal scrollbar is invisible (because of VJFullscreenTSC’s assuming to be running on a VGA device)
you can’t scroll down entirely with the vertical one either (the bottom 320 pixels aren’t displayed because of the above-mentioned functionality). You can, however, do the latter from the menu (and, then, of course, you can disable the scrollbars entirely).
Otherwise, I haven't encountered problems on QVGA devices either.
1.2.1.1.2 The Handheld PC version of TSC
Back in 2001, before Microsoft has released the official Pocket PC client, many used the Handheld PC version of TSC on their Pocket PC’s. The way it was used is explained here and here. Note that it (H/PC Pro version) should be downloaded from here and not at the no-longer-existing URL listed in the article.
Logging into the client is pretty much the same as with any RDP-based solutions.
Its only advantage (unless you use the Vijay555 hack explained above) over the “official” TSC client for the Pocket PC is that it hides the upper task bar. Also, it has a “Low Speed Connection” checkbox (missing from the PPC version), which can toggle between 16- and 256-color modes. (No high-color modes are present.) Some of its problems (there are a LOT more!) are as follows:
It can’t be installed on WM5. It only works on operating systems prior to WM5 (I’ve done the tests on my VGA WM2003SE Pocket Loox 720)
The lower Windows taskbar won’t be visible. Note that this isn’t a hacked VGA issue (Program Files\Terminal Server Client\mstsc40.exe must be manually hacked to VGA); not even real VGA mode will help in this case as can be seen in here
You can’t issue right-clicks, unlike with other clients.
1.2.1.2 Mocha Remote Client 1.2 by MochaSoft
This is a commercial RDC client. While, GUI-wise, it’s certainly better than TSC, I can’t really recommend it because it’s based on the FAR worse version 4 of the RDP protocol, unlike the built-in TSC, which is RDP 5-based. Unfortunately, the older RDP version was far inferior to RDP 5, particularly communication bandwidth-wise.
If you, however, really need to stick to RDP and really need the advantages (compared to TSC) of this client (for example, excellent scaling and scrolling capabilities) and can guarantee you manually disable any kind of animations on the remote desktop, you may want to give it a try.
1.2.2 RFB-based (VNC) applications
Note that, after quickly listing the four different solutions, I also explain what needs to be known about different servers, encodings and server-side scaling. This knowledge will be essential in sometimes drastically decreasing the bandwidth needs of the applications. At first, I introduce the applications themselves.
1.2.2.1 VNC clients by Parys Technografx Ltd
Without doubt, Parys Technografx (PT) Ltd produces by far the best VNC clients for the Pocket PC. There are several of them; WM5 users will want to go straight for their latest product, Pocket Office (PO) – it offers the most for the money: it supports Tight (JPG), the most bandwidth-saving encoding protocol; it supports bidirectional (!) file transfers etc.
As far as strictly VNC clients are concerned, as has already been pointed out, PT PO has the best support for bandwidth saving (it supports the Tight encoding, along with JPG), has file transfer and is very snappy. Its usage can be a bit complicated for a newbie, but don’t be afraid: you’ll soon learn it. Just keep playing with the menus.
Note that the author of PT PO has told me may eliminate the need for manually setting whether the VNC server supports server-side scaling – automatic discovery already works in the free .NET VNC Viewer. He may also introduce automatic encoding handshake (as is the case with, say, the Mocha VNC client). He’s also working on making PT PO RealVNC-compliant (currently, it isn’t, unlike with the other Pocket PC-based VNC clients) and, finally, may also introduce clipboard synchronization (which is also supported by the RFB protocol itself).
Some example screenshots: Enter the IP; Password input; Download.
Verdict: if you want to go the VNC way (and aren’t forced to use the RealVNC server – remember, the current version of PT PO isn’t compatible with RealVNC), get this application – you’ll love it.
1.2.2.2 .NET VNC Viewer by Rocky Lo; 1.0.1.16
The free .NET VNC Viewer is better in some respects than PT PO. First, it has a more traditional interface, which is much easier for a newbie to comprehend. Second, it has automatic server-side scaling support (more on this later), unlike with (the current pre-release version of) PT PO. Third, it’s free.
However, it’s VERY-VERY SLOW as it’s based on Compact Framework. Therefore, I only recommend it if you only want VNC (not, say, a Web- or RDP-based client) and only want a free solution (where, for example, LogMeIn Free can’t be used because you prefer VNC as the remote protocol).
Also see this and this PPCT threads.
1.2.2.3 Mocha VNC 1.1 by MochaSoft
This title is definitely superior to the heavily outdated (RDP 4 only) RDP client of the same developer and, therefore, may be worth considering if, for some reason, you don’t want to go the PT PO route, but want to stick strictly with VNC clients. While it doesn’t support the most bandwidth-saving encoding methods (Tight (JPG)), the most compact compression method it’s capable of (ZRLE / Zlib) is still definitely better than that (Hextile) of the free, very slow .NET Viewer.
It’s very similar to the RDP client; in addition to the capabilities of that client, it has an encoding log, which is very useful when you would like to track down protocol-level errors.
It’s compatible with all major VNC servers; it’s only with PTeSVNC (the VNC server that’s bundled with the PT VNC client downloads – see SetUpPTeSVNC.exe) that it’s incompatible with.
1.2.2.4 VNC 3.3-only, not recommended VNC clients (Allware /Mark Midgley (alternate source) / Conduits )
The (unfortunately, still) most widely known and referred-to, very old and outdated, free VNC clients (that of Mark Midgley, Allware and Conduits) should all be avoided. They have really bad (non-existing) error handling, are only compatible with VNC servers in explicit 3.3 mode (and just silently die when they encounter a server that tries to communicate with something more up-to-date), are very slow and only know the not very bandwidth-friendly Hextile encoding. In a word: avoid them all.
Also see this BrightHand thread.
1.2.2.5 VNC servers
Now that I've quickly elaborated on the different VNC clients, let's take a look at the server side. Unlike with the Web- and RDP-based solutions, you must install a server on your desktop PC to be accessed.
There are several VNC servers out there with slightly different capabilities. As a rule of thumb, I'd go for UltraVNC - it is probably the most important, capable and recommended server, unless you use PT PO, when you should choose the included PTeSVNC instead (if you need seamless file transfers). Nevertheless, if you don't need for example support for server-side scaling, file transfer with PT PO, extended desktops or international characters, you may also want to go for RealVNC or TightVNC too. Finally, the fourth, really nice alternative is PTeSVNC, which is also free and is bundled with all PT VNC clients (also trial ones). It's really capable (except for the lack of extended desktops).
Fortunately, these four servers don't differ much as far as server-side configuration is concerned. That is, if you learn to use and configure one of them, you'll be able to do the same with the others too (except for some additional or missing options / tabs / checkboxes).
Note that if you plan to use PT PO, you may encounter screen refresh problems with Ultra (unlike with PTeSVNC) in all modes; for example, the upper rows in this screenshot. In this respect, PTeSVNC is a better choice. The developers are aware of the problem and may fix it in future versions.
In general, installing VNC servers are pretty straightforward. You install the product and just start the server in Start Menu / Programs on the Windows desktop PC. When it's running, it'll display an icon in the system tray (systray), through which you'll have access to the configuration dialog, user list and can even shut down the service.
1.2.2.6 VNC Bandwidth usage fine tuning
With a capable VNC client / server combo, you can fine-tune the bandwidth usage and force it to be really small – almost as small as with GoToMyPC in high/true color modes. This, however, requires you to know what options there are.
First, there are so-called "encodings" used with VNC. Some of them really love wasting bandwidth; for example, RAW, which, as you may already have guessed, just sends over uncompressed raw screen data and, consequently, takes orders of magnitude more bandwidth than protocols utilizing compression methods. Well-known, high-bandwidth and, therefore, to-be-avoided encodings also include RRE and CoRRE.
The widely used Hextile (the best available with the above-introduced, not recommended three free, "legacy" clients) is already a bit better but still consumes a lot of bandwidth and should, therefore, be avoided. With some additional compression (Zlib hextile, for example) it becomes pretty usable, bandwidth-wise: it will "only" consume about three times more bandwidth than RDP or more advanced (for example, JPEG-based) VNC encodings. Of the Pocket PC clients, only Mocha (and, of course, PT PO) supports Zlib / ZRLE compression.
Finally, Tight with or without JPG (the best, most space/bandwidth-efficient way to encode images) is by far the most effective VNC encoding. Of the Pocket PC-based clients, only PT PO supports Tight / JPG.
While CopyRect isn't strictly an encoding form but a way to tell the client "just scroll some of the old screen contents instead of downloading it again", it should be pointed out that it must always be enabled to (in cases - see for example the smooth scrolling examples below -, greatly) reduce bandwidth usage.
Other tips for PT PO: you may freely decrease the, by default, 1.0s update delay to say, 0.3 s - it will have almost no adverse effect on the bandwidth usage.
1.2.2.6.1 Server-side scaling issues
In addition to choosing the right encoding (at least Zlib / ZRLE and, preferably, Tight (JPG)), you should also know what server-side scaling is and how you can fine-tune it to further reduce bandwidth usage.
First, remote desktops are, generally, bigger than the resolution of your Pocket PC screen. For example, my notebook has an UXGA (1600*1200) screen, which is far larger than even the VGA screens of some of my Pocket PC's. If (and only if!) you don't zoom into this image fully and scroll around the page so that a pixel on the remote desktop equals to a pixel on the Pocket PC, you can make use of clever desktop-side (!) rescaling of screen images before (!) returning them to the client. Just imagine: if you would like to just navigate on a 1600*1200 desktop with your VGA screen, by instructing the server to resize the screen images returned to the client itself, you can save a LOT of bandwidth. For example, if the server uses the rescaling factor 2, then, it'll send over 1600/2 * 1200/2, that is, 800*600 images, which are still bigger than the VGA screen and, therefore, onlly result in very small image quality degradation - while delivering considerable bandwidth usage decrease. Using the scaling factor 3 with the above-mentioned UXGA desktops, the full screen images sent over will become 1600/3 * 1200/3; that is, 533*400 in size. Of course, this will introduce some kind of blurriness - but the bandwidth advantage will be considerable.
Note that, currently, VNC servers are only capable of using integer scaling factors - that is, you can't. This is why you can't just tell them "with a UXGA remote desktop and a VGA client, use the rescaling factor 1600/640, that is, 2.5 so that you get the most optimal result with the best possible image quality".
Some real-world benchmark results to show all this (PTeSVNC server, 1600*1200 desktop, VGA portrait client, Tight NO JPG, server scale 1:2; all data are in Mbytes; the smaller, the better):
CLICK HERE for the VNC chart!
In Landscape, using the above configuration (UXGA desktop, VGA client), using UltraVNC, some other benchmark results:
Server scale 1:4, no smooth: 310k
Tight JPG max speed, server scale 1:2: 550k
Tight JPG HQ, server scale 1:2: 570k
Tight No JPG, server scale 1:2: 560k
Tight No JPG, server scale 1:1: 780k
Finally, SVGA (800*600) desktop, VGA landscape client, with smooth scrolling on:
1:2 Server Scale on: 1.33
Scale off: 1.95
As can be seen, server-side scaling, while it does introduce some kind of blurriness (example screenshots of this later), really reduce the used bandwidth: with a two-factor server-side resizing, about 35..45%. Also, as can be seen, fine-tuning the JPEG quality parameters (or, for that matter, completely disabling it) in Tight mode of PT PO doesn't really result in considerable bandwidth savings.
Finally, some examples of the quality degradation:
1:1
1:2
1:3
1:4
As can clearly be seen, the quality slightly degrades even at the rescale factor of two. That is, there is a clear tradeoff between quality and speed. You will want to use / configure the server-side scaling feature in VNC clients (.NET Viewer and PT PO) that directly allow for configuring this wisely.
1.2.3 Other applications
1.2.3.1 z2 Remote2PC 1.2 build 1205 by z2 Software
z2 Remote2PC is a very famous Pocket PC remote controlling solution. It is generally really solid and its only problem is the definitely higher bandwidth consumption compared to most other alternatives. It doesn't support HTTPS either; in a fully firewalled environment, it may prove less useful than Web-based solutions like LogMeIn, I'm InTouch and GoToMyPC. It does support callbacks to combat this, but the latter requires some manual configuration and, in this mode, can't be used with also-firewalled clients. If these aren't an issue (you won't be, for example, accessing your desktop via slow and/or expensive lines and won't trey to access your firewalled servers from an also firewalled/NAT'ed client), I highly recommend this application.
Reviews, threads: Thread on 1.0 (note that some users call it even faster than TSC – this is certainly not the case); PocketNow. Also see this and this
1.2.3.2 pcAnywhere 12.0 by Symantec
The PPC version is 2.0.0 build 121; note that the 2.0.1 update refuses to run. The trial 12 beta download (direct link here and here. Megathanks to akheron for the latter link!). The Mobile client CAB is also available here; I haven’t tested this myself.
This is another all-in-one remote controlling solution. While it does have its strengths (for example, clipboard synchronization, which is only supported by very few other solutions, and connections even through serial links - that is, not necessarily TCP/IP-based ones), in general, I can't really recommend this solution. Remote controlling / access-wise, there are much more sound, powerful solutions with a much better price/performance ratio and bandwidth utilization (another area pcAnywhere doesn't really excel at).
Example screenshots: After, on the desktop, starting Start / Programs / Symantec pcAnywhere, you’re presented this dialog. Here, you can connect to other computers, start file transfer (as can be seen, file transfer, as with all the other Pocket PC and unlike some desktop solutions, must be initiated from here and not from a remote desktop session) and start hosting.
Starting the server on one’s computer: 1 2 3 (as can be seen, you can use your Windows login credentials) 4 5 6.
An example (desktop) screenshot of remote controlling a session
More info here and here.
1.2.3.3 RemoteControl by CrossTec Corporation; 10.0
This cross-platform solution isn't just a remote controlling applications, but also offers a lot more functionality, mostly geared towards the enterprise. This, on the other hand, also means there isn't even a price quoted. This may mean you won't want to prefer this title over the other ones if you "only" want to have a remote controller only for your desktop, unlike with the case of deploying it to your entire enterprise. That is, you should only check out this solution if your entire enterprise wants to switch to it; then, however, you will also want to take a look at alternative and, when deployed to the entire enterprise, really decent solutions like NetOp Remote Control.
As with NetOp Remote Control, the desktop PC client supports for example direct client/server voice chat (like Microsoft Netmeeting!) for, say, remote Customer Service purposes; the Pocket PC version is much dumber. To see the differences between the desktop and the Pocket PC clients, check out and compare the docs (just start the EXE file and pass it a dot (.) as the decompression directory target); it’ll extract some (2 with the Windows and 4 with the non-Windows case) PDF files to the current directory): desktop Windows; Pocket PC, Mac and Linux.
Some screenshots: installing (2); server-side configuration: TCP/IP HTTP (for gateways!); mobile client install (2); desktop client; file transfer.
It has two transfer modes: GDI (which can only be used in high-color mode; otherwise, it'll mess up bitmap resources as can be seen for example in here; the CrossTec folks are avare of the problem and will, hopefully, fix it) and the traditional, simple screen scraping. Unfortunately, there really isn't much bandwidth usage difference between the two modes (one would expect the GDI version to be much more bandwidth-friendly).
1.2.3.3.1 Vector PC-Duo Remote Control 9.60 by NetSupport Ltd
You'll find numerous references to the Vector PC-Duo Remote Control product line on Pocket PC boards. This product line has been discontinued and replaced by the above-introduced CrossTec product and, therefore, should be entirely ignored. Don't even try to install, say, the PPC client trial (version 9.0): it will complain about an old license. The nsm.lic file in the home directory of the application states the trial should expire in September 2005; still, not even setting the date back not to cause problems helps, the app will always complain of the license file being missing or invalid. Interestingly, the readme.txt of Vector PC-Duo Remote Control states the Pocket PC version supported even File Transfer and Registry Editing. The later CrossTec RC 10.0, interestingly, doesn’t support this.
Some screenshots: On installation, you can choose between the different deploying options; for example, it’s here that you can opt for installing a gateway. (Note that it refers to hosts as “Client” and clients as controls, as with the Crosstec product.) GUI-wise, it is pretty similar to CrossTec 10; see for example the icons, the setting capabilities etc here and here. The menus are also the same.
1.2.3.4 NetOp Remote Control 9.0 by Danware
(mobile); (PPC guest version 8.00)
This product, as with the above-introduced CrossTec RemoteControl, is also a typical enterprise-only remote controller application, offering far more functionalities a non-enterprise user would ever need (and not offered for individual users: the minimum number of deploy hosts you can order it for is 100). Check out the description of the desktop and mobile versions for what it's capable of. In here, therefore, as with the CrossTec product, I only scrutinize it to see whether it's worth sticking to as a remote controller product - an enterprise system administrator in charge of deciding for a complete remote management / help / controller application deployed for the entire enterprise should use a much more broader approach in comparing not strictly Pocket PC-based controlling facilities.
First and foremost, let's get some facts straight: there are two related product lines in the NetOp line. The former, NetOp Remote Control (NRC) for WindowsCE (including Pocket PC / Windows Mobile clients), has been discontinued and is the only to contain a Pocket PC remote client; the latter, NetOp Mobile & Embedded (NME), only has a Pocket PC-side server component (like that of Pocket Controller, dotPocket, MS PowerToys etc. - see this already-linked article for more information). While the two products do work with each other (that is, you can use the old Pocket PC client with the new remote desktop-side component), the NRC 8 (the latest Windows Mobile client available) Pocket PC client is entirely incompatible with WM5.
Danware promises a WM5-compliant, real Pocket PC NME client in Q2 of this year. Up until then, it's only with Pocket PC's using previous operating systems will be able to access remote NetOp desktops.
As far as the general behaviour of the strictly Pocket PC-based remote controlling is concerned, it doesn't have much to write home about; for example, the bandwidth usage results are pretty bad. However, as has been pointed out, this product suite (as with that of CrossTec) should not only be evaluated as a mere remote controller tool: it's capable of much more when deployed in an enterprise. It's just that an individual user with a Pocket PC (and not a, say, notebook or UMPC running desktop Windows and, therefore, using the fully-fledged, great and capable NetOp NME client) won't necessarily want to prefer NetOp to the alternative, on the Pocket PC, much more capable and much less bandwidth-wasting solutions.
Some screenshots: Connect to host (2); desktop client setup 1 2 3 and configuration 1 2 (notice the plethora of usable protocols and the excellent server-side capabilities!); desktop guest in action. The WinCE host looks like this. It, however, also has a desktop configuration component. The setup of the latter (it’s only this that you can, for example, set your password) is as follows: 1 2.
1.2.3.5 Soft Agency Remote Desktop 2.0
The official homepage of this very old and outdated, commercial proprietary remote controller application isn’t accessible any more. Not that it'd be a problem: I don’t recommend this controller at all.
It has very few advantages and the list of its disadvantages is very long. Some screenshots: entering IP; add a user manually into the server (this must be done before the first connection)
1.2.3.6 BitWeen S.R.L. Remote Control 1.1
(alternate source)
This is another highly outdated and in no way recommended remote control application. It's highly overpriced ($49.95) for what it's capable of.
1.3 Haven’t tested
1.3.1 ICA client ny Citrix
(also see this page)
Unfortunately, it’s really a MetaFrame Presentation Server client and isn’t able to speak RDP, “just” ICA, the native protocol of MetaFrame. Therefore, a casual Pocket PC user not having access to the enterprise-level MetaFrame Presentation Servers will not be able to use it to access his own desktop computer - only server farms.
2. Feature / benchmark chart
It's available here. Due to sheer size, I couldn't include it in here - sorry. You'll need to click the link.
2.1 Explanation for the chart
Generic compatibility issues group: everything about operating system: which Pocket PC and desktop operating systems it's compatible with; does it support high-resolution VGA screens. Note that all products support Landscape orientation screens; this is why I haven't listed it in here.
As far as Pocket PC operating system compliance (see the OS compatibility: PPC row) is concerned, I've tested all these products on at least one (MIPS) Pocket PC 2000 (when the given application did have a MIPS version), PPC 2002 (I've tested for PPC2k2 compliance even with applications that are, officially, not PPC2k2-compliant and found out that some, only as WM2003+-advertised application is also PPC2k2-compliant), Windows Mobile 2003, 2003 SE and Windows Mobile 5 devices - that is, all the major Pocket PC operating systems. Note that, in the chart, PPC2k2+ means all operating systems starting with PPC 2002 and WM2003+ means all operating systems starting with Windows Mobile 2003.
Other OS’es : you will want to consult this row if you plan to access your desktop from non-Windows / non-Pocket PC clients too. Several applications / protocols have clients for non-Windows desktops too; the two most important examples being VNC (with clients for all flavors of Unix operating systems) and RDP (there are RDP clients for all alternative operating systems, not only Windows - for example, rdesktop under Linux). Some of the other products also have Linux / Solaris / Mac OS clients; for example, pcAnywhere, CrossTec Corporation's RemoteControl and Danware's NetOp Remote Control. This is really worth knowing if you plan to access your desktop computer from a wide variety of platforms. As can be seen, as far s strictly Web-based technologies are concerned, a RemotelyAnywhere is hands down the best and most compatible.
VGA support?: as can be seen, there are no products that wouldn't support high-resolution VGA screens. Some of them, however, must be "hacked" into this.
Bandwidth usage group: I've made some really extensive tests to find out how each and every remote control solution uses bandwidth. These tests are, therefore, of paramount importance if you
Have a very expensive (for example, mobile phone-based) connection, where every byte counts
Have a slow connection and would, therefore, welcome the fastest possible solution
To reliably and comparably (!) benchmark the different remote controller solutions, I've done the following:
I've created a Wi-Fi connection (through an external access point to avoid not being able to connect to the freshly booted-in desktop / being disconnected because of locked-out users, as is the case with RDP) between my freshly hard reset (no background tasks requesting information off the Internet) WM5-based Dell Axim x51v and my notebook (an IBM ThinkPad a31p with a 1600*1200 UXGA screen). I've used the x51v for this task because its Wi-Fi applet also lists the sent/received bytes as can be seen in this (received bytes) and this (transmitted bytes) screenshots. For some other measurements (most importantly, ones that did require a pre-WM5 device; for example, the NetOp tests), I've used a direct Bluetooth Personal Area Network connection between my Pocket Loox 720 and my notebook. The Widcomm Bluetooth stack also reliably displays the number of bytes sent (that is, the so-called uplink bytes) / received (downlink bytes). Finally, with one application (PT PO), after finding out the multiplication factor (1.33) between the internal data counter it displays and the real bandwidth usage (the latter is higher because of the additional protocol / communication overhead), I've used the built-in counter available in the main menu, under Connection Statistics (screenshot here).
I've switched the desktop resolution to 800*600 (SVGA) on the notebook (note that a, I've also made tests in UXGA (1600*1200) and, with I'm InTouch to find out the speed issues, all possible, settable resolutions between; b, remote controllers that did override this setting - for example, TSC - have overriden this to VGA (640*480) or, when I've chosen no scroll-mode, even less.
I've automatically scrolled through a looooooong test HTML document (my well-known Pocket PC Gaming Bible Part I without the PPCMag header/footer), with disabled smooth scrolling and ClearType by default (in two another tests, I've enabled them both to see how he protocol handles smooth scrolling events and whether it disables ClearType to increase the data transfer efficiency). To automatize scrolling (and also to reiably find out the rendering time of each and every page), I've used My Macros V2.0 by GoldSolution Software. With this application, it's very easy to simulate user input (in this case, pressing the Page Down key) and waiting for a pre-determined time - please also see this screenshot. The latter also helped me to find out the minimal delay between subsequent page down events for the current page to be completely rendered by the client; in the chart, I've sometimes also noted these results as, for example, "600ms delay" or "scrolling delay". By default, I've used a 2-second delay in SVGA mode; in general, all clients were able to keep it with this (except for the very slow .NET Viewer, where I had to increase this to some 8 seconds).
by substracting the bandwidth usage figures after and before starting the full scroll-through, I got the full bandwidth usage of page scrolling.
Note that, during the scrolling, I've paid special attention to not letting the notebook do any additional animation (for example, animated icons in the system tray or MSN contacts / Outlook mail notifications - I've disabled all these applications) and also made sure the mouse cursor was also hovering over the title bar of Internet Explorer, not displaying any additional tip bubbles and not moving at all.
Also note that these results are, generally, an average of several tests. I've often re-run the tests in order to be absolutely sure I'm right, particularly when discussing the results with the developer.
In subsequent tests, I've repeated the test above, in a slightly modified environment; for example, I've switched on ClearType, smooth scrolling, changed the desktop resolution and/or modified the color depth (in the client); all this to see how modifying these parameters affects the bandwidth usage of a given remote control solution. These additional tests delivered a lot of important results, which I've also elaborated on in the tests.
Generally: 8 bit (with Tight VNC, 16 bit), 640*480 (with RDP) / 800*600 (with everything else), no smooth scroll: the bandwidth usage of fully scrolling down the test page in a highly controlled environment, using the a desktop resolution of SVGA (800*600) (with TSC, VGA (640*480)) and the color depth of 8 bits.
It's really worth checking out the results. In addition to the numeric results (the bandwidth usage in kilo / Megabytes), I've also compared these results to the bandwidth usage of the alternative solutions.
File transfer benchmark: with remote control solutions also supporting file transferring, I've also run benchmarks to see whether it uses binary transfer or, similar to, say, how binary content is transcoded to ASCII text to be transferred via E-mails, does it introduce any kind of overhead. I've also benchmarked the file transfer speed to see whether there are major problems with a given application. Note that, with HTTPS tunneling-capable applications, I've made these tests in HTTPS tunneled mode - that is, without direct connections - to see whether the online service is able to transfer even big files without severe slowdowns or crashes.
For this test, I've used a 24.6 Mbyte file. As can be seen, none of the file transfer-capable applications added considerable overhead to the file transfer - even the biggest overhead (that of z2) is much smaller than the overhead of, say, E-mails. I haven't encountered slow file transfers either. This means you can safely go for any of the file transfer-capable solutions, all work great, file transfer-wise.
Based on which protocol?: in here, I've elaborated on what underlying protocol the given remote control application uses. As can clearly be seen, there are three groups: RDP-based ones (with the Mocha client using, unfortunately, the outdated RDP4), RFB (VNC)-based ones and proprietary ones.
Sensitive to smooth scrolling and other animations? (Doesn’t support CopyRect and the like?): in these tests, I've enabled smooth scrolling (in IE7, Tools / Internet Options / Advanced / Browsing / Use smooth scrolling) to see whether the server component of the remote controller is able to catch "simple" scrolling events (that is, where you only communicate to the client the rectangle that was scrolled and the amount it was scrolled by, in addition to the newly-introduced content). In VNC / RFB terminology, the support for this is referred to as CopyRect.
Note that this test not only applies to Internet Explorer's smoothly scrolling Web page contents, but also any kind of similar animations. Testing the behavior of the remote controller application is of paramount importance - if you don't disable all kind of scrolling like this (and the application doesn't do this for you - several do, as will be seen later), you may end up having seriously degraded remote controlling performance.
As can be clearly seen, remote controller applications behave wildly differently in cases like this. RDP 5-based applications (for example, the Terminal Services client built into the Pocket PC 2002, WM2003, WM2003SE and WM5 operating systems) and LogMeIn don't have any problems with such contents. However, the situation isn't this good with other protocols and even the older (4) version of the RDP protocol: with the latter, the bandwidth usage dramatically (with orders of magnitude!) increases and the responsiveness of the remote control equally dramatically degrades. While, for example, GotoMyPC suffers from a 20-30% and the RFB protocol (used by VNC) exhibits a 50% bandwidth increase, other applications have decidedly worse results. I’m InTouch and CrossTec's RemoteControl exhibit a 100% bandwidth increase and, finally, NetOp Remote Control 9.0's bandwidth usage increases by about an order of magnitude.
… that is, does it send over all the changed screen contents or combines them? (The latter approach is much better): it's an easy-to-understand fact that remote control applications can't keep up with the remote desktop when the latter changes really frequently (for example, while playing a video or quickly scrolling through a document), content rendering-wise. In there cases, there can be two approaches. One approach tries to send over all the changed screen contents, using a very big frame buffer; the other approach, when seeing that the client can't keep up with the content changes, simply drops the interim frames and, in cases, only sends the frames to the client that it can safely render.
Naturally, the latter approach is much better. We've already seen the problems (at least an order of magnitude more bandwidth used and greatly slowed-down client-side rendering) caused by the former approach with both RDP 4 (see Mocha Remote Client 1.2) and NetOp Remote Control 9.0. However, the contents of this row shouldn't be a showstopper if you, in general, don't generally watch animations like this (for example, a splash screen gradually fading in/out or the above-mentioned smooth scrolling in a Web browser) over remote controlling sessions.
Bandwidth increase along with true/high color modes?: while the first test in this group used 8-bit color depth (the default color depth for most remote controller applications, except for the JPEG-based Tight VNC modes, which are 16-bit by default), I've also examined how enabling high (16-bit) and, in cases (with desktop clients - the Pocket PC, having "only" a 16-bit color subsystem, can't operate in 24-bit true color mode) true color modes effect the bandwidth usage. As can be seen, the bandwidth usage only increases by between 20% and 66% in high color (and slightly more in true color), the better protocols, in this respect, being RDP 5, GotoMyPC and LogMeIn.
Under-8 bit modes, if any?: I've also benchmarked under-8-bit color depth modes to see whether you can gain significant advantage (and reduced bandwidth usage) by employing modes with fewer and more coarse colors. As can be seen, the results are pretty mixed: with remote controller applications that do support for example 2, 4- or 16-color modes (1 / 2 / 4 bit color depth, respectively), in general, (really) reducing color depth won't help much. Using LogMeIn in 4-bit mode will not help the overall bandwidth consumption (and also resizes the remote desktop to VGA size (640*480), which you may not want); z2 Remote only marginally (7%) benefits from a 16-color mode. That is, you shouldn't suffer with low-color modes with these two remote controllers because it won't deliver lower bandwidth usage. It's only CrossTec's RemoteControl that does benefit from switching to a low (in this case, 2-color) mode; then, its bandwidth needs will then be greatly reduced.
Bandwidth usage when nothing happens (absolutely no changes on the desktop and no client-side input)?: so far, I've tested the bandwidth usage when scrolling through a document. However, this is only test case of the many possible test cases modeling a remote user's behavior.
Another test case, particularly to test whether a given protocol is well-constructed and not (unnecessarily) bandwidth-wasting is an "idle" test: to test how much traffic is generated by just rendering a non-changing desktop. Ideally, a remote controller application shouldn't generate any traffic in this case. Unfortunately, while most applications behave OK in this respect, there are some that do generate some traffic even in these cases; most importantly, the, otherwise, excellent GotoMyPC. The not-that-recommended pcAnywhere 12 has produced some very bad results.
Finally, note that it's here that I've also elaborated on the exceptionally bad bandwidth usage of I’m InTouch with the cursor blinking in the Internet Explorer address bar. In general, bandwidth usage of other protocols with similar "a cursor is blinking" case was pretty low (at least, that of RDP 5, in which case it was close to negligible); with I’m InTouch, I've measured some 340 kbyte / minute additional traffic in this case. This is much higher than just transferring plain screen contents; hope the excellent and really responsive folks at 01 Communique will fix this problem.
Support for server-side scaling (as opposed to client-side scaling down of full-resolution images)?: in the VNC / RFB chapter above, I've already elaborated on the advantages (and disadvantages) of server-side scaling (that is, server-side resizing of the image returned to the client) to save bandwidth. In here, I've elaborated on whether the tested applications use server-side scaling or not. Note that, as most of them use proprietary, closed protocols, I needed to base this row on my measurements (UXGA vs SVGA scrolling results) and, with the I’m InTouch entry, the developer's statement.
Image fetch model in panned (scrollable) mode: full image download, including currently not visible regions? : if you don't use the full-screen mode to see everything on your remote desktop, which is pretty likely on particularly QVGA clients (as opposed to VGA ones), you can save up bandwidth with clients using a protocol that only communicate the currently visible part of the desktop (the viewport). As can clearly be seen, very few applications / protocols support this advanced functionality. Note that, however, if you usually use full screen modes (on a VGA Pocket PC with not much larger remote desktops, this is pretty usual), the lack of non-progressive download won't have any consequences as you will always download the entire screen, no matter what kind of application you use.
Also note that, if you decide for VNC as the backend of your remote control infrastructure, you can configure all the VNC servers to return only, say, the current window, not the entire desktop (the latter is the default setting). You can also make use of this advanced feature of VNC to further reduce bandwidth usage.
Caching of overlapping windows?: advanced remote controller apps / protocols also integrate in the server desktop in a way that they allow for caching not only content to communicate, say, scrolling events in a bandwidth-friendly way, but also overlapping windows.
RDP 5 is a perfect example of such a well-designed protocol. When you expose a window, the client will render its contents from a local cache if its content hasn't changed in the meantime. This dramatically reduces bandwidth usage if you often switch between different tasks.
RFB (the protocol of VNC), unfortunately, doesn't support this functionality; neither do any of the enterprise-oriented trio (pcAnywhere, CrossTec RemoteControl and Danware NetOp Remote Control). The Web-based applications (except for I'm InTouch) do support this, GotoMyPC being the best and the RemotelyAnywhere - LogMeIn duo considerably worse (but still much better than any non-caching solution). Finally, RDP-based solutions (even the RDP 4-based Mocha client!) really excel in this area.
Bandwidth usage of maintaining the persistent connection with HTTPS-capable services: in the section on LapLink Everywhere (LLE), I've already pointed out LLE has severe problems with the idle server-side bandwidth usage - that is, when no clients are connected and the LLE processes "only" maintain an active connection with the central LLE server located on the Internet. LLE consumes, for mobile phone-based users, considerably bandwidth (about 18 kbytes a minute) even in this case. This is why I've made some very extensive tests to find out how the HTTPS-capable (that is, in this case, Web-based, except for RemotelyAnywhere, which doesn't have a central server) alternatives behave in this respect. Fortunately, none of the three HTTPS-enabled services exhibits so bad a behavior.
Note that, in here, I've not only listed the idle server bandwidth, but also the bandwidth usage of the initial log-in (after you start the service). Fortunately, this is pretty low too.
Other bandwidth benchmarks of interest?: in here, I've listed for example my UXGA benchmark (document scrolling) results.
Initial bandwidth usage: Loading all non-visible windows upon connection?: while RDP, in general, is very bandwidth-friendly and only GoToMyPC / Tight JPG VNC beat it in this respect (the latter not using smooth scrolling and not taking into account caching of hidden windows), it has an, in cases, very annoying feature: upon connecting to a remote desktop, it will load the contents of all the visible windows (and the desktop too), even hidden ones (ones in the background). This can lead to a lot of unnecessary bandwidth usage and slowdowns upon connection.
In these tests, I've scrutinized whether the given remote access solution does the same. Fortunately, none of them does.
This means if you always have a lot of non-minimized windows in the background and you do want to reduce bandwidth, either make sure you minimize them (instead of just letting other windows hide them) and only let the current window to be displayed or use a remote control solution that doesn't load all hidden windows upon logging in.
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 (it's 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) upon logging in to, in cases, greatly reduce bandwidth usage.
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, the 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 given ports to your 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 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.
Where to navigate to to log in?: in here, I've elaborated on where the client must be pointed to or, if it's a Web-based remote controlling solution, where the Pocket Internet Explorer browser on the client must be pointed 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 like this.
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 do. Even better ones (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.
Shutdown?: RDP-based remote controllers all have a very annoying problem: they don’t allow for shutting down / restarting the desktop, as is also shown in the TSC screenshot. All the other remote applications, fortunately, do. This also means if you need to remotely shut down / restart your desktop, don't use RDP-based solutions but anything else.
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:
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.
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 accessing 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 series) 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.
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 such 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; 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.
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.