Database Info

DEFINITIVE ROUNDUP: Access your desktop PC from your Pocket PC!

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.

Browsing the Web on MS Smartphone (WM Standard) devices & Review of Opera Mini 4 beta

Browsing the Web on MS Smartphone (WM Standard) devices & Review of Opera Mini 4 beta
UPDATE (08/17/2007): a new version is in the brand new, general Smartphone forum HERE. That is, go there to read the latest version of the article. I, however, keep this version of the original article because of the responses.
(end of update)
In my recently-published, well-known Windows Mobile Web Browsing Bible I’ve elaborated on how Pocket PC’s can be used to browse the Web. Please make sure you DO read the review even if you don’t have a Pocket PC. You will learn a LOT from there and, in addition, I do NOT elaborate on many questions like Web standards compliance or additional Opera Mini features in here. In the current review, I “only” elaborate on questions ONLY concerning the MS Smartphone platform. The only exception is the review of Opera Mini 4, which is a generic one and can be used by Pocket PC users as well.
Now, it’s time to review
how you can do the same on MS Smartphone (Windows Mobile Standard) devices (SP for short); what browsers you should use, what bugs you should be aware of etc.
the brand new and REALLY NICE, HIGHLY recommended Opera Mini 4 platform. This section will be of interest to not only SP users, but also those of the “big brother”, the Pocket PC – and, for that matter, any Java-capable mobile phone.
As you’ll see, on the SP platform, there’re far fewer really usable browsers and there are (currently) absolutely no Java and real Flash support. This, fortunately, makes one’s life far easier – generally, you only have three browsers to select from: either Opera Mobile, Opera Mini or the really promising newcomer, jB5. The two Operas are, as you may have already guessed, generally superior to the built-in Internet Explorer Mobile.
However, let’s start with the latter as it comes built into the operating system of all SP devices.
1.1 Internet Explorer Mobile (IEM)
Unfortunately, the SP version of the built-in IEM, even as of Windows Mobile 6 Standard (that is, the latest SP operating system version), is considerably inferior to the Pocket PC (PPC) version shipped with WM6. For example,
while the PPC version of IEM has received file uploading capabilities some two years ago (with the initial release of WM5), not even the latest, just-released, WM6 version of IEM is capable of the same as can be seen in HERE (showing the results of my traditional file upload test page – see the previously linked page for more info on what the screenshot should show). Note that the SP version of Opera Mobile has no problems with file uploading (1 2 3 4)
it also has major problems with some HTTP / scripting constructs never having caused any problems to the Pocket PC brother; most importantly, it has problems with posting to Smartphone Thoughts and Pocket PC Thoughts forums from IEM. (The PPC port of IEM has no problems with posting to these sites; neither do Opera Mobile and Opera Mini on the SP platform.) Interestingly, this is NOT a problem on several models (even including WM6 ones) - and, in some occasions, it even worked on my Vox. I don't know why - it probably depends on the size of the message. Also see for example Mike Temporale's posts and links in THIS thread.
it doesn’t support tabs and, as you may have guessed, none of the known, Pocket PC-only PIE / IEM enhancers (MultiIE, PIEPlus, Spb Pocket Plus, ftxPBrowser etc.) work.
just as on the Pocket PC, you can’t make use of the hardware buttons (except for the “Back” button) AND the dialpad buttons (except for the 2/4/6/8 buttons for page scrolls) of your Smartphone. In this respect, both Opera Mini and Mobile are better. Fortunately, the most common functionalities are accessible, in general, with two or three (depending on whether you start from full screen mode) key presses. Fortunately, there are some registry hacks that - at least to a certain degree - fix this, which I’ll later, in a subsequent section, elaborate on.
download-wise, it’s really different from the Pocket PC IEM: it’s only CAB files that can be downloaded (if at all – see later), nothing else. This is in stark contrast with both the PPC version and Opera Mobile on the platform, which uses the same, vastly superior download-specific code as the PPC version. You must do some manual, extensive Registry editing to fix this problem - and, even then, you will need to do this for each file type you'd like to see downloaded. I too address this issue in a later section.
Note that isn’t not only files that have no local, associated programs to operate on are refused to be downloaded, but EVERYTHING, even registered and, by default, supported file types like ZIP and PDF files (fortunately, Office files are supported if your device does contain Office Mobile – an example of an XLS file is HERE).
Some examples of these cases:
non-associated RAR files (for example THIS). Upon trying to download files like these, you get THIS error message (unlike with Opera Mobile).
PDF files with the, on the HTC Vox, associated, built-in Adobe Reader LE. An example PDF file is HERE
ZIP files, like THIS, associated with Resco File Explorer.
Furthermore, the old problem with CAB files served as of unknown type is present in this version too. For example, while THIS CAB file is server as binary and, therefore, offered for download, THIS one, which is returned as of unknown (text/plain) type, results in the well-known, useless textual representation (while Opera Mobile downloads it just fine). The CAB problem has always been a major problem with the PPC version as well, as is also explained in the Download Bible.
Note that I’ve also had downloading problems on my WM5 HTC s310 (Oxygen) upon trying to download a 2.5M Byte CAB file (the Smartphone version of Opera Mobile HERE) via an EDGE connection. No matter where I tried to store it (the device had about 10M free built-in storage), the transfer would stall at 300-600 kbytes (I’ve tried to download the file several times), while, under exactly the same circumstances (the same network coverage, the same file etc), my WM5 HTC Wizard Pocket PC downloaded the file without problems. I haven’t encountered similar problems on my WM6 HTC Vox (s710). I don’t know whether this was a temporary problem or generally a problem with WM5 SP IEM’s over slow(er) connections and large(r) binary (in this case, CAB) files. Just keep this in mind if you have similar problems.
As far as the WM6-specific fixes are concerned, the WM6 SP version of IEM, fortunately, supports iframes as can be seen in HERE. (It’s suffering from the same width problem as with the PPC version, though – even in Single column mode. This isn’t an issue on Opera Mobile and Mini.)
All in all, I do not really recommend IEM for regular Web browsing on SP’s if you don't apply the above-mentioned (and below-explained) registry hacks. Go for either Opera Mobile (which is, as far as the new, 8.65 beta is concerned, free until Oct. 1. Of course, being free until October doesn’t mean you shouldn’t support the company – do purchase for example their 8.60 version to support their continuous efforts to give us the BEST Pocket PC, Smartphone and, in my opinion, desktop Windows browsers) or the absolutely free and excellent Opera Mini.

1.1.1 Fixing the binary file download problem
The difference between the SP and the PPC version of IEM is pretty simple. While the latter doesn't require a given file type to be registered in the local Registry to be downloaded, the former does, and also requires a specific flag (the fifth "bit" in EditFlags) to be set to one.
This is why "unknown" file types like RAR or known file types that don't have the EditFlags value are refused to download. You can, fortunately, fix it. In here, I describe both the manual and the automatic, much easier way of doing this. The former includes heavy Registry editing, but might prove useful in cases you'd like to allow for downloading more file types than the automatic way offers.
1.1.1.1 Manually enabling downloding a given file type
Let's assume you want to enable ZIP file downloading. To do this, first, you have to fire up a registry editor (I recommend that of Resco - it's well worth the price).
First, as ZIP files end in .zip (that is, have the file extension 'zip'), you need to navigate to HKEY_CLASSES_ROOT\.zip to see what full name it references (it's the latter that you will, later, create a new EditFlags DWORD in). As can clearly be seen in THIS screenshot, it refers to another Registry entry, Resco_zipfile.
Go to the given extension, still under HKEY_CLASSES_ROOT, and select Menu / 1 File / 1 New / 5 DWORD Value
enter EditFlags in the “Name” field
enter 65536 (that is, hexa 10000) in the DWORD Data field; press Done (left softkey)
now, the new entry should be visible and the ZIP download working (Similar screenshot with EXE files HERE and with PDF files HERE)
Incidentally, if you've read my past EditFlags-related remarks & explanations (for example HERE), you know the uppermost "bit" has a special download-related meaning. If it’s 1 as in HERE, the file will ONLY be downloaded to the main memory and you’re not presented the usual download screen where you can also set the target – instead, the download will start at once. That is, make double sure you don't set it to 1!
Wasit complicated? Certainly it was! Rejoice: now comes the much easier / safer, automatic way! If you're a newbie to Windows Mobile (and/or Registry editing), you will want to prefer THIS registry import file I’ve created for you. It sets the PDF, ZIP and EXE download associations. Note that the latter assumes you’ve installed Resco Explorer and PDF requires the Adobe Reader LE 2.1 (for example, the one shipped with the Vox). You will - after installing Resco Explorer, along with its Registry support - just click the file once you've transferred it to your PDA. After (re)starting IEM, the changes will be visible - and the files downloaded.
Finally, should you need support for even more (not just PDF, ZIP and EXE, but also rar, doc, mpeg, mpg, mp3 and avi) file types, you will want to check out THIS MoDaCo thread (the CAB file installer by rcperez). All you need is running the PIEPlugin.cab file (note that the Download Plugin for PIE Updated.zip file contains the same PIEPlugin.cab also separately downloadable file) linked in the first post. You won't even need to have a Registry Editor. (Note that there are some, similar threads for only one extension type: ZIP, EXE. However, make sure you prefer rcperez's hack.)
1.1.2 Adding more functionality to the phone dialpad
MS Smartphones have something that (most) traditional Pocket PC's don't have: a phonepad: consisting of 10 numeric keys, the # and the * buttons. Knowing the most common functionality a Web browser user wants to have access to (quick scroll up/down, to the top/bottom of the page; reloading; - with multi-document browsers - switching to the previous / next tab; quickly switching between the different rendering and layout modes; quickly changing the character size / zoom percentage), many of this functionality can be quickly accessed by making use of the 12 extra buttons.
As has already been pointed out, IEM only makes use of the '2' and '8' keys by default. These two buttons can be used to do page scrolls, as opposed to the link scrolls accessible on the D-pad, combined with fast scrolling introduced in later WM5 AKU's, should you continuously depress the D-pad. You can, fortunately, assign (some) functionality to all the other remaining ten buttons.
Unfortunately, there are far fewer functions you can assign to the buttons, but even this is definitely a step forward. Let's have a complete list of the functionalities that can be accessed (note that I'll explain the numbers later, when discussing how the Registry should be modded):
Functionality (Registry values):
1 - Page Up (default under (later?) WM5 / WM6)
2 - Page Down (default under (later?) WM5 / WM6)
3 - Top of page
4 - Bottom of page
5 - Page Left in non-one column view / modes
6 - Page Right in non-one column view / modes
7 - Page FULL left in non-one column view / modes
8 - Page FULL right in non-one column view / modes
9 - Default Layout
10 - Desktop Layout
11 - One Column Layout
12 - Full Screen Toggle
13 - Show Pictures Toggle
As can clearly be seen, there're no goodies like "Refresh" in here. However, even then it's pretty much useful.
Now, let's see what these numbers are for. To understand their meaning, I elaborate on how the Registry stores the keypad button - functionality pairs.
In the Registry, it's the [HKEY_LOCAL_MACHINE\ Software\ Microsoft\ Internet Explorer\ KeyMaps] key that stores values (NOT subkeys!) connecting keys with functionalities. In general, it's done in the following way: the value name's the keycode and the value of the value is one of the above-listed functionalities.
The keycodes are as follows (that is, the Registry value names):
48: 0
49: 1
50: 2
51: 3
52: 4
53: 5
54: 6
55: 7
56: 8
57: 9
119: *
120: #
I've created a registry import file that assigns most the available functionality (except for "Page FULL right in non-one column view / modes"). All you need to do is importing it (with, say, Resco Registry Explorer) and (re)starting IEM. The effects will be seen at once. The registry import file is available HERE and has the following key assignment:
0: full screen (12)
1: Show Pictures Toggle (13)
2: Page Up (1)
3: top of page (3)
4: Page Left in non-one column view / modes (5)
5: Page FULL left in non-one column view / modes (7)
6: Page Right in non-one column view / modes (6)
7: default layout (9)
8: Page Down (2)
9: bottom of page (4)
*: Desktop Layout (10)
#: One Column Layout (11)
For more (not mandatory) info, also see THIS, THIS, THIS and THIS.

1.2 Opera Mobile
(a QVGA screenshot; note that, as with IEM and Opera Mini, Opera Mobile is perfectly usable on low-resolution, 176*220 Smartphones too)
Currently, this really excellent browser is even more usable on the Smartphone than on most Pocket PC (that is, Pocket PC’s without a dialpad on the face of the phone – an example of PPC models with a dialpad is the ASUS P525) because of the functionality shortcuts assigned to these buttons. As has been pointed out in the Web Browsing Bible (which is a good read even for people that don’t own a Pocket PC), currently, it’s not possible to assign any otherwise assignable functionality – for example, page up/down, jump to beginning of page etc. – to Pocket PC hardware button. The situation is entirely different with the Smartphone platform.
This is all topped with the traditional Opera Mobile strengths: speed, standards compliance, being multi-tabbed (of course, tabs aren’t displayed in the SP version; however, it’s very easy to quickly (!) switch between loaded pages), no binary download-related problems, upload support etc.
There are some minor (!) bugs with the SP version, as opposed to the PPC one. These are in no way as bad as the problems with IEM, though.
The Register can’t be browsed without zooming out and/or switching to Landscape mode on QVGA screens. This is because, for some reason, one-column mode is just hidden when browsing The Register. Screenshots: 1 2
The standard Smartphone "Back" button doesn't work in the cache setting text input field, which makes it impossible to change the value (other than adding, say, a new number in front of it, which is NOT recommended in any way for a reason I elaborate on later). The "Delete" key on built-in QWERTY keyboards (when they exist), on the other hand, do work. This is a minor problem on models with no built-in QWERTY thumb/keyboard. Tested on both the Vox (has a QWERTY keyboard) and the Oxygen (no keyboard). Note that you can always manually edit (with a file explorer tool) the Size value in the [Disk Cache] section of \Application Data\ Opera\ opera.ini if you want to change this value.
If you install Opera Mobile to a storage card, the file associations won’t work with HTML files and URL’s (for example, links in e-mails) as can be seen in HERE. The problem with PPC version 8.60 was the same; unfortunately, the registry script (see THIS article) I’ve created for the latter doesn’t help with the Smartphone version.
Has some minor problems with image handling. When the browser is presented with more than, say, 7-8 images in a page, it may not download them all (or, for that matter, any of them). Give a try to THIS page to see this in effect - on my QVGA Vox, it didn't render any images. The situation was pretty similar on the old(er) Oxygen (with other pages).
When you manually enter a URL into the "Go to" text input field on the Vox keyboard, you can't enter a string longer than the screen estate size (give a try to entering, say, the above link!) This problem can only be fixed by trying to visit the part that can still be entered and, then, returning to Action / Go to, finding the first part of the URL already entered and going on with entering the latter part(s). Dunno if this problem is caused by the OS or Opera Mobile.
If you define a HUGE cache (to bring down data usage costs), the responsiveness of the browser REALLY decreases. For example, on my Vox, I had a cache with about ~10M files (in the main storage). With that, Opera takes over a minute (!) to start and, after loading a new page (WITHOUT images!) about 10-15 seconds to flush it to the cache, during which you can't for example scroll up/down to go on reading. That is, you need to stick with the default 2M cache to get rid of these problems.
If there is little RAM memory left, the Smartphone dialpad keys (2, 6, 9 etc.) stop working. Instead of their default functionality, they result in reloading pages / moving elsewhere. In these situations, an error message like "Due to RAM memory shortage, the requested action couldn't be done." could be shown.
Again and again, this is more of nitpicking – Opera Mobile for the MS Smartphone still stays THE best Smartphone Web browser. For example, it still supports even saving images (in the Image mode – see the explanation in the usage chart).
Probably the only really annoying bug is the fact that, as of 8.65 beta released on 06/01/2007 and usable until October this year, it only remembers HTTP proxy servers during the first page request after starting; the other requests are directly sent to the HTTP server. To test this, give it a working (for example, at the time of writing, 82.204.47.120:8080 was one of them) proxy address in \Application Data\ Opera\ opera.ini (as is explained in the Toonel-related section) and, then, after restarting Opera, go to WhatIsMyIP.com. Upon the first invocation, you’ll see the proxy’s address as the originating address. Upon later invocations (for example, after just refreshing the page), however, it’ll switch to direct access – and the IP address it displays will also reflect this.
This, unfortunately, means currently you won’t be able to local proxy-based bandwidth usage reduction solutions like Toonel with Opera Mobile. Neither will you be able to use external proxies to either conceal your real IP or get outside of a corporate network.
1.3 Opera Mini 4.x
{
"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"
}
(VGA PPC screenshot running under the Intent midlet manager (hence the non-used command bar at the bottom); a QVGA Smartphone screenshot HERE)
I’ve often reported on Opera Mini, which, as of the current 4.x series beta, has become a serious contender to even native Windows Mobile Web browsers, particularly on the touch screen-less Smartphone platform, where the lacking features of Opera Mini (for example, lack of context menus or copy / paste capabilities) aren’t a problem because of the lack of the touch screen. (That is, you couldn’t use these features on IEM either – it’s only Opera Mobile, with its excellent link / image context menus even on the SP platform, that still offers a bit more functionality than Opera Mini.)
1.3.1 What’s new with the brand new, 4.x Opera Mini series?
Nokia’s having pioneered the quick zoom functionality in their excellent S60 series 3 Web browser, Windows Mobile browsers quickly followed suit: first, NetFront in the second Technical Preview of their forthcoming 3.4; then, Microsoft in their (beta-stage and still far from being finished) DeepFish.
Opera, the, in my opinion, by far the finest (give a try to their desktop browser, particularly if you have an (W)SXGA+ or (W)UXGA screen – you’ll love it!) browser developer company, soon followed suit. In addition to announcing the forthcoming Opera 9, which is a native Windows Mobile application, with similar capabilities, they have also added full page view & quick zoom capabilities to the brand new series of Opera Mini, their Java Midlet-based, small, but still VERY powerful multiplatform browser.
Just visit THIS page (the SWF file, should you want to directly download it, is HERE) and see what Opera has come up with. It’s indeed very cool, isn’t it? All this in a VERY small package (90 kbytes), with almost unmeasurable runtime (dynamic RAM) memory consumption. Compare this to the memory consumption of traditional Web browsers – yes, they consume orders of magnitude more memory. Note that there are a some other, cool videos on Opera’s homepage running the browser in reality – those videos are far more instructive than my static screenshots.
This browser, as has also been pointed out in the Web Browser Bible, runs great on Windows Mobile, on both Pocket PC’s and MS Smartphones, in both common factory-default midlet environments, the Intent (the industry standard on almost all WM5-based PPC and SP phones, except for the Esmertec-based HP iPAQ hx6915) and the Esmertec (shipped with many natively WM6 phones like the HTC Vox / S710) midlet managers.
It’s by far the best J2ME (Java midlet) browser: other Midlet-based browsers are far worse in every respect. For example, jBrowser can’t even display middle-sized pages like the PPCMag blog page, the PPCT main page as can be seen in HERE and, for smaller pages, it will never finish loading.

As has already been pointed out, the best new feature the new version offers is Zoom-in / full page view functionality. Its “let’s crunch the text into the viewable screen estate” works just great – much better than I’ve expected or what most of the other browsers do.
You’ll REALLY love the new page view functionality if you want to check out for example
THIS is the desktop rendition of the Finnish stock exchange in a tabular form. Now, let’s take a look at them in the default, pre-series 4 one-column mode:
and this is how the new, full page layout mode renders it (zoomed in):
and zoomed out, showing the entire page:
A big difference in usability and readability, isn’t it?
Of course, in most cases, if you don’t want to browse tabular data like this, you won’t necessarily need the new mode. Then, you may safely stay with the old, one-column mode.
In addition to providing a page view & zoom-in mode, the Opera folks have come out with something unprecedented in the Windows Mobile world: smart text finding. Let me show you an example with an XDA-Developers thread:
In THIS screenshot, I’ve just started browsing and, therefore, the selection frame is in the upper left corner. Now, let’s press the Down key several times (or, even better, 8 for much quicker navigation downwards). As soon as I’ve reached the body of the text, the selection was automatically (!) scrolled to the right so that no screen estate remains unused on the left side of the screen as can be seen in HERE. Pretty smart, eh?
Now, let’s press Action to read it. As can indeed be seen, the text is very intelligently flowed in a way that no horizontal scrolling is necessary. It’s also really-really superior to how most other browsers handle non-one column modes. Thumbs up Opera, you’re indeed the BEST Web browser developers out there – and this is stated by somebody that knows a LOT about Web technologies and protocols!

1.3.2 Shortcuts
Opera Mini is pretty much similar to Opera Mobile in that it makes extensive use of the phonepad (dialpad) common on all SP models (and, as has already been stated, also available on some PPC models). Unfortunately, the default hotkeys are different, which you, if you often switch between the two browsers, will find pretty inconvenient. (But, then, just edit \Application Data\ Opera\ input.ini to make it similar to the Opera Mini shortcuts. See my other, Opera Mobile-related articles on how this can be accomplished.)
Please see section 1.5 (Shortcuts) to see what shortcuts the two browsers (and, in addition, IEM) offers. They REALLY make browsing MUCH faster – it’s really worth using the dialpad to access them.
1.3.3 Bugs, annoyances in Opera Mini 4.0 beta
The new, 4.0 series being in beta state, it has some, in most cases (if you DO use a compatible Midlet environment), non fatal bugs / annoyances not present in previous versions:
Big minimal font size (as opposed to the current 3.1.* version) and (comparatively) huge gaps between rows. A lot of people have complianed about this; in my opinion, this doesn’t hamper the usability of the client.
Cookies are not necessarily kept (as opposed to the current 3.1.* version – you may end up having to logging into your account much more frequently than with the 3.x series)
You may encounter crashes on Pocket PC’s and on Smartphones running other Midlet managers than that of Esmertec. On my Vox, using the factory-shipped Esmertec midlet environment, I haven’t encountered ANY crash over the last month of active (!) usage. See for example THIS XDA-Dev thread on PPC users’ reporting shutdowns / crashes. Most (if not all) of these users use the Intent midlet manager (which, again, is also the default midlet manager on many Smartphones.)
Let me, again, emphasize that while on my brand new WM6 HTC Vox (s710), using the Esmertec Jeodek 20070115.1.1 midlet environment, I have never encountered any Opera Mini 4.0 beta crash (while having been using it at least 2-3 hours a day!), other midlet environments may behave differently. For example, the Intent midlet manager common on most WM5 Smartphones AND Pocket PC's is known to frequently crash on OpMini4 users - it did once on me too when I (quickly) tested OpMini 4 on my HTC Universal (the latter running the 10/1/7/554 / 20060502 version of the Intent manager.) Should you encounter crashes like this, consider switching to either the IBM J9 midlet manager (according to holg HERE, it works just great with Opera Mini 4) or look around in the XDA-Developers forums for help in getting the, again, stable and reliable Esmertec Midlet manager. (I don't know whether it's separately sold; I seriously doubt it.)
The full page layout takes a LOT of memory. If you stay with the one-column mode, unless you load HUGE pages (say, hundreds of kilobytes originally), you, in general, will be able to make use of all the 30 page slots without having to reload any of these pages. If you, on the other hand, switch to the original page (as opposed to the one-column one) layout view, this will be reduced to two or three concurrent pages at most, regardless of the size of the original pages. If you often switch back to already loaded, just-browsed pages and don’t want to reload them because of the time / bandwidth requirements, you will want to stick to the traditional, one-column mode.
Note that the two versions can easily co-exist with each other. That is, if the first three problems become annoying, you can just switch back to the old versions. Unfortunately, as the favorite lists aren’t shared between the two versions, favorites that you add / edit in one version won’t be visible in the other.
1.3.4 Other (non-4.x-specific) problems
There’re still some problems with Opera Mini that may be a showstopper for you.
It’s still unable to render ANY kind of italic text (see for example THIS for a more thorough elaboration and my demos showing displaying italic text is indeed possible on Smartphones, regardless of the midlet manager in use). This is a MAJOR pain the back. I’ve already contacted the Opera folks on this matter; hope they fix this problem.
Binary download support-wise (as it’s using the IEM engine to do the “dirty” stuff; that is, to download files off the Web), it’s suffering from exactly the same problems as IEM:
CAB files with text MIME type are just rendered as text (like THIS); bigger ones (like THIS 1.5M CAB file) result in an out of memory error
non-CAB files with (correct) binary MIME type (like THIS PDF file) are correctly passed to IEM. Unfortunately, as the execution is fully supervised by IEM, you won’t be able to download any of these files because of the well-known problem already outlined in the IEM section.
Finally, CAB files with the binary MIME type (like THIS) are both correctly recognized by OpMini and, then, correctly downloaded by IEM.
And, of course, the other minor annoyances / restrictions (no file upload, no any kind of access to the IEM / Opera Mobile favorites, no URL copying etc.) – you can see them all in the original Web Browser Bible.
1.3.5 Verdict
Currently, while Opera Mini 4 is at beta stage (as is also emphasized in the documents), it’s already highly recommended if you have a SP model.
1.3.6 More information
Opera Mini 4.0 wishlist thread
Opera Mini forum

1.4 jB5
(another screenshot, now with an image)
Now, this is a really promising browser! While decidedly slower than even IEM and lacks highly useful features like FastBack (upon pressing Back, rendering the page from the local memory cache and NOT downloading it again, unlike both jB5 and NetFront) and does NOT offer multiple document capabilities (unlike the two Operas), it’s (as of the current, tested version, 5.0.56) already pretty powerful (for example, it's the only Smartphone Web browser to offer in-page text search: see it in action: 1 2 3) - much more usable than, say, the next-to-useless Minimo. What is more, it's free.
As it's in beta stage and will surely receive an ever better version, I do not thoroughly review and compare its features / standards compliance to the alternatives because the info would be outdated VERY soon. I will, however, definitely review it as soon as it gets into final (or Release Candidate). Make sure you check it out and get your free copy - if you can put up with the somewhat slower page loading / scrolling speed and the lack of multi-tabs / FastBack, you may like it very much.
1.5 Additional technologies
In this section, I elaborate on the Toonel, Java applet and Flash support on Smartphones. Again and again, CHECK out the original Windows Mobile Web Browsing Bible for more info on them. In here, I only give you strictly Smartphone-related information, not generic one you might want to also know.
1.5.1 Flash
Unfortunately, unlike on the desktop, where there is a more or less solid and compatible (albeit pretty slow) official Flash implementation from Adobe (ex-Macromedia; from now on, I only refer to it as “Adobe”) itself (and the alternative, albeit a bit worse and much more CPU-hungry player integrated into NetFront), Smartphone users have always been left in the cold. Much as Adobe has been addressed several petitions (see for example THIS one at MoDaCo), the Smartphone still haven’t received a real Flash player.
There is some light on the horizon, though. Adobe is working on Flash Lite (current version: 2.1), which is already accessible HERE. (If you don’t have an account, make sure you check in “No, I will create one now” as the bottom so that you can register. Registering can be done quickly; only after that will you be able to access the downloads. Note that, should you not want unwanted Adobe mails, you don’t need to check in any of the “I’m a developer / content creator” radio buttons – you can safely set all of them to “No” instead of the default “Yes” – you’ll still be provided access for the download).
Both IEM and Opera Mobile supports this plug-in (see screenshots below). Note that it doesn’t run MOST currently available Flash animations. For example, most games out there won’t run (unlike under the Pocket PC version). Some examples of them are Bomberman and Play with fire (this is what you’ll be shown: 1 2; IEM screenshot).
Incidentally, I’ve tried to „hack“ Flash Lite (overwriting \Program Files\Adobe\ flashlite.dll with the original, “full” \Windows\ Macromedia\ flash.dll). However, the checking for being a genuine Flash Lite animation is done in another DLL (daxplayer.dll); therefore, this hack doesn’t work.
1.5.2 Toonel
Toonel, the transparent compressor proxy, is a GREAT way to save data usage costs. If you don’t have an unlimited data plan, you really should check it out by, first, reading my related article & tutorial HERE. I’ve published several articles and tips on Toonel; the just-linked one is the one to start with.
While, it seems, it’s not possible to make the native Windows Mobile version work, the Java versions does work on Smartphones.
As far as the native Windows Mobile version is concerned, according to the folks HERE (thanks for the link to the Toonel folks; it's Russian - Babel "translation" HERE), some people managed to make the native (.NET CF) version of Toonel run. I haven’t succeeded in this on either of my Oxygen or Vox.
Fortunately, the Java version works. In general, you’ll only need the (brand new) CrEme 4.12 (download the TI OMAP version of the 4.1 series if you have a TI OMAP-based Smartphone) and THIS JAR file (version 0.45 - do NOT use version 0.50!). Install CrEme (you can do this on the storage card too – then, however, you’ll need to modify the link file I give you), copy the JAR file to the root directory of your handheld (you can, actually, copy it anywhere – but, then, you’ll need to modify the link file I will give you soon) and, then, copy THIS link file to \Windows\Start Menu. Then, just click the latter to start Toonel in the background. Upon start, you should see THIS screen. If you see THIS (note the bind() failed message!), it shows Toonel is already running.
Note that the CrEme process takes quite a lot of memory (but, fortunately, little CPU time – about 1-2% - when inactive) as can be seen in HERE. Beware of this fact – the operating system may kill the CrEme (Toonel) process in the background, particularly if you start other, memory-intensive programs. Then, you will just need to restart the proxy by clicking the startup script.
As, currently, the SP version of Opera Mobile (as with old 8.60 Pocket PC builds) doesn’t have internal support for entering proxy servers, you must enter the proxy information in the config file by hand. However, as with the old PPC betas, you can easily configure the proxy server by just editing \Application Data\ Opera\ opera.ini and adding the following section:
[Proxy]
Use HTTP=1
HTTP server=127.0.0.1:8080
Enable HTTP 1.1 for proxy=1

A screenshot of the Web admin interface of the locally running Toonel on my Vox:
As can clearly be seen, there was about 80% (fourfold!) bandwidth usage saving during the active session. This alone makes Toonel really worthy if yours is not an unlimited data plan.
A quick visit to WhatIsMyIP also shows it’s through the Toonel server that you’re connected (85.25.148.242 is one of the IP’s of the Toonel servers).
It’s VERY important to remember that, currently (as of 07/10/2007), the SP version of Opera Mobile does NOT reliably support proxy servers. Therefore, if you absolutely must use Toonel (or ANY external proxy server), you MUST use IEM and forget Opera Mobile.
As IEM, as with the PPC version, also depends on the operating-system level proxy settings (unlike other browsers), you must also configure the system to access the Net differently than before. That is, do the following:
in IEM, go to Menu / 9 Tools / 3 Options / Connections, untick “Automatically detect settings” and select “Work” in the list as can be seen in HERE
in the system-level Settings, go to 6 Connections / 6 Proxy, press Action on New and create a new record as can be seen in THIS screenshot (as can be seen in HERE, just leave “Type” on “HTTP”). You can name the proxy setting anything; in here, I’ve called it ‘t’. That is, all you need to do is setting “The Internet” to “Connects from”, “Work” to “Connects to” and entering “127.0.0.1:8080” in “Proxy (nameort)”.
Note that, after this, you will need to configure your other programs also using the system-level settings to use Toonel instead of a direct connection. Unfortunately, I haven’t managed to configure the built-in Messaging to use the built-in POP3 proxy support of Toonel (as opposed to the Pocket PC Messaging). Also, remember that, should you have the built-in Live (or MSN) Messenger, defining the proxy will also render them useless.
Unfortunately, it seems it’s not possible to make these programs work with a proxy defined in the above way. That is, you will need to delete the proxy every time you want to access your mail. It seems there are no other ways of disabling it - for example, setting the source / target networks to something else doesn’t work.
Again, keep in mind that you can have Toonel activated for IEM (that is, using a system-level proxy setting) AND still access your mail (both compressed, via Toonel, and uncompressed) via other, Smartphone-compliant mailer clients; for example, FlexMail. With the latter, you can safely use the compression offered by Toonel too and the mails downloaded just OK.
1.5.3 Java applets
While the IEM plug-in of the just-released CrEme 4.12 (the only Java Virtual Machine to be compatible with the Smartphone AND have an applet plug-in) can be registered, it doesn’t seem to be working, unlike on the Pocket PC.
Neither the applet-based Radar Weather test nor the local demo applet (Cube) shipped with the system work: the JVM plug-in just keeps showing "loading applet". Example screenshots: 1 2 (Vox); 3 (Oxygen).
1.6 Keyboard shortcuts
I’ve compiled a chart of the three SP Web browsers showing how a given functionality can be accessed. As can be seen, in general, Opera Mini requires the least button presses to do something (assuming IEM and Opera Mobile run in full-screen mode, which also means double initial softkey presses instead of just a single one to access something in menus only – that is, not having a direct dialpad shortcut).
Keep in mind that, if you extensively use the dialpad (for example, to directly enter the number of the menu item you’d like to activate – these numbers are shown in all menus and I also reproduce them here), you can navigate MUCH faster than using the D-pad to scroll up/down a menu.
You can find the chart here - make sure you check it out, you’ll find it REALLY useful!
2. Non-working or not recommended browsers
2.1 Thunderhawk 2.0
Unfortunately, this browser wasn’t updated for WM5. This means neither the SP2003 (1 2) nor the SP2002 version (these are the two versions available for download) can be installed on WM5/WM6 SP models. All in all, forget about it for the time being.
2.2 NetFront 3.4 Technical Preview 007
No MS Smartphone (WM6 Standard)-compliance: while the CAB installer can be installed on a WM5+ Smartphone, the main GUI isn’t displayed when you start the browser. (tested on the HTC Vox/s710 in both orientations).
2.3 Webby
Unfortunately, it doesn’t run either. While it can be installed, it refuses to run (1 2 3).
2.4 Minimo 0.2
(the latter is a 176*220 screenshot; as can be seen, only the last, Menu (…) icon is invisible; however, transferring the focus to it will also work. Too bad it turned out to be pretty unreliable on my WM5 AKU3 s310 (Oxygen)– even more so than on my QVGA Vox. For example, it didn’t even finish loading the SPT homepage as can be seen in the above screenshot.)
While it can be installed on SP’s, on this platform it’s far from perfect and, in general, useless, for the following reasons:
it has HUGE memory usage (the biggest problem with the 0.2 version on the Pocket PC platform too). After loading, it consumes about 12Mbytes and, when you load additional pages, this decreases even more, leaving little (if any) RAM memory
accessing the icons (to, for example, bring up the address bar) at the bottom can only be done using the right softkey. This, on the other hand, first, iterates through ALL the links in the page (yes, ALL of them), and only after this moves down to the bottom icons. A mouse emulator like SPHelper doesn’t help (to directly click the icons at the bottom) – Minimo just doesn’t sense the mouse clicks (that is, left softkey presses)
the browser often crashes (mostly if you run out of memory) and is generally slowish
All in all, I don’t recommend it. Also see for example THIS and THIS for more info / user opinions.
Note that the other available version, Minimo 0.16, isn’t installable on Smartphones at all.

UPDATE (later the same day):
in THIS thread, MoDaCo forum member holg posted something definitely worth reading - it, for example, explains how you can directly start Opera Mini from the alternative, by me, often-discussed midlet runner environment, the IBM J9. It also shows how external proxies can be used with this environment.
SPT frontpage
UPDATE (07/11/2007): Article heavily updated: added the two IEM Registry hack sections; added the jB5 section.

The following is the brand new section I've just added to the original article. Sorry for not reposting the entire article again - I hate slicing it into pieces so that they become under 10k in size.
1.5.1.1 Hacking REAL Flash on Smartphones
I’ve tried to "hack" Flash Lite (overwriting \Program Files\Adobe\ flashlite.dll with the original, “full” \Windows\ Macromedia\ flash.dll). However, the checking for being a genuine Flash Lite animation is done in another DLL (daxplayer.dll); therefore, this hack doesn’t work.
Fortunately, other hackers had better luck. XDA-Developers forum member jockyw2001 has managed to hack the REAL Flash player onto the SP.
(IEM playing back a YouTube video in One Column mode on the HTC Vox)
(other screenshots: Opera Mobile on the Vox doing the same in Desktop mode with 50% zoom, with the SPHelper cursor for controlling the on-screen controls; the same on my 176*220 Oxygen, with 25% zoom)
His thread is HERE (you will NOT need to read it to complete the steps below!) Note that you MUST apply the hacks on an application unlocked phone - it won't work on locked phones. Fortunately, it's pretty easy to unlock your phone (see for example THIS article for some links). Also note that the hack worked just great on both my WM6 QVGA HTC Vox (s710) and WM5 AKU3 176*220 HTC Oxygen (s310). Some people, however, reported problems with other models (see the above-linked thread). I'm pretty sure it's because they have messed up something that the plug-in doesn't work on their devices.
First, get THIS file (it's a slighlty rearranged version of jockyw2001's original. For example, I've collected the registry import files into one file and separated the files into directories named after the steps you need to do). UnRAR it with, say, WinRAR. Now, do the following:
If you've already installed Resco File Explorer (along with its registry plug-in) and at least once started the latter, copy All.reg from Step 1 - Registry import to anywhere on your SP and click it from File Explorer. It will be imported into the Registry.
Go to the root directory of your SP and to the Step 2 - Windows directory copy directory on your desktop computer. Copy the Windows directory on your SP.
Go to the Step 3 - flash6 directory on your desktop and the \Windows\Macromedia directory on your SP. Overwrite flash.dll on your SP with the one on your desktop.
Go to Step 4 - regserv and copy regsvrce.exe anywhere on your SP. From inside File Explorer (on your SP), execute it to register Flash. To do this, enter \Windows\Macromedia\flash.dll in the Full pathname... text input field (176*220 screenshot). (To make this easier (to avoid entering the path on the phonepad / keyboard of your phone), I recommend for example Pocket Controller on the desktop. If you can’t use Ctrl-V to paste to there (the case with the version 5.06 + HTC Vox combo, but NOT with the Oxygen), use ViTO’s excellent CopyPaste on the Smartphone to copy the contents of the clipboard to the input field.)
Then, just press OK and “Yes” in the confirmation dialog. After some 2-3 seconds, you’ll hear another bell. Now, start regsvrc.exe again; you’ll immediately see a confirmation (success) dialog (176*220 screenshot).
On the desktop, go to Step 5 - Flash7 and copy flash.dll to \Windows\Macromedia on your SP in order to overwrite the in step 3 copied Flash 6 version with the new, Flash 7 one.
Now you can start enjoying REAL Flash content!
The plug-in works great (additional screenshot); you’ll need a cursor emulator like SPHelper to click labels / buttons like in THIS screenshot.
Note that both IEM and Opera Mobile are able to make use of the plug-in. The two programs have somewhat different strengths and weaknesses.
First, IEM can't make use the up/down arrow keys; that is, if you would like to, say, play a game depending on these two directions, they will be unplayable. In these cases, you MUST use Opera Mobile. Second, as far as playing back YouTube videos is concerned, while IEM (unlike on the Pocket PC – it’s pretty strange the SP version of IEM is better in this respect) you will want to prefer Opera Mobile because it’s slightly faster at playback. You will still want to overclock your phone - if it’s a TI OMAP-based one, with OMAPClock.
Under Opera Mobile (as opposed to IEM), in the default mode, the flash plug-in size will be really tiny as can be seen in HERE. (Therefore, you’ll want to switch to Desktop mode and use a Zoom level of, on QVGA machines, in general, 50%, and, on 176*220 models, 25%) Unfortunately, you will still have problems with scrolling down / right – in the default, link scrolling mode, you will only see the top left part of the page and won’t be able to scroll anywhere (not even clicking the scrollbars with SPHelper). To fix this (and to scroll down to the Flash animation), you MUST switch to Image (scrolling) mode. With Opera Mobile, the up/down arrows do work, unlike with IEM, as can also be seen in THIS screenshot (otherwise, I couldn’t have been able to go down).

UPDATE (07/18/2007): Upon popular demand, I've added a section on installing the Flash hack on a storage card.
Again, it's available at http://www.pocketpcmag.com/blogs/index.php?blog=3&p=2084&more=1&c=1&tb=1&pb=1

1.1.3 MultiIE
The well-known Pocket PC IEM enhancer, MultiIE, is also compatible with (WM5+ only; sorry, no pre-WM5 compliance) MS Smartphones. The standard WM5 installer works on both Pocket PC’s and Smartphones. Let’s see how it compares to the Pocket PC version!
Unfortunately, it’s far inferior, feature-wise, to the Pocket PC version. Basically, you can only expect it to add multi-tab functionality.
1.1.3.1 Differences between the Pocket PC and the Smartphone version
1.1.3.1.1 Goodies missing - a generic overview
It’s fully impossible to save images in the SP version. The same stands for the excellent, additional features offered by, for example, address bar macros. They are ALL missing from the SP version, which is, more or less, only lets for multi tabs, softkey-based D-pad scroll mode and full screen switching, HTML saving and source viewing and keeping backlight on.
There are a LOT of features just not accessible in the SP version. In addition to basic functionality like the already-mentioned ability to open a link in another tab, the lack of saving images or saving full Web pages (as opposed to only saving plain HTML files without in-line images and, preferably, CSS/JS files), a whole set of other features are also missing: for example, address bar macroing, the excellent location-based services offered by the PPC version, the ability to quickly reformat a Web page through online Web compression / reformatting services like Skweezer etc. Fortunately, at least “Keep Backlight On” works.
1.1.3.1.2 Setting dialogs
Unfortunately, a lot of menu options accessible on the PPC are just not accessible in the SP version. For example, assigning shortcut buttons to MultiIE functions (PPC screenshots: 1 2) isn’t even offered by the SP version. On the Screen tab, it’s not possible to switch off the, on the Smartphone, useless (because you can’t tap them on a touchscreen-less device) corner icons (PPC SP).
1.1.3.1.3 Impossible to open a link in a new tab
While it’s available in the SP version of Opera Mobile (where you just traverse the focus to the link you’d like to open but, instead of pressing Action, press the right softkey and select “1 Open in new window”), it’s not possible to dynamically set where (in what tab) a new link should be opened to. This, of course, is also possible in the PPC version of MultiIE as can be seen in HERE.
You can surely try to redefine the default functionality in the Open link: Tap default action to, say, Open in new back window as can be seen in HERE, but it won’t work at all (and won’t stick). This means you can NOT open links in another tab in any way without opening a new tab in Menu / 9 MultiIE / 3 Open New Window and, in there, select the link you want to display in this tab.
1.1.3.2 Compared to Opera Mobile…
The inability to open a link in a new window, as has already been pointed out, is a big problem with MultiIE – as opposed to OpMob.
Switching between open tabs also requires significantly more button presses than in Opera Mobile. In the latter, you only need to press ‘2’ once to bring up the list of open tabs, where, after selecting the right one to switch to, you only need to press Action once. In MultiIE, you need to press Menu / 9 MultiIE and, if there are not more than 3 open tabs (in Portrait mode on QVGA devices; on 176*220 ones, even two open tabs will result in the same), select the tab at the top. If there’re more tabs open (QVGA screenshot with 4 tabs) or, you’re in Landscape, there will be another level of redirection (1 Windows), making it necessary to issue another keypress.
There is, however, something MultiIE is better at: saving web pages do work. Unfortunately, you can’t fine tune what should be saved – unlike in the PPC version, where not only the page HTML itself, but also all the related resources (by selecting a full save instead of the HTML-only).
1.1.3.3 Other bugs & problems
In addition to the already-mentioned ones (for example, the Open link: Tap default action settings’s not being sticky) it has several other bugs. For example, it sometimes hides the tabs (1 2) on QVGA devices (but not on 176*220 ones). This might particularly be a case with pages using frames, after maximizing one of these frames using Expand Frame (left softkey); for example, the MultiIE page itself.
The menus may be a bit messed up (but still usable) on QVGA devices because of the too large fonts. On low-res 176*220 ones, they’re OK (screenshots: 176*220: 1 2 3; QVGA: 1 2)
While the tabs can be re-displayed after a screen rotation (if the particular device supports rotating the screen – for example, the Vox does), rotating back to the original rotation will result in not using the entire screen estate. This won’t be an issue if you NEVER rotate the screen but stay in either Portrait or Landscape all the time.
As far as the options dialog screens are concerned, the “Plugin” dialog is also different: first, as it is lacking a scrollbar, you don’t see anything under Presets / Shown on open more menu on both 176*220 and QVGA Portrait phones. On QVGA Landscape ones, however, the scrollbar is displayed and you can scroll down, revealing the lowermost GUI widgets. Not that it’d be of any use: NONE of the features work in here. That is, you can’t even set the User-Agent to be used to “disguise” your browser as a full desktop Windows browser. This is also a very bad disadvantage, compared to how it behaves on the Pocket PC.
Still in this dialog, the address bar search configuration (PPC screenshots: 1 2) don’t work either: an “Option not available in alpha” is displayed.
1.1.3.4 Tips & tricks
By default, to view the source of a Web page, it tries to use \Windows\notes.exe, which doesn’t exist on any MS Smartphones.
Unfortunately (if you have a phone with a built-in keyboard – non-QWERTY phones don’t have this program!), if you redefine this link to \Windows\TextNotes.exe as can be seen in HERE, Menu / 9 MultiIE / 6(+) Page Tools / 3 View Source will not work either.
Therefore, if you have a Windows Mobile 6 Standard phone (which come with Office Mobile built-in), you’ll want to prefer Word Mobile (\Windows\pword.exe) to view the sources. To make this word, configure MultiIE to use it as the default viewer. With that, watching sources will work just fine:

1.1.3.5 Verdict
All in all, don’t expect much of the current version of MultiIE for Smartphone. It’s WAY worse, WAY harder to use and definitely more buggy than the Pocket PC version. The Smartphone version of Opera Mobile is far better thought-out (support for dialpad buttons; menu-based link / image context menu support etc., making it far easier to, for example, open a link in a new tab instead of the current one; far faster to switch tabs; allows for saving images etc.). If you, however, absolutely need to stick to IEM and do need a multitab solution for it with some goodies (for example, Opera Mobile still doesn’t support saving pages; MultiIE does; the same stands for quickly swapping between the three scrolling modes, should you want to exclusively use the D-pad for scrolling and leave the 2/8 phone buttons alone), currently, MultiIE is the only way to go.

UPDATE: Just added a new section on MultiIE in the IEM-related chapter. Worth a read!

UPDATE (10/20/2007): I've published a review of Opera Mobile 8.65 Final (PPC/SP), Picsel 1.0.5 (PPC/SP) and the brand new Spb Pocket Plus 4.0 (PPC). A new version of jb5 (PPC/SP) has been released and a brand new, albeit very simple IEM add-in Web Viewer for WM5 (PPC). Also, I’ve linked in some of my recent reviews of some new (not very important) Web browsers: TeaShark (PPC/SP) and UCWEB (PPC/SP). Finally, I've published some genuine, never-before-published tips and tricks on utilizing the Pocket PC hardware application buttons to control Opera Mini and Opera Mobile. It's a MUST for any serious Pocket PC user - you'll LOVE my new tips & tricks. See THIS. Cross-posted to: PPCT, AximSite, XDA-Developers - 1, XDA-Developers - 2, FirstLoox, BrightHand, HowardForums, SPT, MoDaCo.

UPDATE (11/12/2007): the final version of Opera Mini 4 has been released. I've written a VERY thorough tutorial on installing and using it; it's available HERE; cross-posted to PPCT, AximSite, XDA-Developers -1, XDA-Developers -2, FirstLoox, BrightHand, HowardForums - 1, HowardForums - 2, SPT, MoDaCo, official Opera Mini forum. Note that it also links in my brand new MIDlet Bible, which will be a god-send anyone wanting to run this EXCELLENT browser on his or her handset.

Menneisyys said:
Step 1 - Registry import to anywhere on your SP and click it from File Explorer. It will be imported into the Registry.
[*]Go to the root directory of your SP and to the Step 2 - Windows directory copy directory on your desktop computer. Copy the Windows directory on your SP.
Click to expand...
Click to collapse
REF: STEP2...
When I try to copy my WINDOWS folder from SP to Desktop, I get error: "Cannot copy index: There has been a sharing violation. The source or destination file may be in use." This error is while copying from "Content IE5" I feel I didn't understand that instruction correctly. There are 1136 objects in Windows folder on route.
Thanks in advance for any help you can provide.

markanthonypr said:
REF: STEP2...
When I try to copy my WINDOWS folder from SP to Desktop, I get error: "Cannot copy index: There has been a sharing violation. The source or destination file may be in use." This error is while copying from "Content IE5" I feel I didn't understand that instruction correctly. There are 1136 objects in Windows folder on route.
Thanks in advance for any help you can provide.
Click to expand...
Click to collapse
Why do you want to copy from there? To copy the local cache?

Menneisyys said:
Why do you want to copy from there? To copy the local cache?
Click to expand...
Click to collapse
Hello Menneisyys, Thank you for your reply. I made reference to Step#2 of your post#9 on this thread in regards to installing/hacking Real Flash in order to view YouTube videos. While it is true that YouTube now has a mobile version, I still can't see the videos with their mobile version. Its why I was trying to follow your instructions to install Real Flash.

markanthonypr said:
Hello Menneisyys, Thank you for your reply. I made reference to Step#2 of your post#9 on this thread in regards to installing/hacking Real Flash in order to view YouTube videos. While it is true that YouTube now has a mobile version, I still can't see the videos with their mobile version. Its why I was trying to follow your instructions to install Real Flash.
Click to expand...
Click to collapse
OIC.
"Go to the root directory of your SP and to the Step 2 - Windows directory copy directory on your desktop computer. Copy the Windows directory on your SP."
This means you need to copy from the desktop to the phone, not vica versa.
(sorry for the misunderstanding - 1. my mother tongue isn't English 2. given that I write a *lot* (much more than anyone else) of Bibles /articles on Windows Mobile, I have very little time to actually double-check my articles before submitting them)

ERROR!
Menneisyys said:
The following is the brand new section I've just added to the original article. Sorry for not reposting the entire article again - I hate slicing it into pieces so that they become under 10k in size.
1.5.1.1 Hacking REAL Flash on Smartphones
I’ve tried to "hack" Flash Lite (overwriting \Program Files\Adobe\ flashlite.dll with the original, “full” \Windows\ Macromedia\ flash.dll). However, the checking for being a genuine Flash Lite animation is done in another DLL (daxplayer.dll); therefore, this hack doesn’t work.
Fortunately, other hackers had better luck. XDA-Developers forum member jockyw2001 has managed to hack the REAL Flash player onto the SP.
(IEM playing back a YouTube video in One Column mode on the HTC Vox)
(other screenshots: Opera Mobile on the Vox doing the same in Desktop mode with 50% zoom, with the SPHelper cursor for controlling the on-screen controls; the same on my 176*220 Oxygen, with 25% zoom)
His thread is HERE (you will NOT need to read it to complete the steps below!) Note that you MUST apply the hacks on an application unlocked phone - it won't work on locked phones. Fortunately, it's pretty easy to unlock your phone (see for example THIS article for some links). Also note that the hack worked just great on both my WM6 QVGA HTC Vox (s710) and WM5 AKU3 176*220 HTC Oxygen (s310). Some people, however, reported problems with other models (see the above-linked thread). I'm pretty sure it's because they have messed up something that the plug-in doesn't work on their devices.
First, get THIS file (it's a slighlty rearranged version of jockyw2001's original. For example, I've collected the registry import files into one file and separated the files into directories named after the steps you need to do). UnRAR it with, say, WinRAR. Now, do the following:
If you've already installed Resco File Explorer (along with its registry plug-in) and at least once started the latter, copy All.reg from Step 1 - Registry import to anywhere on your SP and click it from File Explorer. It will be imported into the Registry.
Go to the root directory of your SP and to the Step 2 - Windows directory copy directory on your desktop computer. Copy the Windows directory on your SP.
Go to the Step 3 - flash6 directory on your desktop and the \Windows\Macromedia directory on your SP. Overwrite flash.dll on your SP with the one on your desktop.
Go to Step 4 - regserv and copy regsvrce.exe anywhere on your SP. From inside File Explorer (on your SP), execute it to register Flash. To do this, enter \Windows\Macromedia\flash.dll in the Full pathname... text input field (176*220 screenshot). (To make this easier (to avoid entering the path on the phonepad / keyboard of your phone), I recommend for example Pocket Controller on the desktop. If you can’t use Ctrl-V to paste to there (the case with the version 5.06 + HTC Vox combo, but NOT with the Oxygen), use ViTO’s excellent CopyPaste on the Smartphone to copy the contents of the clipboard to the input field.)
Then, just press OK and “Yes” in the confirmation dialog. After some 2-3 seconds, you’ll hear another bell. Now, start regsvrc.exe again; you’ll immediately see a confirmation (success) dialog (176*220 screenshot).
On the desktop, go to Step 5 - Flash7 and copy flash.dll to \Windows\Macromedia on your SP in order to overwrite the in step 3 copied Flash 6 version with the new, Flash 7 one.
Now you can start enjoying REAL Flash content!
The plug-in works great (additional screenshot); you’ll need a cursor emulator like SPHelper to click labels / buttons like in THIS screenshot.
Note that both IEM and Opera Mobile are able to make use of the plug-in. The two programs have somewhat different strengths and weaknesses.
First, IEM can't make use the up/down arrow keys; that is, if you would like to, say, play a game depending on these two directions, they will be unplayable. In these cases, you MUST use Opera Mobile. Second, as far as playing back YouTube videos is concerned, while IEM (unlike on the Pocket PC – it’s pretty strange the SP version of IEM is better in this respect) you will want to prefer Opera Mobile because it’s slightly faster at playback. You will still want to overclock your phone - if it’s a TI OMAP-based one, with OMAPClock.
Under Opera Mobile (as opposed to IEM), in the default mode, the flash plug-in size will be really tiny as can be seen in HERE. (Therefore, you’ll want to switch to Desktop mode and use a Zoom level of, on QVGA machines, in general, 50%, and, on 176*220 models, 25%) Unfortunately, you will still have problems with scrolling down / right – in the default, link scrolling mode, you will only see the top left part of the page and won’t be able to scroll anywhere (not even clicking the scrollbars with SPHelper). To fix this (and to scroll down to the Flash animation), you MUST switch to Image (scrolling) mode. With Opera Mobile, the up/down arrows do work, unlike with IEM, as can also be seen in THIS screenshot (otherwise, I couldn’t have been able to go down).
Click to expand...
Click to collapse
Hello, you either have JavaScript turned off or an old version of Adobe's Flash Player. Get the latest flash player.
...meaning NOT working.
Is this smartphone only?
Still no flash solution!

The one and only MS Smartphone Web Browsing Bible

In my recently-published, well-known Windows Mobile Web Browsing Bible I’ve elaborated on how Pocket PC’s can be used to browse the Web. Please make sure you DO read the review even if you don’t have a Pocket PC. You will learn a LOT from there and, in addition, I do NOT elaborate on many questions like Web standards compliance or additional Opera Mini features in here. In the current review, I “only” elaborate on questions ONLY concerning the MS Smartphone platform. The only exception is the review of Opera Mini 4, which is a generic one and can be used by Pocket PC users as well. Finally, in addition, as so many times in the past, I present you some genuine Registry hacks fixing annoyances / bugs in both IEM and Opera Mobile never before published.
Now, it’s time to review
how you can do the same on MS Smartphone (Windows Mobile Standard) devices (SP for short); what browsers you should use, what bugs you should be aware of etc.
the brand new and REALLY NICE, HIGHLY recommended Opera Mini 4 platform. This section will be of interest to not only SP users, but also those of the “big brother”, the Pocket PC – and, for that matter, any Java-capable mobile phone.
As you’ll see, on the SP platform, there’re far fewer really usable browsers and there are (currently, before NSIcom fixes the bugs with the current CrEme version) absolutely no Java and, if you don't apply the Flash "hack", real Flash support. This, fortunately, makes one’s life far easier – generally, you only have four browsers to select from: IEM, Opera Mobile, Opera Mini or the really promising newcomer, jB5. The two Operas are, as you may have already guessed, generally superior to the built-in Internet Explorer Mobile.
However, let’s start with the latter as it comes built into the operating system of all SP devices.
1.1 Internet Explorer Mobile (IEM)
Unfortunately, the SP version of the built-in IEM, even as of Windows Mobile 6 Standard (that is, the latest SP operating system version), is considerably inferior to the Pocket PC (PPC) version shipped with WM6. For example,
while the PPC version of IEM has received file uploading capabilities some two years ago (with the initial release of WM5), not even the latest, just-released, WM6 version of IEM is capable of the same as can be seen in HERE (showing the results of my traditional file upload test page – see the previously linked page for more info on what the screenshot should show). Note that the SP version of Opera Mobile has no problems with file uploading (1 2 3 4)
it also has major problems with some HTTP / scripting constructs never having caused any problems to the Pocket PC brother; most importantly, it has problems with posting to Smartphone Thoughts and Pocket PC Thoughts forums from IEM. (The PPC port of IEM has no problems with posting to these sites; neither do Opera Mobile and Opera Mini on the SP platform.) Interestingly, this is NOT a problem on several models (even including WM6 ones) - and, in some occasions, it even worked on my Vox. I don't know why - it probably depends on the size of the message. Also see for example Mike Temporale's posts and links in THIS thread.
it doesn’t support tabs and, as you may have guessed, none of the known, Pocket PC-only PIE / IEM enhancers (PIEPlus, Spb Pocket Plus, ftxPBrowser etc.) work - except for MultiIE, which only delivers a fraction of its Pocket PC features.
just as on the Pocket PC, you can’t make use of the hardware buttons (except for the “Back” button) AND the dialpad buttons (except for the 2/4/6/8 buttons for page scrolls) of your Smartphone. In this respect, both Opera Mini and Mobile are better. Fortunately, the most common functionalities are accessible, in general, with two or three (depending on whether you start from full screen mode) key presses. Fortunately, there are some registry hacks that - at least to a certain degree - fix this, which I’ll later, in a subsequent section, elaborate on.
download-wise, it’s really different from the Pocket PC IEM: it’s only CAB files that can be downloaded (if at all – see later), nothing else. This is in stark contrast with both the PPC version and Opera Mobile on the platform, which uses the same, vastly superior download-specific code as the PPC version. You must do some manual, extensive Registry editing to fix this problem - and, even then, you will need to do this for each file type you'd like to see downloaded. I too address this issue in a later section.
Note that isn’t not only files that have no local, associated programs to operate on are refused to be downloaded, but EVERYTHING, even registered and, by default, supported file types like ZIP and PDF files (fortunately, Office files are supported if your device does contain Office Mobile – an example of an XLS file is HERE).

Some examples of these cases:
non-associated RAR files (for example THIS). Upon trying to download files like these, you get THIS error message (unlike with Opera Mobile).
PDF files with the, on the HTC Vox, associated, built-in Adobe Reader LE. An example PDF file is HERE
ZIP files, like THIS, associated with Resco File Explorer.
Furthermore, the old problem with CAB files served as of unknown type is present in this version too. For example, while THIS CAB file is server as binary and, therefore, offered for download, THIS one, which is returned as of unknown (text/plain) type, results in the well-known, useless textual representation (while Opera Mobile downloads it just fine). The CAB problem has always been a major problem with the PPC version as well, as is also explained in the Download Bible.
Note that I’ve also had downloading problems on my WM5 HTC s310 (Oxygen) upon trying to download a 2.5M Byte CAB file (the Smartphone version of Opera Mobile HERE) via an EDGE connection. No matter where I tried to store it (the device had about 10M free built-in storage), the transfer would stall at 300-600 kbytes (I’ve tried to download the file several times), while, under exactly the same circumstances (the same network coverage, the same file etc), my WM5 HTC Wizard Pocket PC downloaded the file without problems. I haven’t encountered similar problems on my WM6 HTC Vox (s710). I don’t know whether this was a temporary problem or generally a problem with WM5 SP IEM’s over slow(er) connections and large(r) binary (in this case, CAB) files. Just keep this in mind if you have similar problems.
As far as the WM6-specific fixes are concerned, the WM6 SP version of IEM, fortunately, supports iframes as can be seen in HERE. (It’s suffering from the same width problem as with the PPC version, though – even in Single column mode. This isn’t an issue on Opera Mobile and Mini.)
All in all, I do not really recommend IEM for regular Web browsing on SP’s if you don't apply the above-mentioned (and below-explained) registry hacks. Go for either Opera Mobile (which is, as far as the new, 8.65 beta is concerned, free until Oct. 1. Of course, being free until October doesn’t mean you shouldn’t support the company – do purchase for example their 8.60 version to support their continuous efforts to give us the BEST Pocket PC, Smartphone and, in my opinion, desktop Windows browsers) or the absolutely free and excellent Opera Mini.
1.1.1 Fixing the binary file download problem
The difference between the SP and the PPC version of IEM is pretty simple. While the latter doesn't require a given file type to be registered in the local Registry to be downloaded, the former does, and also requires a specific flag (the fifth "bit" in EditFlags) to be set to one.
This is why "unknown" file types like RAR or known file types that don't have the EditFlags value are refused to download. You can, fortunately, fix it. In here, I describe both the manual and the automatic, much easier way of doing this. The former includes heavy Registry editing, but might prove useful in cases you'd like to allow for downloading more file types than the automatic way offers.
1.1.1.1 Manually enabling downloading a given file type
Let's assume you want to enable ZIP file downloading. To do this, first, you have to fire up a registry editor (I recommend that of Resco - it's well worth the price).
First, as ZIP files end in .zip (that is, have the file extension 'zip'), you need to navigate to HKEY_CLASSES_ROOT\.zip to see what full name it references (it's the latter that you will, later, create a new EditFlags DWORD in). As can clearly be seen in THIS screenshot, it refers to another Registry entry, Resco_zipfile.
Go to the given extension, still under HKEY_CLASSES_ROOT, and select Menu / 1 File / 1 New / 5 DWORD Value
enter EditFlags in the “Name” field
enter 65536 (that is, hexa 10000) in the DWORD Data field; press Done (left softkey)
now, the new entry should be visible and the ZIP download working (Similar screenshot with EXE files HERE and with PDF files HERE)
Incidentally, if you've read my past EditFlags-related remarks & explanations (for example HERE), you know the uppermost "bit" has a special download-related meaning. If it’s 1 as in HERE, the file will ONLY be downloaded to the main memory and you’re not presented the usual download screen where you can also set the target – instead, the download will start at once. That is, make double sure you don't set it to 1!
Was it complicated? Certainly it was! Rejoice: now comes the much easier / safer, automatic way! If you're a newbie to Windows Mobile (and/or Registry editing), you will want to prefer THIS registry import file I’ve created for you. It sets the PDF, ZIP and EXE download associations. Note that the latter assumes you’ve installed Resco Explorer and PDF requires the Adobe Reader LE 2.1 (for example, the one shipped with the Vox). You will - after installing Resco Explorer, along with its Registry support - just click the file once you've transferred it to your PDA. After (re)starting IEM, the changes will be visible - and the files downloaded.
Finally, should you need support for even more (not just PDF, ZIP and EXE, but also rar, doc, mpeg, mpg, mp3 and avi) file types, you will want to check out THIS MoDaCo thread (the CAB file installer by rcperez). All you need is running the PIEPlugin.cab file (note that the Download Plugin for PIE Updated.zip file contains the same PIEPlugin.cab also separately downloadable file) linked in the first post. You won't even need to have a Registry Editor. (Note that there are some, similar threads for only one extension type: ZIP, EXE. However, make sure you prefer rcperez's hack.) Note that you may want to stick with my registry import scripts if you don't want the pre-WM6 scripts to mess up for example the PDF associations (as it creates its own PDF file type registry record and forces the old association to be removed), making it impossible to load a PDF document by just clicking it from File Explorer.

1.1.2 Adding more functionality to the phone dialpad
MS Smartphones have something that (most) traditional Pocket PC's don't have: a phonepad: consisting of 10 numeric keys, the # and the * buttons. Knowing the most common functionality a Web browser user wants to have access to (quick scroll up/down, to the top/bottom of the page; reloading; - with multi-document browsers - switching to the previous / next tab; quickly switching between the different rendering and layout modes; quickly changing the character size / zoom percentage), many of this functionality can be quickly accessed by making use of the 12 extra buttons.
As has already been pointed out, IEM only makes use of the '2' and '8' keys by default. These two buttons can be used to do page scrolls, as opposed to the link scrolls accessible on the D-pad, combined with fast scrolling introduced in later WM5 AKU's, should you continuously depress the D-pad. You can, fortunately, assign (some) functionality to all the other remaining ten buttons.
Unfortunately, there are far fewer functions you can assign to the buttons, but even this is definitely a step forward. Let's have a complete list of the functionalities that can be accessed (note that I'll explain the numbers later, when discussing how the Registry should be modded):
Functionality (Registry values):
1 - Page Up (default under (later?) WM5 / WM6)
2 - Page Down (default under (later?) WM5 / WM6)
3 - Top of page
4 - Bottom of page
5 - Page Left in non-one column view / modes
6 - Page Right in non-one column view / modes
7 - Page FULL left in non-one column view / modes
8 - Page FULL right in non-one column view / modes
9 - Default Layout
10 - Desktop Layout
11 - One Column Layout
12 - Full Screen Toggle
13 - Show Pictures Toggle
As can clearly be seen, there're no goodies like "Refresh" in here. However, even then it's pretty much useful.
Now, let's see what these numbers are for. To understand their meaning, I elaborate on how the Registry stores the keypad button - functionality pairs.
In the Registry, it's the [HKEY_LOCAL_MACHINE\ Software\ Microsoft\ Internet Explorer\ KeyMaps] key that stores values (NOT subkeys!) connecting keys with functionalities. In general, it's done in the following way: the value name's the keycode and the value of the value is one of the above-listed functionalities.
The keycodes are as follows (that is, the Registry value names):
48: 0
49: 1
50: 2
51: 3
52: 4
53: 5
54: 6
55: 7
56: 8
57: 9
119: *
120: #
I've created a registry import file that assigns most the available functionality (except for "Page FULL right in non-one column view / modes"). All you need to do is importing it (with, say, Resco Registry Explorer) and (re)starting IEM. The effects will be seen at once. The registry import file is available HERE and has the following key assignment:
0: full screen (12)
1: Show Pictures Toggle (13)
2: Page Up (1)
3: top of page (3)
4: Page Left in non-one column view / modes (5)
5: Page FULL left in non-one column view / modes (7)
6: Page Right in non-one column view / modes (6)
7: default layout (9)
8: Page Down (2)
9: bottom of page (4)
*: Desktop Layout (10)
#: One Column Layout (11)
For more (not mandatory) info, also see THIS, THIS, THIS and THIS.
1.1.3 MultiIE
The well-known Pocket PC IEM enhancer, MultiIE, is also compatible with (WM5+ only; sorry, no pre-WM5 compliance) MS Smartphones. The standard WM5 installer works on both Pocket PC’s and Smartphones. Let’s see how it compares to the Pocket PC version!
Unfortunately, it’s far inferior, feature-wise, to the Pocket PC version. Basically, you can only expect it to add multi-tab functionality.
1.1.3.1 Differences between the Pocket PC and the Smartphone version
1.1.3.1.1 Goodies missing - a generic overview
It’s fully impossible to save images in the SP version. The same stands for the excellent, additional features offered by, for example, address bar macros. They are ALL missing from the SP version, which is, more or less, only lets for multi tabs, softkey-based D-pad scroll mode and full screen switching, HTML saving and source viewing and keeping backlight on.
There are a LOT of features just not accessible in the SP version. In addition to basic functionality like the already-mentioned ability to open a link in another tab, the lack of saving images or saving full Web pages (as opposed to only saving plain HTML files without in-line images and, preferably, CSS/JS files), a whole set of other features are also missing: for example, address bar macroing, the excellent location-based services offered by the PPC version, the ability to quickly reformat a Web page through online Web compression / reformatting services like Skweezer etc. Fortunately, at least “Keep Backlight On” works.
1.1.3.1.2 Setting dialogs
Unfortunately, a lot of menu options accessible on the PPC are just not accessible in the SP version. For example, assigning shortcut buttons to MultiIE functions (PPC screenshots: 1 2) isn’t even offered by the SP version. On the Screen tab, it’s not possible to switch off the, on the Smartphone, useless (because you can’t tap them on a touchscreen-less device) corner icons (PPC SP).
1.1.3.1.3 Impossible to open a link in a new tab
While it’s available in the SP version of Opera Mobile (where you just traverse the focus to the link you’d like to open but, instead of pressing Action, press the right softkey and select “1 Open in new window”), it’s not possible to dynamically set where (in what tab) a new link should be opened to. This, of course, is also possible in the PPC version of MultiIE as can be seen in HERE.
You can surely try to redefine the default functionality in the Open link: Tap default action to, say, Open in new back window as can be seen in HERE, but it won’t work at all (and won’t stick). This means you can NOT open links in another tab in any way without opening a new tab in Menu / 9 MultiIE / 3 Open New Window and, in there, select the link you want to display in this tab.
1.1.3.2 Compared to Opera Mobile…
The inability to open a link in a new window, as has already been pointed out, is a big problem with MultiIE – as opposed to OpMob.
Switching between open tabs also requires significantly more button presses than in Opera Mobile. In the latter, you only need to press ‘2’ once to bring up the list of open tabs, where, after selecting the right one to switch to, you only need to press Action once. In MultiIE, you need to press Menu / 9 MultiIE and, if there are not more than 3 open tabs (in Portrait mode on QVGA devices; on 176*220 ones, even two open tabs will result in the same), select the tab at the top. If there’re more tabs open (QVGA screenshot with 4 tabs) or, you’re in Landscape, there will be another level of redirection (1 Windows), making it necessary to issue another keypress.
There is, however, something MultiIE is better at: saving web pages do work. Unfortunately, you can’t fine tune what should be saved – unlike in the PPC version, where not only the page HTML itself, but also all the related resources (by selecting a full save instead of the HTML-only).

1.1.3.3 Other bugs & problems
In addition to the already-mentioned ones (for example, the Open link: Tap default action settings’s not being sticky) it has several other bugs. For example, it sometimes hides the tabs (1 2) on QVGA devices (but not on 176*220 ones). This might particularly be a case with pages using frames, after maximizing one of these frames using Expand Frame (left softkey); for example, the MultiIE page itself.
The menus may be a bit messed up (but still usable) on QVGA devices because of the too large fonts. On low-res 176*220 ones, they’re OK (screenshots: 176*220: 1 2 3; QVGA: 1 2)
While the tabs can be re-displayed after a screen rotation (if the particular device supports rotating the screen – for example, the Vox does), rotating back to the original rotation will result in not using the entire screen estate. This won’t be an issue if you NEVER rotate the screen but stay in either Portrait or Landscape all the time.
As far as the options dialog screens are concerned, the “Plugin” dialog is also different: first, as it is lacking a scrollbar, you don’t see anything under Presets / Shown on open more menu on both 176*220 and QVGA Portrait phones. On QVGA Landscape ones, however, the scrollbar is displayed and you can scroll down, revealing the lowermost GUI widgets. Not that it’d be of any use: NONE of the features work in here. That is, you can’t even set the User-Agent to be used to “disguise” your browser as a full desktop Windows browser. This is also a very bad disadvantage, compared to how it behaves on the Pocket PC.
Still in this dialog, the address bar search configuration (PPC screenshots: 1 2) don’t work either: an “Option not available in alpha” is displayed.
1.1.3.4 Tips & tricks
By default, to view the source of a Web page, it tries to use \Windows\notes.exe, which doesn’t exist on any MS Smartphones.
Unfortunately (if you have a phone with a built-in keyboard – non-QWERTY phones don’t have this program!), if you redefine this link to \Windows\TextNotes.exe as can be seen in HERE, Menu / 9 MultiIE / 6(+) Page Tools / 3 View Source will not work either.
Therefore, if you have a Windows Mobile 6 Standard phone (which come with Office Mobile built-in), you’ll want to prefer Word Mobile (\Windows\pword.exe) to view the sources. To make this word, configure MultiIE to use it as the default viewer. With that, watching sources will work just fine:
1.1.3.5 Verdict
All in all, don’t expect much of the current version of MultiIE for Smartphone. It’s WAY worse, WAY harder to use and definitely more buggy than the Pocket PC version. The Smartphone version of Opera Mobile is far better thought-out (support for dialpad buttons; menu-based link / image context menu support etc., making it far easier to, for example, open a link in a new tab instead of the current one; far faster to switch tabs; allows for saving images etc.). If you, however, absolutely need to stick to IEM and do need a multitab solution for it with some goodies (for example, Opera Mobile still doesn’t support saving pages; MultiIE does; the same stands for quickly swapping between the three scrolling modes, should you want to exclusively use the D-pad for scrolling and leave the 2/8 phone buttons alone), currently, MultiIE is the only way to go.
1.2 Opera Mobile
(a QVGA screenshot; note that, as with IEM and Opera Mini, Opera Mobile is perfectly usable on low-resolution, 176*220 Smartphones too)
Currently, this really excellent browser is even more usable on the Smartphone than on most Pocket PC (that is, Pocket PC’s without a dialpad on the face of the phone – an example of PPC models with a dialpad is the ASUS P525) because of the functionality shortcuts assigned to these buttons. As has been pointed out in the Web Browsing Bible (which is a good read even for people that don’t own a Pocket PC), currently, it’s not possible to assign any otherwise assignable functionality – for example, page up/down, jump to beginning of page etc. – to Pocket PC hardware button. The situation is entirely different with the Smartphone platform.
This is all topped with the traditional Opera Mobile strengths: speed, standards compliance, being multi-tabbed (of course, tabs aren’t displayed in the SP version; however, it’s very easy to quickly (!) switch between loaded pages), no binary download-related problems, upload support etc.
There are some minor (!) bugs with the SP version, as opposed to the PPC one. These are in no way as bad as the problems with IEM, though.
The standard Smartphone "Back" button doesn't work in the cache setting text input field, which makes it impossible to change the value (other than adding, say, a new number in front of it, which is NOT recommended in any way for a reason I elaborate on later). The "Delete" key on built-in QWERTY keyboards (when they exist), on the other hand, do work. This is a minor problem on models with no built-in QWERTY thumb/keyboard. Tested on both the Vox (has a QWERTY keyboard) and the Oxygen (no keyboard). Note that you can always manually edit (with a file explorer tool) the Size value in the [Disk Cache] section of \Application Data\ Opera\ opera.ini if you want to change this value.
If your device runs WM6 (but NOT a previous operating systems - it's working just great on my WM5 AKU3 HTC Oxygen / s310!) and you want to use Opera Mobile as the default browser to, say, open links arriving in e-mails, the file associations won’t work with these URL’s as can be seen in HERE. The problem with the old PPC version 8.60 was the same, but the explanation and solution was completely different; this is why the old registry script (see THIS article) I’ve created for the latter doesn’t help with the Smartphone version.
Fortunately, after playing with the new, WM6 Registry, I pinpointed the problem and was able to come up with a real fix (yes, I was the first to fix this bug!). Just import THIS registry file (if you've installed Opera in the main storage; if it's on the storage card, use THIS instead) and voila: everything will be OK. (Just for the record: under WM6, as opposed to earlier operating systems (where this key didn't exist at all and the system used the traditional http association), HKEY_LOCAL_MACHINE\ Software\ Microsoft\ Shell\ Rai\ : DEFBROWSER \ 1 must contain the full executable path of the default browser, as opposed to its name (without the path) only. Two screenshots showing this, with the new contents (assuming Opera is installed in the main storage): 1 2.)
It's very important that this fix should also be used on the Pocket PC platform if you have WM6!

(Note that, after my finding out the trick above, I've been told other people (for example, John Burn HERE) have also been succeeded in finding the solution for the problem. I really ask eveyone to publish their fixes not only in one, model-specific forum not really visited by non-owners of the same model, but also in generic ones. Generic ones include, for example, the forum of Opera Mobile: after having found out the fix, the first thing I've done was posting an announcement in there so that all Opera Mobile users are notified. This way, everyone suffering from the bug notices the fix being available right away and noone tries to reinvent the wheel. I belonged to the latter category: it took me about half an hour to find the fix. Should I have known of the fix already being existing, I wouldn't have wasted time on finding what the problem is caused by.)
Has some minor problems with image handling. When the browser is presented with more than, say, 7-8 images in a page, it may not download them all (or, for that matter, any of them). Give a try to THIS page to see this in effect - on my QVGA Vox, it didn't render any images. The situation was pretty similar on the old(er) Oxygen (with other pages). Note that a forced reload the page, in general (but not always!), helps.
When you manually enter a URL into the "Go to" text input field on the Vox keyboard, you can't enter a string longer than the screen estate size (give a try to entering, say, the above link!) This problem can only be fixed by trying to visit the part that can still be entered and, then, returning to Action / Go to, finding the first part of the URL already entered and going on with entering the latter part(s). Dunno if this problem is caused by the OS or Opera Mobile.
If you define a HUGE cache (to bring down data usage costs), the responsiveness of the browser REALLY decreases. For example, on my Vox, I had a cache with about ~10M files (in the main storage). With that, Opera takes over a minute (!) to start and, after loading a new page (WITHOUT images!) about 10-15 seconds to flush it to the cache, during which you can't for example scroll up/down to go on reading. That is, you need to stick with the default 2M cache to get rid of these problems.
If there is little RAM memory left, the Smartphone dialpad keys (2, 6, 9 etc.) stop working. Instead of their default functionality, they result in reloading pages / moving elsewhere. In these situations, an error message like "Due to RAM memory shortage, the requested action couldn't be done." could be shown.
Again and again, this is more of nitpicking – Opera Mobile for the MS Smartphone still stays THE best Smartphone Web browser. For example, it still supports even saving images (in the Image mode – see the explanation in the usage chart).
Probably the only really annoying bug is the fact that, as of 8.65 beta released on 06/01/2007 and usable until October this year, it only remembers HTTP proxy servers during the first page request after starting; the other requests are directly sent to the HTTP server. To test this, give it a working (for example, at the time of writing, 82.204.47.120:8080 was one of them) proxy address in \Application Data\ Opera\ opera.ini (as is explained in the Toonel-related section) and, then, after restarting Opera, go to WhatIsMyIP.com. Upon the first invocation, you’ll see the proxy’s address as the originating address. Upon later invocations (for example, after just refreshing the page), however, it’ll switch to direct access – and the IP address it displays will also reflect this.
This, unfortunately, means currently you won’t be able to local proxy-based bandwidth usage reduction solutions like Toonel with Opera Mobile. Neither will you be able to use external proxies to either conceal your real IP or get outside of a corporate network.
Note that some of the rendering bugs common with the PPC version are here; for example, the Register bug. The Register (in the examples, I show examples of THIS article) can’t be browsed without zooming out and/or switching to Landscape mode on QVGA screens. This is, of course, using the fit to screen mode (as opposed to the Desktop mode) when browsing The Register. Screenshots: 1 2; a 176*220 screenshot HERE. The Pocket PC version has the similar problem (QVGA screenshot).
In addition to the subtle differences like the image scrolling mode (to allow for saving images on the Smartphone), there is another notable difference between the SP and the PPC version of Opera Mobile 8.65. The PPC version has three display modes as can also be seen in HERE: Desktop, Fit to screen and Single column. Of these, efectively, only two (desktop view and, in general, one-column view) is used on QVGA devices (it’s only on VGA models that there is a real “Fit to screen” mode), but all the three are listed. If you select Fit to screen on a QVGA device, it will, effectively, show everything in one-column mode only (that is, the columns of will be kept). This is clearly visible in THIS screenshot. The only difference between the two modes, on a QVGA PPC, is that if you use your device in the Landscape orientation, then, if you stick to the Single column mode, it will only use 240 pixels of the sligltly less than 320 pixels of the horizontal screen estate. This means you will want to exclusively use Fit to screen on a QVGA Pocket PC. (Again, VGA Pocket PC's are entirely different. Compare the above screenshot to THIS, showing the effect of Fit to screen in landscape mode. As can be seen, there is no unused screen estate, as opposed to the Single column mode.)

The SP version, on the other hand, only has two modes: Desktop and Fit to screen as can be seen in HERE (QVGA screenshot) and HERE (176*220 screenshot). They, however, work exactly the same as the QVGA Pocket PC version, regardless of whether you select Fit to screen or Single column on the latter. Effectively, Fit to screen, Landscape screen estate usage-wise, is the same as the same Fit to screen on the PPC, which can clearly be seen in THIS QVGA SP screenshot, showing THIS MoDaCo Smartphone forum. As can be seen, it uses the entire horizontal screen estate, just like the PPC version in the, on QVGA devices, preferable Fit to Screen mode.
Two other screenshots of the same MoDaCo forum: 176*220 SP, QVGA SP Portrait (the latter being exactly the same on QVGA PPC.)
Note that there will be exceptions from this "everything is displayed as one-column only" rule: not all webpages will be rendered as one-column. For example, one example of this is THIS Finnish stock exchange page, which is rendered as a two-dimensional table on both PPC's and SP's, using even the Single column mode on the former.
To show what happens with this page, I've made several screenshots:
QVGA SP in Portrait (the same in Landscape)
176*220 SP (in, of course, Portrait only) - yes, as can be seen, even in this really low-resolution model the chart is two-dimensional. Note that the "Opera Mobile for Smartphone doesn't load all the images" bug is certainly visible in this screenshot - it didn't load the images (of which only the "Image" placeholder is visible) not after a forced reloading, unlike with the QVGA SP version, which did load them after a forced reload (but not when first accessing the page).
QVGA PPC Fit to screen and PPC One column mode
Again, as can be seen, ALL the tested devices (QVGA and 176*220 SP's and a QVGA PPC in BOTH the Fit to screen and Single column modes) rendered the chart using real, two-dimensional fit to screen mode and did NOT try to force each column into its own row.
1.3 Opera Mini 4.x
{
"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"
}
(VGA PPC screenshot running under the Intent midlet manager (hence the non-used command bar at the bottom); a QVGA Smartphone screenshot HERE)
I’ve often reported on Opera Mini, which, as of the current 4.x series beta, has become a serious contender to even native Windows Mobile Web browsers, particularly on the touch screen-less Smartphone platform, where the lacking features of Opera Mini (for example, lack of context menus or copy / paste capabilities) aren’t a problem because of the lack of the touch screen. (That is, you couldn’t use these features on IEM either – it’s only Opera Mobile, with its excellent link / image context menus even on the SP platform, that still offers a bit more functionality than Opera Mini.)
Should you want to know how Opera Mini can be deployed in current midlet managers (the article explains the IBM J9 and the Intent Tao case; the Esmertec case is really-really similar), you will want to read the related section HERE, in the “A step-by-step Tutorial on setting up Opera Mini” section. Note that the direct link takes you to version 3; to get the version 4 beta, you will want to follow the instructions HERE.
1.3.1 What’s new with the brand new, 4.x Opera Mini series?
Nokia’s having pioneered the quick zoom functionality in their excellent S60 series 3 Web browser, Windows Mobile browsers quickly followed suit: first, NetFront in the second Technical Preview of their forthcoming 3.4; then, Microsoft in their (beta-stage and still far from being finished) DeepFish.
Opera, the, in my opinion, by far the finest (give a try to their desktop browser, particularly if you have an (W)SXGA+ or (W)UXGA screen – you’ll love it!) browser developer company, soon followed suit. In addition to announcing the forthcoming Opera 9, which is a native Windows Mobile application, with similar capabilities, they have also added full page view & quick zoom capabilities to the brand new series of Opera Mini, their Java Midlet-based, small, but still VERY powerful multiplatform browser.

Just visit THIS page (the SWF file, should you want to directly download it, is HERE) and see what Opera has come up with. It’s indeed very cool, isn’t it? All this in a VERY small package (90 kbytes), with almost unmeasurable runtime (dynamic RAM) memory consumption. Compare this to the memory consumption of traditional Web browsers – yes, they consume orders of magnitude more memory. Note that there are a some other, cool videos on Opera’s homepage running the browser in reality – those videos are far more instructive than my static screenshots.
This browser, as has also been pointed out in the Web Browser Bible, runs great on Windows Mobile, on both Pocket PC’s and MS Smartphones, in both common factory-default midlet environments, the Intent (the industry standard on almost all WM5-based PPC and SP phones, except for the Esmertec-based HP iPAQ hx6915) and the Esmertec (shipped with many natively WM6 phones like the HTC Vox / S710) midlet managers.
It’s by far the best J2ME (Java midlet) browser: other Midlet-based browsers are far worse in every respect. For example, jBrowser can’t even display middle-sized pages like the PPCMag blog page, the PPCT main page as can be seen in HERE and, for smaller pages, it will never finish loading.
As has already been pointed out, the best new feature the new version offers is Zoom-in / full page view functionality. Its “let’s crunch the text into the viewable screen estate” works just great – much better than I’ve expected or what most of the other browsers do.
You’ll REALLY love the new page view functionality if you want to check out for example
THIS is the desktop rendition of the Finnish stock exchange in a tabular form. Now, let’s take a look at them in the default, pre-series 4 one-column mode:
and this is how the new, full page layout mode renders it (zoomed in):
and zoomed out, showing the entire page:
A big difference in usability and readability, isn’t it?
Of course, in most cases, if you don’t want to browse tabular data like this, you won’t necessarily need the new mode. Then, you may safely stay with the old, one-column mode.
In addition to providing a page view & zoom-in mode, the Opera folks have come out with something unprecedented in the Windows Mobile world: smart text finding. Let me show you an example with an XDA-Developers thread:
In THIS screenshot, I’ve just started browsing and, therefore, the selection frame is in the upper left corner. Now, let’s press the Down key several times (or, even better, 8 for much quicker navigation downwards). As soon as I’ve reached the body of the text, the selection was automatically (!) scrolled to the right so that no screen estate remains unused on the left side of the screen as can be seen in HERE. Pretty smart, eh?
Now, let’s press Action to read it. As can indeed be seen, the text is very intelligently flowed in a way that no horizontal scrolling is necessary. It’s also really-really superior to how most other browsers handle non-one column modes. Thumbs up Opera, you’re indeed the BEST Web browser developers out there – and this is stated by somebody that knows a LOT about Web technologies and protocols!
1.3.2 Shortcuts
Opera Mini is pretty much similar to Opera Mobile in that it makes extensive use of the phonepad (dialpad) common on all SP models (and, as has already been stated, also available on some PPC models). Unfortunately, the default hotkeys are different, which you, if you often switch between the two browsers, will find pretty inconvenient. (But, then, just edit \Application Data\ Opera\ input.ini to make it similar to the Opera Mini shortcuts. See my other, Opera Mobile-related articles on how this can be accomplished.)
Please see section 1.5 (Shortcuts) to see what shortcuts the two browsers (and, in addition, IEM) offers. They REALLY make browsing MUCH faster – it’s really worth using the dialpad to access them.

1.3.3 Bugs, annoyances in Opera Mini 4.0 beta
The new, 4.0 series being in beta state, it has some, in most cases (if you DO use a compatible Midlet environment), non fatal bugs / annoyances not present in previous versions:
Big minimal font size (as opposed to the current 3.1.* version) and (comparatively) huge gaps between rows. A lot of people have complained about this; in my opinion, this doesn’t hamper the usability of the client.
Cookies are not necessarily kept (as opposed to the current 3.1.* version – you may end up having to logging into your account much more frequently than with the 3.x series)
You may encounter crashes on Pocket PC’s and on Smartphones running other Midlet managers than that of Esmertec. On my Vox, using the factory-shipped Esmertec midlet environment, I haven’t encountered ANY crash over the last month of active (!) usage. See for example THIS XDA-Dev thread on PPC users’ reporting shutdowns / crashes. Most (if not all) of these users use the Intent midlet manager (which, again, is also the default midlet manager on many Smartphones.)
Let me, again, emphasize that while on my brand new WM6 HTC Vox (s710), using the Esmertec Jeodek 20070115.1.1 midlet environment, I have never encountered any Opera Mini 4.0 beta crash (while having been using it at least 2-3 hours a day!), other midlet environments may behave differently. For example, the Intent midlet manager common on most WM5 Smartphones AND Pocket PC's is known to frequently crash on OpMini4 users - it did once on me too when I (quickly) tested OpMini 4 on my HTC Universal (the latter running the 10/1/7/554 / 20060502 version of the Intent manager.) Should you encounter crashes like this, consider switching to either the IBM J9 midlet manager (according to holg HERE, it works just great with Opera Mini 4) or look around in the XDA-Developers forums for help in getting the, again, stable and reliable Esmertec Midlet manager. (I don't know whether it's separately sold; I seriously doubt it.)
The full page layout takes a LOT of memory. If you stay with the one-column mode, unless you load HUGE pages (say, hundreds of kilobytes originally), you, in general, will be able to make use of all the 30 page slots without having to reload any of these pages. If you, on the other hand, switch to the original page (as opposed to the one-column one) layout view, this will be reduced to two or three concurrent pages at most, regardless of the size of the original pages. If you often switch back to already loaded, just-browsed pages and don’t want to reload them because of the time / bandwidth requirements, you will want to stick to the traditional, one-column mode.
Note that the two versions can easily co-exist with each other. That is, if the first three problems become annoying, you can just switch back to the old versions. Unfortunately, as the favorite lists aren’t shared between the two versions, favorites that you add / edit in one version won’t be visible in the other.
1.3.4 Other (non-4.x-specific) problems
There’re still some problems with Opera Mini that may be a showstopper for you.
It’s still unable to render ANY kind of italic text (see for example THIS for a more thorough elaboration and my demos showing displaying italic text is indeed possible on Smartphones, regardless of the midlet manager in use). This is a MAJOR pain the back. I’ve already contacted the Opera folks on this matter; hope they fix this problem.
Binary download support-wise (as it’s using the IEM engine to do the “dirty” stuff; that is, to download files off the Web), it’s suffering from exactly the same problems as IEM:
CAB files with text MIME type are just rendered as text (like THIS); bigger ones (like THIS 1.5M CAB file) result in an out of memory error
non-CAB files with (correct) binary MIME type (like THIS PDF file) are correctly passed to IEM. Unfortunately, as the execution is fully supervised by IEM, you won’t be able to download any of these files because of the well-known problem already outlined in the IEM section.
Finally, CAB files with the binary MIME type (like THIS) are both correctly recognized by OpMini and, then, correctly downloaded by IEM.
And, of course, the other minor annoyances / restrictions (no file upload, no any kind of access to the IEM / Opera Mobile favorites, no URL copying etc.) – you can see them all in the original Web Browser Bible.
1.3.5 Verdict
Currently, while Opera Mini 4 is at beta stage (as is also emphasized in the documents), it’s already highly recommended if you have a SP model.
1.3.6 More information
Opera Mini 4.0 wishlist thread
Opera Mini forum
1.4 jB5
(another screenshot, now with an image)
Now, this is a really promising browser! While decidedly slower than even IEM and lacks highly useful features like FastBack (upon pressing Back, rendering the page from the local memory cache and NOT downloading it again, unlike both jB5 and NetFront) and does NOT offer multiple document capabilities (unlike the two Operas), it’s (as of the current, tested version, 5.0.56) already pretty powerful (for example, it's the only Smartphone Web browser to offer page saving (which is, incidentally, implicitly possible with Opera Mobile if you're ready to find the given file in the cache) and in-page text search: see it in action: 1 2 3) - much more usable than, say, the next-to-useless Minimo. What is more, it's free.
As it's in beta stage and will surely receive an ever better version, I do not thoroughly review and compare its features / standards compliance to the alternatives because the info would be outdated VERY soon. I will, however, definitely review it as soon as it gets into final (or Release Candidate). Make sure you check it out and get your free copy - if you can put up with the somewhat slower page loading / scrolling speed and the lack of multi-tabs / FastBack, you may like it very much.

1.5 Additional technologies
In this section, I elaborate on the Toonel, Java applet and Flash support on Smartphones. Again and again, CHECK out the original Windows Mobile Web Browsing Bible for more info on them. In here, I only give you strictly Smartphone-related information, not generic one you might want to also know.
1.5.1 Flash
Unfortunately, unlike on the desktop, where there is a more or less solid and compatible (albeit pretty slow) official Flash implementation from Adobe (ex-Macromedia; from now on, I only refer to it as “Adobe”) itself (and the alternative, albeit a bit worse and much more CPU-hungry player integrated into NetFront), Smartphone users have always been left in the cold. Much as Adobe has been addressed several petitions (see for example THIS one at MoDaCo), the Smartphone still haven’t received a real Flash player.
There is some light on the horizon, though. Adobe is working on Flash Lite (current version: 2.1), which is already accessible HERE. (If you don’t have an account, make sure you check in “No, I will create one now” as the bottom so that you can register. Registering can be done quickly; only after that will you be able to access the downloads. Note that, should you not want unwanted Adobe mails, you don’t need to check in any of the “I’m a developer / content creator” radio buttons – you can safely set all of them to “No” instead of the default “Yes” – you’ll still be provided access for the download).
Both IEM and Opera Mobile supports this plug-in (see screenshots below). Note that it doesn’t run MOST currently available Flash animations. For example, most games out there won’t run (unlike under the Pocket PC version). Some examples of them are Bomberman and Play with fire (this is what you’ll be shown: 1 2; IEM screenshot).
1.5.1.1 Hacking REAL Flash on Smartphones
I’ve tried to "hack" Flash Lite (overwriting \Program Files\Adobe\ flashlite.dll with the original, “full” \Windows\ Macromedia\ flash.dll). However, the checking for being a genuine Flash Lite animation is done in another DLL (daxplayer.dll); therefore, this hack doesn’t work.
Fortunately, other hackers had better luck. XDA-Developers forum member jockyw2001 has managed to hack the REAL Flash player onto the SP.
(IEM playing back a YouTube video in One Column mode on the HTC Vox)
(other screenshots: Opera Mobile on the Vox doing the same in Desktop mode with 50% zoom, with the SPHelper cursor for controlling the on-screen controls; the same on my 176*220 Oxygen, with 25% zoom)
His thread is HERE (you will NOT need to read it to complete the steps below!) Note that you MUST apply the hacks on an application unlocked phone - it won't work on locked phones. Fortunately, it's pretty easy to unlock your phone (see for example THIS article for some links). Also note that the hack worked just great on both my WM6 QVGA HTC Vox (s710) and WM5 AKU3 176*220 HTC Oxygen (s310). Some people, however, reported problems with other models (see the above-linked thread). I'm pretty sure it's because they have messed up something that the plug-in doesn't work on their devices.

First, get THIS file (it's a slightly rearranged version of jockyw2001's original. For example, I've collected the registry import files into one file and separated the files into directories named after the steps you need to do). UnRAR it with, say, WinRAR. Now, do the following:
If you've already installed Resco File Explorer (along with its registry plug-in) and at least once started the latter, copy All.reg from Step 1 - Registry import to anywhere on your SP and click it from File Explorer. It will be imported into the Registry.
Go to the root directory of your SP and to the Step 2 - Windows directory copy directory on your desktop computer. Copy the Windows directory on your SP.
Go to the Step 3 - flash6 directory on your desktop and the \Windows\Macromedia directory on your SP. Overwrite flash.dll on your SP with the one on your desktop.
Go to Step 4 - regserv and copy regsvrce.exe anywhere on your SP. From inside File Explorer (on your SP), execute it to register Flash. To do this, enter \Windows\Macromedia\flash.dll in the Full pathname... text input field (176*220 screenshot). (To make this easier (to avoid entering the path on the phonepad / keyboard of your phone), I recommend for example Pocket Controller on the desktop. If you can’t use Ctrl-V to paste to there (the case with the version 5.06 + HTC Vox combo, but NOT with the Oxygen), use ViTO’s excellent CopyPaste on the Smartphone to copy the contents of the clipboard to the input field.)
Then, just press OK and “Yes” in the confirmation dialog. After some 2-3 seconds, you’ll hear another bell. Now, start regsvrc.exe again; you’ll immediately see a confirmation (success) dialog (176*220 screenshot).
On the desktop, go to Step 5 - Flash7 and copy flash.dll to \Windows\Macromedia on your SP in order to overwrite the in step 3 copied Flash 6 version with the new, Flash 7 one.
Now you can start enjoying REAL Flash content!
Note that the above tutorial explains how you can install Flash in the main storage. Should you want to install Flash on your storage card (to save 1.5 Mbytes of main storage, which is a real must on Smartphones with less than 128M built-in Flash ROM), do the following (it's pretty much the same as with the previous case, except for the registry file you'll need to import and the paths you need to use; I used the bold typeface to emphasize the differences):
import THIS registry file (it's NOT the same as Step 1 - Registry import\All.reg! Do NOT import the latter!)
Go to the \Windows directory of your SP and to the Step 2 - Windows directory copy\Windows directory on your desktop computer. Copy everything BUT the Macromedia subdirectory to your SP (that is, do NOT copy the latter, only the AppMgr subdirectory and the two files, Macromedia Flash Player ActiveX.unload and nmsrapix.dll, in \Windows.)
On your SP, change the current directory to your storage card - that is, it should be \Storage Card. Create a subdirectory named Windows there and copy the Macromedia subdirectory in there (so that, finally, flash.dll will be under \Storage Card\Windows\Macromedia)
Go to the Step 3 - flash6 directory on your desktop and the \Storage Card\Windows\Macromedia directory on your SP. Overwrite flash.dll on your SP with the one on your desktop.
Go to Step 4 - regserv and copy regsvrce.exe anywhere on your SP. From inside File Explorer (on your SP), execute it to register Flash. To do this, enter \Storage Card\Windows\Macromedia\flash.dll in the Full pathname... text input field and go on as explained in the main storage-centric tutorial.
On the desktop, go to Step 5 - Flash7 and copy flash.dll to \Storage Card\Windows\Macromedia on your SP in order to overwrite the in step 3 copied Flash 6 version with the new, Flash 7 one.
The plug-in works great (additional screenshot); you’ll need a cursor emulator like SPHelper to click labels / buttons like in THIS screenshot.
Note that both IEM and Opera Mobile are able to make use of the plug-in. The two programs have somewhat different strengths and weaknesses.
First, IEM can't make use the up/down arrow keys; that is, if you would like to, say, play a game depending on these two directions, they will be unplayable. In these cases, you MUST use Opera Mobile. Second, as far as playing back YouTube videos is concerned, while IEM (unlike on the Pocket PC – it’s pretty strange the SP version of IEM is better in this respect) you will want to prefer Opera Mobile because it’s slightly faster at playback. You will still want to overclock your phone - if it’s a TI OMAP-based one, with OMAPClock.
Under Opera Mobile (as opposed to IEM), in the default mode, the flash plug-in size will be really tiny as can be seen in HERE. (Therefore, you’ll want to switch to Desktop mode and use a Zoom level of, on QVGA machines, in general, 50%, and, on 176*220 models, 25%) Unfortunately, you will still have problems with scrolling down / right – in the default, link scrolling mode, you will only see the top left part of the page and won’t be able to scroll anywhere (not even clicking the scrollbars with SPHelper). To fix this (and to scroll down to the Flash animation), you MUST switch to Image (scrolling) mode. With Opera Mobile, the up/down arrows do work, unlike with IEM, as can also be seen in THIS screenshot (otherwise, I couldn’t have been able to go down).

1.5.2 Toonel
Toonel, the transparent compressor proxy, is a GREAT way to save data usage costs. If you don’t have an unlimited data plan, you really should check it out by, first, reading my related article & tutorial HERE. I’ve published several articles and tips on Toonel; the just-linked one is the one to start with.
While, it seems, it’s not possible to make the native Windows Mobile version work, the Java versions does work on Smartphones.
As far as the native Windows Mobile version is concerned, according to the folks HERE (thanks for the link to the Toonel folks; it's Russian - Babel "translation" HERE), some people managed to make the native (.NET CF) version of Toonel run. I haven’t succeeded in this on either of my Oxygen or Vox.
Fortunately, the Java version works. In general, you’ll only need the (brand new) CrEme 4.12 (download the TI OMAP version of the 4.1 series if you have a TI OMAP-based Smartphone) and THIS JAR file (version 0.45 - do NOT use version 0.50!). Install CrEme (you can do this on the storage card too – then, however, you’ll need to modify the link file I give you), copy the JAR file to the root directory of your handheld (you can, actually, copy it anywhere – but, then, you’ll need to modify the link file I will give you soon) and, then, copy THIS link file to \Windows\Start Menu. Then, just click the latter to start Toonel in the background. Upon start, you should see THIS screen. If you see THIS (note the bind() failed message!), it shows Toonel is already running.
Note that the CrEme process takes quite a lot of memory (but, fortunately, little CPU time – about 1-2% - when inactive) as can be seen in HERE. Beware of this fact – the operating system may kill the CrEme (Toonel) process in the background, particularly if you start other, memory-intensive programs. Then, you will just need to restart the proxy by clicking the startup script.
As, currently, the SP version of Opera Mobile (as with old 8.60 Pocket PC builds) doesn’t have internal support for entering proxy servers, you must enter the proxy information in the config file by hand. However, as with the old PPC betas, you can easily configure the proxy server by just editing \Application Data\ Opera\ opera.ini and adding the following section:
[Proxy]
Use HTTP=1
HTTP server=127.0.0.1:8080
Enable HTTP 1.1 for proxy=1
A screenshot of the Web admin interface of the locally running Toonel on my Vox:
As can clearly be seen, there was about 80% (fourfold!) bandwidth usage saving during the active session. This alone makes Toonel really worthy if yours is not an unlimited data plan.
A quick visit to WhatIsMyIP also shows it’s through the Toonel server that you’re connected (85.25.148.242 is one of the IP’s of the Toonel servers).
It’s VERY important to remember that, currently (as of 07/10/2007), the SP version of Opera Mobile does NOT reliably support proxy servers. Therefore, if you absolutely must use Toonel (or ANY external proxy server), you MUST use IEM and forget Opera Mobile.
As IEM, as with the PPC version, also depends on the operating-system level proxy settings (unlike other browsers), you must also configure the system to access the Net differently than before. That is, do the following:
in IEM, go to Menu / 9 Tools / 3 Options / Connections, untick “Automatically detect settings” and select “Work” in the list as can be seen in HERE
in the system-level Settings, go to 6 Connections / 6 Proxy, press Action on New and create a new record as can be seen in THIS screenshot (as can be seen in HERE, just leave “Type” on “HTTP”). You can name the proxy setting anything; in here, I’ve called it ‘t’. That is, all you need to do is setting “The Internet” to “Connects from”, “Work” to “Connects to” and entering “127.0.0.1:8080” in “Proxy (nameort)”.
Note that, after this, you will need to configure your other programs also using the system-level settings to use Toonel instead of a direct connection. Unfortunately, I haven’t managed to configure the built-in Messaging to use the built-in POP3 proxy support of Toonel (as opposed to the Pocket PC Messaging). Also, remember that, should you have the built-in Live (or MSN) Messenger, defining the proxy will also render them useless.
Unfortunately, it seems it’s not possible to make these programs work with a proxy defined in the above way. That is, you will need to delete the proxy every time you want to access your mail. It seems there are no other ways of disabling it - for example, setting the source / target networks to something else doesn’t work.
Again, keep in mind that you can have Toonel activated for IEM (that is, using a system-level proxy setting) AND still access your mail (both compressed, via Toonel, and uncompressed) via other, Smartphone-compliant mailer clients; for example, FlexMail. With the latter, you can safely use the compression offered by Toonel too and the mails downloaded just OK.
1.5.3 Java applets
While the IEM plug-in of the just-released CrEme 4.12 (the only Java Virtual Machine to be compatible with the Smartphone AND have an applet plug-in) can be registered, it doesn’t seem to be working, unlike on the Pocket PC.
Neither the applet-based Radar Weather test nor the local demo applet (Cube) shipped with the system work: the JVM plug-in just keeps showing "loading applet". Example screenshots: 1 2 (Vox); 3 (Oxygen).

1.6 Keyboard shortcuts
I’ve compiled a chart of the three SP Web browsers showing how a given functionality can be accessed. As can be seen, in general, Opera Mini requires the least button presses to do something (assuming IEM and Opera Mobile run in full-screen mode, which also means double initial softkey presses instead of just a single one to access something in menus only – that is, not having a direct dialpad shortcut).
Keep in mind that, if you extensively use the dialpad (for example, to directly enter the number of the menu item you’d like to activate – these numbers are shown in all menus and I also reproduce them here), you can navigate MUCH faster than using the D-pad to scroll up/down a menu.
You can find the chart here - make sure you check it out, you’ll find it REALLY useful!
2. Non-working or not recommended browsers
2.1 Thunderhawk 2.0
Unfortunately, this browser wasn’t updated for WM5. This means neither the SP2003 (1 2) nor the SP2002 version (these are the two versions available for download) can be installed on WM5/WM6 SP models. All in all, forget about it for the time being.
2.2 NetFront 3.4 Technical Preview 008
NetFront is a well-known browser, which, as of the Technical Preview (TP) versions of the forthcoming, 3.4 version, also received (still a bit flaky) Smartphone support. (No, don’t expect version 3.3, the currently avaailable non-preview, commercial version to run on the Smartphone – it can’t be installed).
(a 176*220 screenshot; the same device scrolling through a stock exchange list in Normal (desktop) display (rendering) mode)
(Note that most of these are all non-full screen screenshots. I used them to prove the screenshots have indeed been taken on a Smartphone. In reality, especially on 176*220 devices, you will want to stick to full screen mode to maximize the screen estate available for browsing).
Note that, currently, the last TP version is 008. You will, however, want to prefer the earlier, 007 version (see review HERE) accessible for example HERE because version 008 is far more restrictive and the two versions have the same expiration date.
The main difference between the PPC and the SP version is that you can’t navigate to the address bar of the latter using any keys (or any menu). This means you must use a cursor emulator like SPHelper to click the address bar; that is, to transfer the focus there.
It’s very important that, after you load the program, it’s only the command bar (the two softkeys) that will change, nothing else, as can be seen in HERE. To bring up the standard Netfront GUI (with the address bar), you will need to navigate to Menu / View / Full Screen. It’s then that you will be presented the standard NF GUI and start working / browsing via, say, going to Menu / File / Bookmark (or Operation / 6 Bookmark) or, with SPHelper (or any other cursor emulator), activating the address bar.
Note that while you can’t navigate to the tabs (if you do open more than one tabs) using the D-pad, you can easily access them via Menu / 1 Window for both switching to and closing.
Unfortunately, the restrictions of the PPC version also apply here; most importantly, the inability to redefine keys / buttons to quickly access any kind of functionality. This is especially annoying with the Smartphone version, where you have tons of easily accessible buttons, which are heavily used by all major, highly-recommended Web browsers (Opera Mobile, IEM (particularly after hacking the Registry) and Opera Mini but not jB5 as yet). In here, you can’t even use page scroll using the touchpad. In addition, not even the Smartphone “back” button works (which does work in both Opera Mobile and IEM) to quickly return to the previous page.
Interestingly, while there certainly is Flash support on the Smartphone (example screenshot HERE), YouTube, as opposed to the PPC version, doesn’t work. Remember that you need to activate Flash manually and also remember that it will chew through your battery if you navigate to any Flash-enabled web page – yes, it’s still very weak, battery usage-wise. The Access folks should immediately look into this problem.
All in all, while it’s certainly usable, it’s, on the Smartphone platform, not as convenient (and battery-friendly, for example, Flash-wise) as Opera Mobile or IEM. Only use it if you REALLY want to stick to NetFront and you can put up with the restrictions (not directly accessible address bar, sub-par Flash support etc).

2.3 Webby
Unfortunately, it doesn’t run either. While it can be installed, it refuses to run (1 2 3).
2.4 Minimo 0.2
(the latter is a 176*220 screenshot; as can be seen, only the last, Menu (…) icon is invisible; however, transferring the focus to it will also work. Too bad it turned out to be pretty unreliable on my WM5 AKU3 s310 (Oxygen)– even more so than on my QVGA Vox. For example, it didn’t even finish loading the SPT homepage as can be seen in the above screenshot.)
While it can be installed on SP’s, on this platform it’s far from perfect and, in general, useless, for the following reasons:
it has HUGE memory usage (the biggest problem with the 0.2 version on the Pocket PC platform too). After loading, it consumes about 12Mbytes and, when you load additional pages, this decreases even more, leaving little (if any) RAM memory
accessing the icons (to, for example, bring up the address bar) at the bottom can only be done using the right softkey. This, on the other hand, first, iterates through ALL the links in the page (yes, ALL of them), and only after this moves down to the bottom icons. A mouse emulator like SPHelper doesn’t help (to directly click the icons at the bottom) – Minimo just doesn’t sense the mouse clicks (that is, left softkey presses)
the browser often crashes (mostly if you run out of memory) and is generally slowish
All in all, I don’t recommend it. Also see for example THIS and THIS for more info / user opinions.
Note that the other available version, Minimo 0.16, isn’t installable on Smartphones at all.
UPDATE (later the same day):
in THIS thread, MoDaCo forum member holg posted something definitely worth reading - it, for example, explains how you can directly start Opera Mini from the alternative, by me, often-discussed midlet runner environment, the IBM J9. It also shows how external proxies can be used with this environment.
SPT frontpage
Cross-posted to: PPCT, SPT, MoDaCo, AximSite, XDA-Developers, BrightHand, FirstLoox, HowardForums.

UPDATE (08/31/2007) : Opera Mini 4 beta 2 out; the FULL review has been posted to these forums: PPCT, AximSite, XDA-Developers - 1, XDA-Developers - 2 FirstLoox, BrightHand, HowardForums, SPT, MoDaCo, Opera Mini forums.

UPDATE (10/20/2007): I've published a review of Opera Mobile 8.65 Final (PPC/SP), Picsel 1.0.5 (PPC/SP) and the brand new Spb Pocket Plus 4.0 (PPC). A new version of jb5 (PPC/SP) has been released and a brand new, albeit very simple IEM add-in Web Viewer for WM5 (PPC). Also, I’ve linked in some of my recent reviews of some new (not very important) Web browsers: TeaShark (PPC/SP) and UCWEB (PPC/SP). Finally, I've published some genuine, never-before-published tips and tricks on utilizing the Pocket PC hardware application buttons to control Opera Mini and Opera Mobile. It's a MUST for any serious Pocket PC user - you'll LOVE my new tips & tricks. See THIS. Cross-posted to: PPCT, AximSite, XDA-Developers - 1, XDA-Developers - 2, FirstLoox, BrightHand, HowardForums, SPT, MoDaCo.

Skyfire browser for WM6.1
Nice rundown on browsers but why is Skyfire not covered here? I just loaded it onto my Samsung Jack and it seems to be pretty good (better than IEM).
Would have liked to know how Skyfire compared to Opera and other browsers. fyi

My W3C speech on Web browsing + a full explanation

As has been announced some weeks ago, I had a W3C speech a week ago devoted to Web browsing on mobile devices. You can find the (English) slides HERE. (Sorry, some of the example screenshots are in Finnish. This, however, doesn’t have a detrimental effect on the overall understandability of the material.) In order to understand the slides, I’ve also decided to comment on all of them so that the entire Windows Mobile, Symbian and BlackBerry mobile community can benefit from my speech – in written form. Finally, note that, albeit this article is over 80kchars long, it in no way can provide a FULL, absolutely thorough overview of the Web browsing scene on these platforms. That is, if you don’t understand something, don’t despair: in my referenced, previous articles, you can, in most cases, find a very thorough dissemination of the subject. Just an example: in this article, I only devote some 2kchars to the subject of downloading files while my original, devoted article, along with its (recent) updates, amount to over 100 kchars.
I also provide in-line screenshots in this article so that you know what I'm speaking about without constantly switching to PowerPoint; however, to see the original document at its full (and copy/pasteable) glory and resolution, you'll need the PPT file.
(Sorry for the comparatively bad quality – captured from the 1024*768 M-JPEG video(!) recording of my Canon 960IS camera.)
{
"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"
}
(no comments needed)
(just some self-promotion )

(Promoting my employer and me. Incidentally, should you want to support my employer - and, through that, me - with a, say, contract for some kind of development or any kind of IT consultation [if you work for a company that would like to outsource some kind of consultation or quality (!!!!), in-depth research], feel free to contact me and I’ll make sure my employer contacts you back. Even a, say, US$ 50,000 project would be welcome. I’ve been a generic – not just mobility! – IT consultant and lecturer [for example, for Sun’s Java training courses], but am also well versed in traditional Electric Engineering stuff like telecommunications and signal processing; see for example my forthcoming Digital TV / Telecommunications Bible for more info on the latter. That is, I’m in no way a mobility-only type of professional. In e-mail [werner AT pocketpcmag PISTE com, where change AT to @ and PISTE to . (dot)], I’m also ready to provide you with a more thorough list of past IT consultation, education etc. projects. It’s me that would be working on these contacts; together with an English editor to get the English right. I only expect serious inquiries. Please, if you like my articles and would like to see similar articles come out in the future too [it’s mostly because I have a lot of free time and a really cool environment at work that I am allowed to work on articles even during work hours], look around at your company to see whether there’s some way of outsourcing your, say, consultation, education or research needs. International contracts [on which I/we’ve worked several times] are welcome.)
OK, let’s get to business. Given that in a 45-minute speech it’s entirely impossible to give the listeners a complete, detailed picture of the problems, the compatibility issues of each and every browser for all the three operating systems, I’ve added references to all slides (whenever applicable). To quickly look up the referenced article / Bible, just change “1327” in http://www.pocketpcmag.com/blogs/index.php?p=1327 to the number given after „Ref:“
Also, you’ll need to be aware of three articles not (always) linked as references. The two Windows Mobile Web Browsing Bibles have the reference number 1828 and 2084 for Pocket PC’s and MS Smartphones, respectively. They, therefore, translate to real URL’s http://www.pocketpcmag.com/blogs/index.php?p=1828 and http://www.pocketpcmag.com/blogs/index.php?p=2084 . My Opera Mini 4.1 (Ref: 2571) review, which is currently not discussed in either of the Web Browsing Bibles, is worth checking out for the latest information on this excellent browser. Also, you can find all my Web browsing articles in the Web Browsers category on my blog at http://www.pocketpcmag.com/blogs/index.php?blog=3&cat=61
There are several established mobile operating systems (platforms). In this slide, I quickly list them. Of course, this is just a very high-level overview of the operating systems; it’s later that I elaborate on them more thoroughly; one by one.
Web browsing-wise, probably the most advanced platform is Windows Mobile (WM for short), which itself has basically two, starting with WM5, converging subplatforms: touchscreen-enabled Pocket PC’s (PPC for short) and touchscreen-less MS Smartphones. In WM6 parlance, they’ve been renamed to Windows Mobile 6 Professional / Classic and Windows Mobile 6 Standard, respectively. I’ve also listed Handheld PC’s for completeness (and as an introduction to the slide explaining the evolution of the built-in Web browser pre-installed on WindowsCE devices in the past 11.5 years), which are a dying breed.
Symbian is another, very important, consumer-focussed mobile operating system. The most featureful browser for its most popular breed, Nokia’s Series 60 (S60), is the Nokia S60 Web. They are, in addition, also able to run Opera Mini and other MIDlet-based browsers. It also used to have an Opera Mobile port, as was the case with some Linux-based models like the Sharp Zaurus.
RIM's BlackBerry is a very important business (and, with the advent of more consumer-friendly models like the Curve and Pearl and the, particularly multimedia-wise, really enhanced 4.5/4.6) operating system. Its Web browser has traditionally pretty bad. With operating system version 4.5/4.6, however, it has undergone a major facelift and received a lot of new features. For example, now, searching for text in pages works. This highly useful feature is only supported by very few other browsers – for example, it’s only been introduced to the two Opera browsers this year.
The hugely popular Apple iPhone runs Safari. It’s really a decent browser. The only real disadvantage is the complete lack of, for example, Flash (Lite) support. As YouTube (one of the major usage areas of Flash as of today) has a dedicated YouTube client, this isn’t that big a problem. Note that, unlike with the first three operating systems (and like all the following ones), I don’t elaborate on this operating system in the rest of my speech. Currently, iPhone doesn’t have Java MIDlet support; therefore, you won’t be able to run Opera Mini on it. Java, however, will be - hopefully - soon added.
Linux, after the, unfortunately, discontinued, but, technically, really-really excellent Sharp Zaurus series, seems to have been reborn: Nokia's Web Tablets and the non-Nokia phones based on the LiMo foundation’s operating systems are gaining popularity. Note that, as far as the old Zaurii are concerned, it had both Opera Mobile and NetFront (NF for short) preinstalled.
Finally, the once market-leading Palm OS is pretty much dead now; this is why I don’t elaborate on its (compared to what is available on Windows Mobile, iPhone and Symbian, not very advanced) browsers like the, with newer versions being NetFront-based, Blazer at all. Unfortunately, the only MIDlet manager (an environment to run Java-based applications like the Opera Mini browser) for the operating system is IBM’s now-discontinued J9, is really buggy and crashes frequently; this means you can’t even use Opera Mini on the platform.
First, let’s take a closer look at Windows Mobile and the core operating system, WindowsCE, paying special attention to how the built-in browser was enhanced during the 11.5 years of maturation.
With WindowsCE 1.0 (Handheld PC), which was released in early 1997 and used on several models like the HP 300/320LX, the Philips Velo etc, has only a really basic (no frames) but already online (non-offline) browser. (We’ll soon see why I emphasize it being online.)
The next two major releases of the operating system, WindowsCE 2.0 and 2.11 (released early 1998 and 1999, respectively) has gone in two directions to cater for people wanting a really palm-sized and, to keep the size down, keyboard-less version of the, compared to the, then, like-hot-cakes-selling Palm handhelds, not really popular WindowsCE models. The new form factor was named Palm-size PC (PsPC). Several WindowsCE hardware manufacturers released PsPC’s; for example, Casio released the Cassiopeia two-digit series (E10 etc.); Philips released the Nino, HP the Jornada 430 which was even featured in a James Bond movie etc. These devices only offered offline browsing; that is, if you had any kind of Internet connection on them (via, say, an infrared connection to a mobile phone), you still couldn’t directly access any Web pages. Instead, you needed to use the desktop based ActiveSync tool (earlier called as WindowsCE Services) to fetch the pages for you and synchronize it to your handheld for offline viewing.
It was only in the “traditional” Handheld PC handhelds, for example, the HP 360LX/620/680 (with the OS version 2.11, called Handheld PC Pros) that still had online access capabilities with a hugely enhanced and updated Web browser much better than the one in WinCE version 1.0.
The market’s answer to the 2.x-series handhelds was pretty much lukewarm. This also resulted in several manufacturers like Philips leaving the scene for ever. It was not before mid-2000, with the release of WindowsCE 3.0 and its hugely popular Pocket PC platform (a heavily enhanced version of the PsPC platform, fixing a lot of issues like the lack of online browsing support) that anyone would say WindowsCE-based handhelds would seriously endanger the market penetration of Palm handhelds and BlackBerry messengers.
WindowsCE 3.0, which was released in May 2000, was the first really successful MS mobile op. system. As with the 2.x series, two operating system subversions were based on it: the, technically, much more advanced (for example, its built-in browser was already capable of finding text in pages, which the Pocket PC version isn’t even now capable of) Handheld PC 2000 (HP 720/728 etc.) using the traditional clamshell form and the descendants of Palm-size PC’s, now, renamed to Pocket PC’s. The latter received an online Web client again; at the time, it was clearly less capable than that of the Handheld PC 2000 OS. Ironically, the latter operating system has practically died out pretty soon and now (its descendants) is used in niche models only.

Let’s go on with the Pocket PC operating system and its built-in browser, Pocket Internet Explorer (PIE). This was, incidentally, renamed to Internet Explorer Mobile (IEM) in 2005 with WM5.
In late 2001, the first version of the PPC OS (also called Pocket PC 2000) was updated to PPC2k2 (2002). While it did have certain advantages over the old operating system, Web browsing-wise it was more of a step back in speed / memory handling because it was incapable of rendering larger (about 150+ kbytes) pages – unlike its predecessors and successors.
In Spring 2003, Windows Mobile 2003 (WM2003 for short; notice the operating system name change!) followed with a much-much better built-in browser with, among other things, CSS support added. (Previous browsers didn’t at all support CS sheets.) Then, in Summer 2004, WM2003 Second Edition (WM2003SE) followed suit, with the native One Column mode being the most important enhancement (on which I’ll elaborate later), Web browsing-wise.
In Autumn 2005, WM5 arrived, also renaming PIE to IEM. It contained a heavily bugfixed IEM engine – some CSS contructs no longer result in the prompt termination of the PIE session, unlike in WM2003(SE). It was also the first PIE (IEM) version to support file uploading – a painful omission from previous PIE versions.
WM5 (and subsequent operating system releases) was also unique in that internal updates during the lifespan of the operating system were well-documented and referred to, easily checkable by an end user, via “AKU” versions. Just some major enhancements: while the initial WM5 IEM browser was pretty very slow to load Web pages, AKU 2 has fixed this almost completely. AKU3.5 introduced a High-Resolution switch for high-resolution VGA devices – another long-demanded feature.
In Spring 2007, WM6 followed suit, with no real improvements except the support for IFrames. Finally, this (2008) Spring, WM6.1 was announced with no real improvements either; a fully revised and enhanced version (a full port of the desktop IE6 engine) is promised later this (2008) year.
Speaking of the built-in browser, it still is pretty much incapable when compared to alternative browsers like Opera Mobile or even Mini. This is why there exist several so-called “plug-ins” or, with some less popular solutions, “shells” to enhance its functionality by adding, for example, multi-document (multitab) support. The most important plug-ins are as of today: Spb Pocket Plus, PIEPlus and MultiIE.
In the rest of my presentation, I’ll return to the compatibility issues of IEM several times; for the time being, let’s check out the other, alternative browsers.
In addition to PIE / IEM, there are several third-party browsers on Windows Mobile. Let’s start with standalone, native Windows Mobile ones (native means you don’t need to run them in a specific environment like a MIDlet manager). The first group is non-streaming too, meaning no excess data fees over a non-flatrate connection / inability to use over non-3+G connections.
* Opera Mobile: probably the most important Web browser. It’s, more or less, based on a direct kernel port of the desktop engine, meaning excellent compliance with core Web standards. Note that the currently, officially available version, 8.65, is still based on the 8.x core; it’s only the latest, 9.x-series Opera Mobile that have, finally, switched to the 9.x core and delivers full compliance with all current standards. While it’s a fairly new browser (the first beta was released in early 2006), it’s taken the Windows Mobile Web browsing scene by storm and is the preferred Web browser of many.
* NetFront is a long-established browser. Unfortunately, while it does have its merits, the development seem to have slowed down and several major bugs haven’t been fixed for years. (For example, you still need to rely on the definitely inferior built-in Flash interpreter instead of having the ability to use external, official and much better-quality Flash plug-ins.) I really hope Access, the developer of NetFront, finally starts to make some serious enhancements to this browser.
* Thuderhawk: this is another long-established browser. The classic (native Windows Mobile) client has received no real improvements in the last about two or three years (except for adding Java applet support back in 2006) and it seems it’s completely abandoned as the company is switching to a MIDlet-based and, therefore, truly multiplatform (not only WinMo) solution.
* Minimo, which is an unofficial and, now, abandoned Mozilla Firefox-port. Unfortunately, I can’t really recommend this browser – its speed, performance and memory consumption is pretty bad when compared to most of the alternatives. Note that it has nothing to do with the real, official Windows Mobile Firefox port announced some months ago.
* Picsel’s browser is an OEM-only one and, therefore, can’t be acquired (legally) if it isn’t included in your factory ROM. It’s pretty slow and is incompatible with even basic Web standards. Nevertheless, some people still like it.
* Maximus: it’s a really poor and in no way recommended browser.
Streaming-based but still native browsers follow. The most important of them is SkyFire which, currently, only works in the 3G networks of the U.S. As I’m in Europe, I can’t really give it a thorough ride at the moment. Another, similar (but, based on the raving user reports on SkyFire, speed- and usability-wise, really inferior) solution was Microsoft’s DeepFish, which has been discontinued in the meantime. Also note that there are other, streaming-based, dedicated mobile solutions like DataWind’s PocketSurfer 2.
Finally, let’s elaborate a bit on MIDlet-based browsers. Their biggest advantage is the compatibility with all other mobile platforms, including even “dumb” feature phones (but excluding BREW-only dumbphones used in some American networks). This will even include the iPhone as soon as Sun (and Apple) gets their MIDlet manager, the environment you can run MIDlets in, ready. Their biggest disadvantages are
1. the somewhat reduced speed. In practice, however, you won’t really notice this; the only real difference is the download speed when you use the in-process download manager, as opposed to using the system-level Web browser to download files. As you will want to prefer the latter, this isn’t an issue.
2. the lesser integration with the operating system. For example, you can’t copy arbitrary text from Web pages. This can be done in a very awkward way with Opera Mini 4.1: save the page to a file and inspect the saved file (containing the Web page in a textual, albeit non-HTML form) with a copy-capable file viewer.
Another major issue is the inability to make the browser the default one for the entire system – at least for non-Windows Mobile operating systems. On the latter, thanks to me and two other developers, this is already possible, making your life much easier: you can now just click links in a, say, e-mail and Opera Mini (or, alternatively, any other Java MIDlet-based Web browser) opens the given page.
Of the MIDlet-based (non-native) browsers, it’s Opera Mini that is the most important. Now, as of version 4.1 and all its new goodies (like file upload and page saving), along with our direct invocation tools, it’s a serious alternative to fully-fledged, non-Java-based browsers.
Some other MIDlet-based browsers include TeaShark and UCWEB. The brand new version of Thunderhawk (TH for short) is also Java-based but is strictly OEM only and isn’t available for the general public.
BlackBerry from RIM, as has already been pointed out, is mostly a business “push mail” platform, only recently opening its gates for the consumer wanting more multimedia and camera. Officially, it’s still at OS version 4.2 / 4.3; the new version, 4.5 / 4.6, is slated to be released in a few months. In the meantime, you will really want to check out the (largely unofficial) betas as they offer a lot of goodies seriously enhancing the usability, user- and, through the new fontsets, eye-friendliness of the platform.
In the two screenshots at the bottom of the slide, you can see how the old, 4.2 OS (on the left) rendered the first few entries in my Opera Mini favorites list and how the same is done under 4.5 (on the right). As can clearly be seen, under 4.5, much more contents can be displayed on the screen and the fonts are much better-looking and readable.
As far as Symbian is concerned, there used to be several subversions of Nokia’s Symbian. (Here, I don’t elaborate on Sony-Ericsson’s handsets.) Of them, S60 is the surviving one and the once-common S80 and S90 versions are both dead. A major breakthorugh, touchscreen, will be added this or next year and Nokia is promising an iPhone killer, Nokia Cube.

S60’s later versions (namely, ones that represent the 3rd generation of S60, S60 3rd, and come with Feature Pack 1 (FP1) or [in the future] higher), have an excellent built-in Web browser, Nokia S60 Web. It’s based on WebKit, an excellent core to build Web browsers on. It also supports Flash Lite 2 and 3; the latter has been delivered in firmware updates (v21 for the N95) and not as standalone downloads. Flash Lite 3 is much better to play back YouTube / other videos than the full Flash 7 on Windows Mobile.
On the screenshot on the right, you can see one of its major features, the minimap, in action. It helps in positioning on a page quite fast and is, now, widely copied by other browsers like NetFront 3.4+.
Now that we have had a bird’s view overview of what’s available on the three platforms (and, as far as Java/MIDlet-capable phones are concerned, - including, sooner or later, the iPhone - all of the other), let’s take a closer look at the issues a mobile Web browser can be confronted when browsing pages originally targeted at desktop (and not resource-restricted, dumbed-down mobile) browser users.
First, you need to consider architectural restrictions, the (comparatively) small amount of RAM (dynamic) memory (10...90 Mbytes on higher-end handsets; (much) lower on feature phones) being one of the biggest problem.
While you can, generally, build up the in-memory representation of even several kilobyte-long Web pages using less than 10 Mbytes, having restricted RAM severely restricts the handset’s ability to store multiple Web pages in-memory for quick access without having to re-fetch (re-download) them. Note that dynamic memory consumption-wise, I really recommend my thorough RAM usage tests in the Web Browsing Bible.
Different Web browsers certainly have vastly different memory needs; this is why, for example, Opera Mini 4.1 is able to keep up to 30 pages in memory even on devices with little RAM. Opera Mobile consumes about an order of magnitude more memory, but is still about two two three times better than IEM, NetFront or Minimo.
The CPU efficiency (a 624 MHz Intel / Marvell XScale is equivalent of a max. 200-300 MHz Pentium) can also be an issue, particularly if you provide dynamic content. While Java Script and Ajax (if it’s compatible at all) run pretty OK, the case isn’t necessarily the same with embedded Flash content, particularly on Windows Mobile platform, where the current, official Flash 7 plug-in is pretty slow. (NetFront’s own Flash interpreter being even worse.) As a rule of thumb, you should use Flash Lite 2 or 3 instead if you want flawless, fast execution. (Currently, Flash Lite 3 is supported by Symbian only and Windows Mobile is slated to introduce support only later.)
On mobile devices, cache reading / writing can also be about an order (or even more) of magnitude slower than on a desktop / notebook hard disk (1-2 as opposed to 20-40 Mbyte/s being typical). This means far higher page loading times if the particular browser employs a bad caching algorithm. (I’ve also very thoroughly elaborated on all these issues in the Bible; the reader is referred to it for more info.)
Multitab browsers may also be affected by the process number restrictions under pre-Windows Mobile 7 (that is, all current) operating systems. This will mostly result in issues with multitab browsers spawning an entirely new process for each and every tab (all IEM plug-ins work this way); that is, not with, say, Opera Mini.
Finally, "from stratch" browsers (that is, browsers that aren‘t direct ports of any established desktop Web browsers; some examples are NetFront, Thunderhawk, UCWeb etc.) generally suffer from severe bugs / errors on even the HTTP protocol level, let alone higher-level HTML / CSS bugs.
Let us still elaborate on the question of what a mobile browser can be used for. As has already been pointed out, their biggest advantage on all mobile platforms is the fact that you aren’t restricted to specially formatted PDA/handset-only pages like WAP pages and you can access full pages initially meant for desktop users. This makes it possible for you to access orders of magnitude more pages than some 5-6 years ago with feature (dumb) phones’ only able to access WAP pages.
However, as has already been explained in the previous slide, you need to be avare of several possible problem areas when accessing an initially desktop-optimized page.
* First, >500k HTMLs (for example pages generated by Snitz Forums 2000 or even YouTube) may result in a severe slowdown or even crashes on the client; under Windows Mobile, particularly under the PPC2k2 operating system, which, as has already been explained, only allows for rendering max. 100-120k HTML pages without crashing
* As has already been explained, under IEM, the memory usage is about an order of magnitude more than the original size of HTML. With alternate browsers (particularly with Opera Mini and, to a lesser degree, Opera Mobile) this isn’t an issue.
* (Desktop) ActiveX controls are not supported, not even on Windows Mobile because it’s not an x86 architecture and, therefore, can’t run native x86 code.
* Some browsers (IEM and, particularly, Thunderhawk and Picsel) have very weak JavaScript support
* Unfortunately, Java applets (login, authentication) are only supported by custom third-party JVMs only. What is more, it’s only available on Windows Mobile – that is, there’s no applet support at all on Symbian / BB. On Windows Mobile, applet support is pretty restricted and is only compatible with up to JDK1.4 (unless you use Thunderhawk). There's no official support from Sun on these three platforms either, unlike on iPhone.
* I’ve already mentioned the Flash incompatibility and problems and the less important HTTP/HTML problems, bugs and restrictions.
On slide 8, I’ve already elaborated on the different networking models used by Web browsers, as far as client-middle tier server streaming-based vs. standard, middle-tier-less browsers are concerned. A nonstandard setup can be vastly different from the pretty much bandwidth-hungry streaming-based solution, however. On this slide, I further elaborate on this distinction.
Most online (as opposed to offline; see for example AvantGo, Mobipocket Reader or iSilo offline web downloading and ActiveSync-based syncing to the handset) browsers use direct connections.There are, however, clients that do have a (sometimes simplified) client-side textual (!) renderer component – as opposed to traditional streaming clients (SkyFire, DeepFish and specialized hardware like PocketSurfer 2) – don’t consume much data. On the contrary: one of the design goals of these clients was to vastly reduce data usage, which is of paramount importance with non-flat rate connections - like those of Canadian mobile operators - and make them usable even over super-expensive, typically, 3...5 Mbyte/month BlackBerry data plans. That is, they work in exactly the opposite way as data-hungry apps like SkyFire and deliver considerable data saving even when compared to accessing the same Web pages with a standalone client.
The most important of these client/server browsers, making use of (pretty much) transparent proxies, are Opera Mini (and most of? all? the other MIDlet-based browsers) and Thunderhawk.
These solutions have some drawbacks:
* possible eavesdropping (definitely not the case with Opera; as far as some new, “noname” Chinese browser companies are concerned, however, many believe that the opposite is true; as a rule of thumb, never ever enter any credit card info in any of these new and pretty much unknown browsers)
* they are not flexible enough – there’s no way to use other proxies like the highly useful header rewriter proxies to allow for, say, asking for nationalized versions of pages (more on this later)
* sometimes introduce a definite delay because the (sometimes overburdened) middle-tier server has to process the source pages themselves. With Opera Mini, the delay, typically, ranges from 2 to 30 seconds – that is, sometimes it’s on the verge of acceptability.
* Some incompatibility issues with some sites; for example, the current Opera Mini 4.1 is not compatible with the “Quote” button in vBulletin version 3.6.8 currently used at, say, forum.xda-developers.com.
Some of the pros (much less data overhead) have already been mentioned; on top of that, what you gain is also anonymity. That is, your real IP is hidden – the Web page you access sees Opera’s middle-tier server as the client, not your own IP. Note that your IP is told to the Web server but in an extended HTTP request header, which few of these servers log.
Now, let’s turn our attention to IEM, that is, the browser coming with built into the Windows Mobile operating system. As has already been explained, it has pretty weak and, with standard Ajax, plain non-existing Ajax/JavaScript support. Its CSS support is equally bad. It doesn’t support the multidocument model (which was introduced in IE7 on the desktop) support without 3rd party so-called “plug-ins”. It’s also pretty much limited in that it has no link target / current page saving capabilities (which are pretty much essential).

The same used to apply to image saving in operating system versions prior to WM5. Also, it has severe restrictions like absolutely no IFrame support in pre-WM6 versions and only supports displaying 12 (in WM6) and 10 (in pre-WM6) frames. In this regard (too) alternative, commercial browsers fare far better.
Its stability used to be pretty bad in pre-WM5 times too: it frequently crashed because of certain CSS constructs. I’ve found and published several such CSS constructs back then. This is, fortunately, no longer the case in WM5+.
The two screenshots show how the mobile version of the PPCMag blog and the desktop version of YLE’s (Finnish Broadcasting Company) main page is displayed on a high-resolution VGA device.
Historically, on high-res Windows Mobile models, IEM had the “pixel doubling” problem, meaning images were still rendered as low-res, with double their size. This was fixed in WM5 AKU 3.5 (in early 2007), which lets the users switch between “High-resolution” and the default standard mode. This, however, didn’t really help external applications making use of the IEM rendering engine to display HTML-formatted contents like CHM readers – they still render images with pixel doubling (and, unfortunately, charts too) on high-resolution devices.
Incidentally, when used as a plug-in, there is another source of problem. If you don’t close HTML tags right after the (last) word like in <i>foo </i>bar (as opposed to <i>foo</i> bar), then, the two (formatted and the next) words will be rendered without a space in between them. In the two screenshots presented in the article (a low-res QVGA and a high-res VGA one), I show the results of this “bad-formatted” construct. Note that in the expression “fox jumps over a lazy dog”, ‘fox jumps’ is rendered as one word only because its HTML source was like this: “<b>fox </b>jumps over a lazy dog” and not the recommended “<b>fox</b> jumps over a lazy dog”.
Let’s turn our attention to NetFront, a well-known commercial browser for Windows Mobile. While it’s a bit expensive ($30), it offers an excellent browsing experience – except for some (rather major) problems and bugs. For example, it has built-in Flash support, which is, unfortunately, weaker than that of Adobe / Macromedia used by both IEM and Opera Mobile (it has compatibility issues and severe CPU usage problems). It supports SVG (which is very commonly used in Japan’s 3G content networks) and also has a Java VM to run applets. The latter, unfortunately, is definitely weaker than that of CrEme, the best JVM available for Windows Mobile and, in cases (where there isn’t much animation / graphics involved), even the Java support of the traditional, non-MIDlet-based Thunderhawk. It supports multitabs but their number is, unfortunately, maximized (to five) – as opposed to IEM plug-ins, Minimo or the Operas. I just can’t understand the rationale for this restriction; after all, on a modern 128 Mbyte RAM device, dozens of Web pages can be stored in RAM for quick access / swith. It also has minimap support and, which is very important for many iPhone fans, iPhone-like acceleration when dragging the screen contents by a finger / the stylus.
It has, as of version 3.4 and 3.5 (not NOT previous versions!), has pretty good Ajax/ JavaScript/ CSS support and its rendering engine is definitely better than that of IEM.
The recent releases are as follows: 3.3 (Summer 2006; inferior); 3.4 (Fall 2007): OEM only; currently: 3.5 Technical Previews. This, unfortunately, means you can only get the outdated and (compared to later 3.4 and current 3.5 versions) pretty much incapable 3.3 if you plan to go for this browser. Unfortunately, the currently available 3.5 Technical Previews versions are pretty much limited: no more favorites than 10; no Java / Flash support; no more tabs than 2. In this regard, Opera Mobile and most IEM plug-ins with their 30-day unlimited trial is much better. I hope the NetFront developers consider this and unlock all the features of future Technical Previews, only leaving a timebomb in rendering the browser useless after a certain date. (Noone will set their clocks back – and suffer from the consequences – just to be able to run NetFront to save $30.)
Now, let’s take a deeper look at Minimo, the free and, unfortunately, discontinued (cancelled), unofficial Firefox port. Note that the already-announced official Firefox will be later released for Windows Mobile; currently, no release date is known.
It comes in two versions: 0.16 (for pre-WM5 devices) and 0.20 (for WM5+ only). It’s plain useless on some models because of speed problems and other bugs. On the ones that it doesn’t have model-specific problems, however, is a semi-decent alternative if you really want a free browser other than Opera Mini.
Being based on the Firefox engine, it has excellent scripting (including Ajax) and CSS support. Not as good as Opera Mobile 9.xx, though.
Now comes without doubt (as of version 9.xx) the best, fastest and most powerful standalone Web browser, Opera Mobile. It has excellent JS / Ajax support, almost 100% compatibility with all Web standards, particularly with version 9.33; it’s very fast at everything (loading pages, downloading files etc.), supports the standard Adobe / Macromedia Flash plug-in (unlike NetFront, which forces the user to rely on the built-in and definitely inferior Flash engine) and lets for opening any number of tabs, as opposed to NetFront or IEM without a plug-in. It (as of version 9.xx – but, unfortunately, not the currently commercially available 8.65) also has some other goodies like finding text in pages, which is not available in any IEM-based solutions, not even commercial ones.
Currently, it’s available in two versions: the official (8.65) and the preview (9.33 / 9.5), for both PPC’s and Smartphones. The latter, 9.xx-series has without doubt the best standards compliance of all browsers for Windows Mobile.

Opera Mini, as of version 4.1, has become a really-really decent alternative to other Web browsers, particularly if you need a free solution. As it’s a MIDlet, it’s compatible with almost every phone out there – even feature phones. This means you get exactly the same menus, the same shortcuts on, say, your wife’s low-end feature phone and your smartphone.
It requires a separate environment, a MIDlet manager, to run. I’ve elaborated on the different MIDlet managers available for Windows Mobile in the MIDlet Bible, which you definitely should read if you want to get introduced to the wonderful world of MIDlets. (Note that you won’t necessarily need to read it if your only aim is to be able to install and use Opera Mini 4.1; then, all you’ll need to do is reading my 4.1 deployment and usage tutorial.)
As of the current (4.1beta) version, it offers even file upload, address autocompletion and page saving capabilities. Full page view is also supported (which has been added in version 4.0), retaining the full layout of the original page - as opposed to the one-column view. Incidentally, it’s this that you can see in the above screenshot too.
Its only problem is the lack of arbitrary text copying from Web pages. This could easily be fixed as is done in Russian Opera Mod (an unofficial and, unfortunately, illegal modification of the original Opera Mini) – feeding the textual page contents to a text input area, where it can already be copied to the clipboard if the particular MIDlet manager allows for this (all of them do on all the three reviewed mobile platforms; the only exception is the discontinued and outdated TAO Intent MIDlet manager on Windows Mobile).
As it’s a proxy-based solution, it has far less data usage; however, it can’t access local files (files in the file system) and the additional processing can take some time (typically, between 5 and 30 secs).
Thanks to extensive hacking, direct invocation has also been implemented (originally by me), which greatly enhances its usability on Windows Mobile because it lets for being directly invoked when you click a link in an e-mail or Office document. This isn’t as important on Symbian and BlackBerry because it’s far easier to copy / paste e-mail links in these operating systems (when you step over a link, it’ll be highlighted at once; then, you can copy it to the clipboard at once [as opposed to the, in this regard, much slower and more awkward Windows Mobile]; pasting to Opera Mini’s address input field is equally easy and quick), should you want to avoid using their built-in, respective browsers (for example in order to keep data usage down.)
Finally, still on the subject of Symbian and BlackBerry: while all public builds of version 4.0 frequently (about once a day) crashed on these platforms, I haven’t ever encountered any crashes with 4.1. That is, you won’t ever need to remove and reinsert the battery in order to reset your handsets.
Thuderhawk has a long history on Pocket PC’s. (It also had a MS Smartphone-compliant version, but only for low-res, 176*220 screens, and a QVGA version has never been released for this platform.) Unfortunately, it also seems it’s no longer worked upon as the developer has entirely switched to a MIDlet-based solution to directly compete with Opera Mini. (Which is more than hard as Opera Mini is really-really good.)
Thuderhawk’s biggest advantage has always been it being based on its own fontset (BitStream is also a font designer company), which makes original-layout, full page rendering possible even on 320-wide (QVGA) screens by using special, narrow, but perfectly readable fonts not otherwise available under Windows Mobile. Note that IEM can use similar fonts to look pretty much the same condensed as is explained HERE; the lower right screenshot shows exactly this, while the upper one shows a typical forum page rendered on a 320-wide screen without any need to do any horizontal scrolling.
Unfortunately, being based on a custom fontset means Thunderhawk only supports Western characters; meaning no support for most Eastern European or oriental languages. With Eastern-European, non-cyrillic languages like Polish, Romanian, Hungarian, Czech, Slovakian, Slovenian etc. that use alphabets pretty close to Western languages, this can be somewhat fixed by converting their special, Unicode-only characters to 8859-1 on the server side; with fully Unicode languages, on the other hand, this can’t be done.
Thunderhawk has no support for hi-res ((W)VGA) screens (it displays contents at QVGA effective resolution); doesn’t let for any kind of page / link target saving at all and doesn’t even support copying to the clipboard from Web pages. It doesn‘t use client-side web page / image caching at all (meaning, at times, it may result in far bigger data usage than most of the alternatives); it is only able to download files to built-in storage (not to storage cards or other, alternative media); it has absolutely no support for file upload etc.
Microsoft Deepfish should also be mentioned, which was more of a pilot project slightly more than a year ago to see how server-side content rendering with plain image-based client-server communication works. It wasn’t anything to write home about: because of the client’s being based on the (comparatively) slow Compact Framework and the middle tier server’s being overloaded, it was pretty slow in real use. It’s been discontinued in the meantime. It’s still not known whether it’ll be reused in future Microsoft browsers – for example, in the IE6 port slated for later this year.
Now, let’s take a look at the IEM plug-ins, which greatly extend the functionality (but, alas, not the Web standard compliance / conformance) of IEM.
These plug-ins greatly extend IEM’s capabilities: they add multitab (multiple document) support, resource (page / link target / image) saving, User-Agent GUI-based setting; they let for using hardware buttons for much easier navigation / function access, address bar macros, altering the way the document is scrolled by D-pad etc.; some of them even have GPS-based, location-dependent services.)
* PIEPlus is probably the best and most featureful (resource saving, support for hardware button reassignment etc.). For pre-WM2003SE users (“One Column” was only introduced in WM2003SE), it has a unique feature not offered by other PIE plug-ins: the Pocket View one-column view
* MultiIE is also a decent IEM plug-in; albeit, it’s in no way better than PIEPlus any more (unlike in the past). Basically, it has a similar feature set as PIEPlus.

ftxPBrowser: this PIE plug-in (or, more precisely, a shell), in pre-WM5 times, used to be highly recommended. As it’s mostly incompatible with WM5+, it’s not recommended any more.
Webby, another shell (not a real plug-in), is .NET Compact Framework-based and is, therefore, a bit on the slow side. However, it’s become better and better over time and offers for example extensions like Mozilla for for example ad filtering. It doesn’t let for accessing some of the features of the underlying IEM; for example, it has no One Column mode.
The brand-new Touch Browser, which tries to mimic Safari on iPhone, is pretty similar to Webby in that it’s another CF-based shell. The initial versions were pretty bad; hopefully, future versions will, hopefully, improve on the situation.
Finally, Spb Pocket Plus 4 should be mentioned (see screenshot on the same slide, showing its tabs). While before version 4 it was definitely worse (it didn’t even offer on-screen, easily clickable tabs) than PIEPlus or MultiIE (the two major alternatives), this is no longer the case: version 4.0 has fixed this, along with other goodies like accelerated screen dragging just like on the iPhone.
Now that we’ve seen the major browsers (and plug-ins) for the three operating systems, let’s quickly elaborate on what problems running them under Windows Mobile may result in.
The most important of them, particularly under pre-WM5 operating systems (particularly under WM2003SE), is the driver memory usage, which rendered NetFront and Opera Mobile unable to start under certain circumstances – unless you reset the entire handheld.
Let’s go on with discussing the different client-side techniques helping in reformatting (“reflowing”) a page to (horizontally) fit in a low-resolution screen. If we don’t do this, the low (horizontal) screen resolution (240 by default - 320 when used in Landscape -; some low-end MS Smartphones and pre-v3 Symbian S60 Smartphones had even worse-resolution (176*208 / 220) screens) results in having to scroll horizontally. This is why there are several “One column” client-side implementations. (There’re also middle-tier implementations like Skweezer; more on them later). On Windows Mobile, these special modes are supported by all browsers except Thunderhawk. On Symbian S60’s Nokia Web, in most cases, they are unnecessary as the browser is smart enough to be able to correctly re-flow text – as is the case in Opera Mini in non-one column mode. These two browsers are truly excellent in intelligently reflowing text.
In IEM, there’re (with WM2003SE+ devices) three rendering modes: the truly one-column “One column”, the “Fit to screen” (later renamed to “Default”), in addition to “Desktop view”. The three screenshots on this slide show an example BrightHand forum page in the Desktop / Fit to Screen (Default) / One Column order (from left to right).
Note that One column isn’t necessarily better than Fit to screen. There are cases when the latter delivers better results than the One column mode; for example, when you render simple charts (tables) not wider than 3-4 columns (or 6-8 columns in High-Resolution mode, if your handheld is a high-resolution one). Then, One column will display all the cells vertically, making the original layout completely messed up, while the Fit to screen mode will try to render them horizontally. However, in general, Fit to screen delivers results not needing horizontal scrolling in much fewer cases than Nokia Web or Opera Mini 4+ in non-mobile view mode, particularly on low-resolution (for example, QVGA) screens.
As, as has already been pointed out, pre-WM2003SE PIE’s, where there’s no One Column and the only “Fit to Screen” (Default) mode can’t correctly render the contents of the page without horizontal scrolling, you’ll need to use one of the following alternatives:
External Web compression / reformatting / one-columnizing services (Skweezer, Google Mobile etc.). They, unfortunately, get rid most of JavaScript code, making a lot of JavaScript-based functionality like changing pages in some forum engines inaccessible.
PIEPlus because of the explicit Pocket View mode, which fixes this problem
Use an alternate browser like Opera Mobile (WM2003) or Thunderhawk (compatible with even PPC2k / 2k2), which handle these cases much better
Wait for Touch Browser’s (which does have a built-in One Column mode) becoming much better

With Opera Mobile, the three rendering modes are almost the same as under IEM. It should, however, be pointed out that the One Column mode is buggy: the horizontal size is 240 pixels; that is, it’s only really usable on QVGA devices used in Portrait – preferably not in Landscape and definitely not on a (W)VGA hi-res model.
It, as has already been stated, generally fares much better in rendering blocks of texts without any need for horizontal scrolling. Just compare the first (leftmost) screenshot to the Desktop rendering screenshot of IEM: as can clearly be seen, this particular page was correctly (no need for horizontal scrolling) rendered by Opera Mobile in Desktop mode, unlike with IEM. (Of course, most of the time, you won’t want to use the Desktop mode, unless you need to see images in their original size, without being resized to fit the screen.)
The three screenshots, from left to right, show exactly the same three modes, in the same order, as with IEM: Desktop, Fit to screen and, finally, One Column. As the screenshots have been taken on a VGA device, the latter is buggy and only uses the left half of the screen.
Note that the One Column mode is clearly better implemented in Opera Mobile than in IEM (apart from the 240-pixel bug): it renders charts much better than IEM in One Column mode. See the example screenshots and discussion at the end of section 1.2 Opera Mobile of the MS Smartphone Web Browsing Bible.
NetFront has three similar modes: Normal, Just-Fit (about the same as “Fit to Screen” / “Default” in IEM and Opera Mobile) and, finally, Smart-Fit. The latter mode is without doubt the best: it’s like One Column, but still tries to render contents horizontally where applicable, unlike IEM and like Opera Mobile.
The three example screenshots (from left to right), as with IEM and Opera Mobile, have been taken using Normal, Just-Fit and Smart-Fit.
Minimo only has two modes: the default (desktop) mode and SSR (Small Screen Rendering), which is almost the same as One Column mode in the other browsers. The two screenshots show this (left: default, right: SSR).
Finally, in the Thunderhawk screenshot, you can see how well it manages to display even the most delicate screen contents without the need for horizontal scrolling. Note that it forces the user to use the horizontal orientation, which may be overly problematic on models with screen polarization issues in this orientation (as opposed to Portrait mode). However, users of devices with pre-WM2003SE operating systems (and a device without polarization problems) will surely welcome Thunderhawk’s using Landscape mode – none of the alternate browsers do so, not even the ones that, otherwise, could (as with some e-book readers like Mobipocket), not being based on IEM. (It was in WM2003SE that user-switchable Portrait / Landscape rotation has been added.)

Now that we’ve reviewed the browsers’ approach to rendering pages / textual page content originally designed for at least 800-wide screens on 176…640-wide screens, let’s turn our attention to other questions like (easily) controlling the browsers – for example, scrolling pages using hardware buttons.
There are several ways you can easily scroll a Web page up and down without using the touchscreen. The most common way of doing this is using the D-pad.
1. If you stick to using the D-pad, under IEM, by default, you’ll end up using link scrolling (as opposed to page scrolling). This can be a pain in the back, particularly on pages that have several links on them (you end up having to press Down several times to be able to scroll to new contents); fortunately, it can be altered on the Registry level (with a Registry hack). Most IEM plug-ins (PIEPlus, MultiIE at least) allow for doing this on the GUI level, making Registry hacks unnecessary.
Some browsers / plug-ins even allow for supplying the one-page-at-a-time scroll amount in percents. The screenshot in the slide shows exactly this with NetFront, where you can easily set this.
2. If you (also) utilize other buttons for at least page scrolling down, you can still use the D-pad for link scrolling (assuming you prefer one-handed use and don’t want to touch the screen to follow a link) by assigning the Page Down operation to any hardware button. This has thoroughly been explained in the Button Enhancer Bible.
3. Also, if you have a volume slider on your handset, you can use the jog dial / volume controller with the excellent SmartSKey utility; most of the browsers support this.
4. Under Settings / Buttons, you can also directly assign the “Page Up” and “Page Down” functionality to any hardware button (or, for that matter, even special buttons, jog dials and volume sliders with advanced, third-party button enhancer utilities like AE Button Plus.)
Note that, as far as Symbian is concerned, it Nokia S60 Web makes navigation pretty easy with its minimap accessed by pressing and holding the up/down button. So does the built-in Web browser with the latest, 4.5/4.6 version of BlackBerry. Finally, don’t forget that Opera Mini and Opera Mobile support page scrolling using the numeric buttons on phones that do have these – then, you can still use the D-pad to scroll link by link (or, if you use Mobile View [that is, One Column mode] with Opera Mini, left/right to scroll pages).
While certainly not as widely used as Flash content (any more), Java applet support is still nice to have – some (mostly internal and/or enterprise front-end) pages (still) use Java applets. For Windows Mobile, there are several solutions - Java Virtual Machines (JVM's). BB and Symbian have absolutely no applet support.
IEM depends on JVM plug-ins (as is the case with Flash plug-ins). Only two JVM’s have applet support (JVM’s with no Applet support are IBM J9 (it’s MIDlet / Personal Java only) and Mysaifu (it’s application-only)):
* Insignia Jeode; last version dates back to 2003 (came with the iPAQ 5550 – and previous iPAQ models. Most of these are locked to either the iPAQ brand or the given model). Today, as Insignia / Esmertec has stopped developing it (because they have moved to producing MIDlet managers), it can in no way be acquired legally
* CrEme: this is without doubt the best JVM to run applets. Unfortunately, it’s not meant for non-OEM customers, albeit they do have a downloadable 30-day trial on their homepage
Unfortunately, unlike with the Flash (Lite) plug-ins, Opera Mobile can’t make use of these plug-ins.
As far as the other browsers are concerned, the following two browsers have a built-in JVM:
* NetFront 3.1+: acceptable quality / compatibility (unfortunately, worse than Jeode / CrEme – as is the case with Access’ own Flash support in NetFront)
* Thunderhawk: in order to avoid producing a huge install (even older, non-fully-fledged Java runtime libraries easily add 1-2 Mbytes to the static size of the program [let alone newer JDK’s like 1.5+], which is pretty low – around 700 kbytes – with TH) and still provide full (!) JDK 1.5+ compatibility, the BitStream folks have gone for a strictly client-server solution, the server-side actively interpreting and executing the applet and just sending its GUI as a static image to the client. It, while it indeed offers full JDK1.5+ compatibility, has some cons compared to all the other solutions using local code execution: the images are low-res, slow-to-refresh and can cause excess data usage as the image of their GUI needs to be downloaded to the client every, say, second.
There’s absolutely no applet support in Opera Mini/Mobile or Minimo. In addition, currently, the WebKit-based browsers (Iris etc.) don’t support applets either - as with the Flash plug-in. Hope at least this changes in the future.
There’re some additional Web technologies that have become pretty standardized. You may have noticed Internet Explorer, Firefox or Opera don’t contain any kind of a Flash plug-in on the desktop Windows. The situation is exactly the same on mobile operating systems: few browsers or operating systems come with Flash support built-in (the two most important exception being NetFront on Windows Mobile and Symbian S60’s Nokia S60 Web with Flash Lite 2 / 3).
Flash being by far the most important additional technology requiring a plug-in (with most browsers), let’s take a deeper look at the Flash support on all these mobile operating systems. Let’s start with Windows Mobile.
IEM (all versions starting with PPC2k2) and Opera Mobile (as of version 8.65+) both have a somewhat restricted Flash 7 plug-in (and Flash Lite 2, in addition). It’s quite outdated and, of course, doesn’t support the latest technologies. It isn’t particularly efficient either; for example, its YouTube / other Flash video playback performance is plain sub-par.
NetFront has a built-in Flash engine, which is even inferior to the Flash 7 plug-in: it’s buggy, (even) less compliant and has major CPU usage bugs.
There’s absolutely no Flash support in Minimo, Opera Mini and Thunderhawk.
As far as BlackBerry, Symbian and the iPhone are concerned, they have absolutely no full Flash support. Symbian, however, supports Flash Lite 3 (depending on the model and the firmware used) – unlike Windows Mobile. Flash Lite will be discussed in the next slide(s).
(The screenshot shows the full Flash-based Bomberman, one of my favorite real-world Flash tester games, running in IEM.)
Flash Lite 3, which has recently been released for some past and recent Symbian S60 3rd edition models as firmware upgrades, has excellent support for YouTube and other, Flash-based Web video repositories. It’s, unfortunately, not available for Windows Mobile / BlackBerry / iPhone (as yet). For WM, it’s coming; for the other two mobile operating system, nothing is certain.
The two screenshots show Nokia S60 Web on the v21 firmware-based N95 playing back YouTube videos; the bottom left in Landscape (the video shrinked to the QVGA screen size); the one on the right on the original size in Portrait (hence the vastly oversized video). I haven’t provided similar screenshots on Windows Mobile because the Flash 7 plug-in on WM is very slow & inefficient and it’s almost impossible to use it to play back any Flash videos. Fortunately, a lot of alternative methods for playing back YouTube exist for all these operating systems; this is the subject of the several following slides.

As many users spend a lot of time watching YouTube (and other) Web videos, it’s definitely worth elaborating on the alternative technologies of playing them back.
First, let’s elaborate a bit on the two major formats YouTube content is delivered: the high-quality H.264 & FLV (with accordingly high data usage) returned by the firewall-friendly HTTP protocol, and the low-quality, low-(QQCIF) resolution 3GP (returned via the firewall-unfriendly RTSP protocol). We, of course, will mostly be interested in the high-quality version – unless we really need to decrease data usage and/or use a low-resolution mobile device like a MS Smartphone with a 176*220 screen.
The desktop YouTube Web interface isn’t the best for mobile usage (slow, huge – over 300 kbytes – pages; only Symbian + Flash Lite 3 is able to play back inline videos). There is a mobile version created and supported by YouTube, which
* Already supports all the functionalities of the desktop (account, upload etc)
* Is compatible with most mobile platforms having an RTSP / 3GP player like RealOne – no additional player needs to be installed
* Already has all the videos, unlike a year ago when it became public
However, it’s lower-quality 3GP only (no FLV / H.264) and requires RTSP. That is, it can be vastly inferior in most cases and, therefore, should be avoided.
The screenshot shows the results of a search using the native mobile YouTube interface (which, again, should be avoided, unless you absolutely don’t need the vastly enhanced video and audio quality of the FLV / H.264 videos).
Let’s continue with alternate YouTube technologies – ones that don’t depend on the Flash plug-in (because of the slow and flaky Flash plug-in on Windows Mobile) or are usable on other platforms like the BlackBerry. Fortunately, there are several of them; one of the most important is vTap.
vTap has native clients for all mobile platforms. From the Windows Mobile one (see the upper right screenshot), you can even initiate video playback (this client is highly recommended and useful because it’s capable of searching on not only YouTube but also other video sites), while you can’t do the same from the BlackBerry one.
This also means you’ll need to turn to other solutions to stream YouTube videos to your BlackBerry handheld; an example of these solutions is vTap’s Web interface (not the standalone client) depicted in the three screenshots at the bottom, showing searching for clips, opening them as a stream and, finally, the media player rendering it. (Note that the rendered contents is invisible in the screenshot on the bottom right. This isn’t a bug.)
Finally, one of the several alternative YouTube playback solutions is YTPocket, which depends on the external TCPMP FLV playback support (under Windows Mobile). The two screenshots show the results of a search and, then, initiating a download (and the consequent invocation of TCPMP for viewing).
Let’s move on to another, completely different, but, for users of non-unlimited data plans, very important question: reducing data usage. This, incidentally, can prove very helpful for users over unlimited, but very slow (for example, GPRS, like Vodafone’s non-3G dial-up) connections.
There are several ways of optimizations and major data usage saving; this slide discusses the way you can drastically lower the data usage by employing server-side (gzip) encoding, which is supported by all mobile browsers (for example, on WM, starting with the PPC2k PIE; that is, it has had support for eigth years).
As a rule of thumb, if you can, you should check the Accept-Encoding header (telling you whether the client is able to process gzip-compressed responses) along with the User-Agent HTTP header to find out whether it’s a mobile client (should you only want to return GZIP’ed contents for mobile users if you find GZIP compression is using too much CPU on your Web server). If you go this way, keep in mind that several mobile users “spoof” their User-Agent headers so that servers never return mobile-specific contents to them. With some of these clients (most importantly, IEM), you’ll want to look for specific extended (X-) HTTP headers to be able to make a distinction between desktop and mobile clients - that is, correctly identify mobile ones.
Note that several content manager and forum engines (e.g., vBulletin) support GZIP’ing “out of the box” if it identifies the client as a mobile device.

Unfortunately, if you are just a user and can’t ask a webmaster to return compressed (GZIP’ed) contents upon receiving requests from mobile clients but still want to (vastly) decrease your data usage, you’ll need to do some client-side work. There are two main categories of doing this.
The first group, largely consisting of the free Toonel and the commercial (between 30…50 US$ - cheaper for recurring customers) OnSpeed, runs a “proxy” on your Java-capable and/or Windows Mobile-based mobile device and configures (or, forces you to manually configure) your browser to access the Web through it. The proxy takes care of compression by being connected to another, invisible server. The advantage of this solution, compared to the next, is mainly that you 1. don’t need to pay attention to visiting a mediator Web page to do the conversion for you and 2. you will always receive full Web pages, not dumbed-down ones without, for example, scripting.
The second group consists of Web services like Skweezer, MobileLeap, Google Mobile etc. They are easier to initially set up than the apps in the first group (absolutely no need to install third-party apps on your mobile); however, they’re a bit harder to use and, as has already been pointed out, they can royally mess up Web pages. Most IEM plug-ins like MultiIE, PIEPlus and Webby automatically support the online services; the first two (Toonel / OnSpeed) can be used with all Windows Mobile Web browsers allowing for proxy usage (that is, everything except Opera Mini and TH – not a problem though as they’re content-stripped / compressed already).
Let’s turn to an entirely different subject: compliance with different (important) Web standards. Let’s start with AJAX, which is getting more and more ubiquitous. Opera Mobile and Minimo have the best support for it; the two screenshots show these (OM on the left, Minimo on the right) rendering the entirely AJAX-based Google Image.
Unfortunately, IEM is (still) pretty weak when it comes to AJAX support, even as of WM 6.1. So is NetFront as of the currently commercially available 3.3; fortunately, 3.4+ is already much better. (But, again, currently, there’re only restricted Technical Previews of 3.5 you may not want to use because of the restrictions). Thunderhawk and Opera Mini both have rather poor support.
JavaScript support is pretty similar to this. The bad JS support of IEM results in, for example, Yahoo Mail buttons’ not working – a major problem with many users. The same stands for for example address autocompletion in Google Mail; currently, only Opera Mobile and Minimo support it (they have the best JavaScript compliance).
Still on the subject of Web standards compliance, let’s take a look at the compatibility with CSS. In this area, Opera Mobile is without doubt the best as of version 9.xx. Version 8.65 (the one officially and commercially available; screenshot on the left) is a bit worse in this respect. Minimo is the second (screenshot on the right). The slide also shows how the desktop (9.x-series) Opera renders the test page (the only desktop browser to render it without any glitches – see the referenced article for more screenshots of other desktop browsers if interested).
Let’s go on with evaluating the CSS2 (Acid 2) test results. This slide shows how NetFront 3.3 and IEM render the test. As can clearly be seen, they (particularly IEM) have nothing to write home about.

Still on the subject of Web standards compliance, let’s see the results of W3C’s brand new “Web Compatibility Test for Mobile Browsers” suite. First, let’s see how the Windows Mobile-based Web browsers render this suite.
This slide shows IEM in WM6.1 (left), the 5-year-old WM2003 (middle) and 7-year-old PPC2002 (right). As can clearly be seen, the Web standards compliance of IEM is only a tad better than that of its very old PPC2002 ancestor.
Let’s continue with the same W3C test suite, looking at the Opera Mobile and Mini results. The left screenshot shows Opera Mobile 9.33, which delivers almost flawless results (showing it’s indeed based on the new, 9.x-series kernel), as opposed to version 8.65 (2nd shot). Opera Mini 4.1 (on the right) delivers acceptable results – still much better than, say, IEM (see previous slide).
Let’s take a look at the third (and last) Windows Mobile W3C test slide showing the current Techincal Preview of NetFront 3.5 (left); the WebKit-based Iris browser (middle) and Minimo 0.20 (right). As can clearly be seen, none of them really excel – Opera Mobile 9.x is just far better than any of them.
Now, having finished with Windows Mobile, take a look at other mobile platforms. In the lower row, you can see the WebKit-based Symbian Nokia S60 Web (left), iPhone’s Safari (middle). The built-in browser coming with BlackBerry 4.2 (right) follows; the latest (still beta), 4.5 BlackBerry version (topmost) shows the new BB operating system indeed delivers a bit better results than the previous one – but still much-much inferior to even Opera Mini (which, incidentally, runs flawlessly on the BlackBerry).

Finally, in order to give you a complete picture of what you can expect of desktop browsers, an overview of their rendering the same test. (On the bottom: Firefox 3 beta5 (left); Internet Explorer 8 beta (middle); IE7 (right); on the top: Opera 9.5.). As can clearly be seen, Opera is by far the best and even the latest version of IE8 is far-far inferior than even the latest 3-series Firefox.
Now, let’s discuss the techniques needed to avoid certain HTML / page layout constructs that simply can’t be rendered by (some) mobile Web browsers. The most important stumbling block is that of frames: both IFrames and standard ones. First, let’s take a look at the latter.
With IEM (as opposed to most other major browsers) the number of (standard, not i-) frames is restricted (10/12 at most for pre-WM6/WM6+, respectively). One of the most widely known example of the affected pages is freemail.hu. The pictures show IEM (on the left) was simply unable to display the page in its entirety, unlike Opera Mobile (right), which has no frame limitations. Make sure you avoid an excess number of frames if you want to make your portal accessible to even IEM clients and you don’t have a specific mobile version!
Now, let’s take a look at Inline Frames (IFrame). They are in no way supported by pre-WM6 IEM and Thunderhawk. The former is shown in the screenshot on the left, showing the pre-WM6 IEM’s inability to render the contents of the test page. NetFront and Opera Mobile, on the other hand, have no problems rendering this area (neither has Opera Mini).
The lack of IFrame support also means no Gmail / Yahoo Mail dynamic address completion (which works in Opera Mobile and Minimo) is possible because they’re entirely based on IFrames.
This slide shows IEM coming with WM6 has indeed added support for Iframes and has raised the number of standard displayable frames to 12.

This slide explains some common cookie handling-related problems with NetFront and Thunderhawk. The text speaks for itself; no need to explain it further (rather than following the links to my original, lengthy articles and elaboration).
The next few pages elaborate on the language & encoding problems and internationalization (on Windows Mobile), which will be pretty important for you if you display / host / try to access pages not (only) using non-Western languages – or, for that matter, even special punctuation like “.
First, NetFront handles the HTTP character encoding header (Content-Type) vs. meta tag entirely differently from the other browsers. It is, unfortunately, buggy when 8859-1 is used along with special 8859-1 punctuation – for example, if you write your posts in Word and don’t disable its automatic character substitution enabled (and active) by default.
Opera Mobile is pretty problematic at POSTing (NOT displaying /rendering!! Only when user interaction / form-based posting takes place) some contents; for example, special 8859-1 punctuation and everything different from 8859-1.
To easily fix these problems, if you’re a webmaster and know your pages do contain some special punctuation coming from, say, Word and want it to be rendered by NetFront or editable and (re)POSTable by Opera Mobile correctly, do convert dynamically (in the runtime) all these characters to their 8859-1, “plain” equivalents.
If an Opera Mobile client edits a non-8859-1 document (like an article or a forum post), convert all special Unicode characters (like ő and ű) to HTML char entity codes (ő and ű with ő and ű, respectively). These entity codes are correctly POSTed back by the browser.
As has already been mentioned, Thunderhawk uses its own, Western-only character set. It contains absolutely no other characters. Even when the operating system does support the given character set (and is able to render all the characters well), Thunderhawk won’t and just display a hyphen as a placeholder upon encountering them (the text in the screenshot shows some of these). Therefore, in order to correctly display non-Western, but easily 8859-1-mappable languages (typically, Eastern-European languages not using Cyrillic characters belong to this category), as a webmaster, you may want to check for ThunderHawk User-Agents and substitute the characters accordingly when encountering a TH client.
Some Web pages (and Web frameworks / content handlers) allow for easy internationalization – that is, dynamically returning a different-language page upon encountering a special HTTP request header. This slide elaborates on this and lists the two browsers (PIE and Minimo) that do let for setting this particular header. Unfortunately, the other browsers need an external HTTP request header rewriter proxy running anywhere (including your own PDA) to gain access to this functionality.
The two screenshots show IEM rendering b2evo’s login screen in English and Finnish (with automatical swithcing between them; no need for user interactions / language selection via links on the page), depending on the preferred language flag sent by the client.

Unfortunately, several mobile browsers don’t really shine at Web standards compliance either when it comes to downloading and saving binary files to the local file system on these handhelds.
The problems most users face:
* Content-Type: text/plain response problems with binary content: IEM & NF don’t try to decide whether the body is binary and blindly render it – as opposed to IE on desktop Windows. No such problems exist with other Windows Mobile browsers. That is, make sure Content-Type is correctly set on the server to allow for binary downloading to IEM & NF! Alternatively, if you are just a user and have no effect on the webmaster’s correctly setting this header, either use an IEM plug-in allowing for saving link targets, use a standalone HTTP downloader tool like Adisasta WinMobile Download Accelerator 2+ or HandyGet - or switch entirely to a different browser.
* NF and Opera Mobile send out download requests twice, while other browsers – including desktop ones – only do this once. This is why for example downloading from RapidShare doesn’t work in these browsers. If you’re a webmaster, the solution is simple: never reject double download requests. If you’re a mobile client only, switch to IEM – at least for the time of download.
* Referer-related problems: before WM5, PIE (and Thunderhawk even now) don’t pass the Referer header. Therefore, if you’re a webamin, don’t blindly trust the Referer header always being sent in order to deny out-site download requests. Just make a User-Agent test to check whether download requests not containing a Referer header originate from PIE and TH. If they do, you can safely let them download.
Note that you can greatly speed up your Web (and FTP) downloads by using multithreaded downloader clients (like FlashGet on desktop). Currently, two of them are worth mentioning:
* The just-released Adisasta WinMobile Download Accelerator 2.0 (do NOT use older versions because they’re slow!)
* HandyGet 1.6
The final slide discusses the opposite of the previous one: uploading files to Web. File upload is supported by all browsers (except for TH); IEM starting with WM5. As Opera Mini 4.1+ also supports it, you can even upload from the otherwise not very capable BlackBerry platform.
If you have a browser that isn’t upload-capable, then, switch to another browser that can. And, if you’re a webmaster hosting a page with file upload capabilities (like all forum engines, social network pages etc. allowing for attachment / image upload), you will need to ask your mobile clients to do the same. Alternatively, if you’re absolutely sure some of your clients won’t want to touch other browsers, you may also want to provide FTP upload support or, if you only look for text input, a HTML textarea to paste their text to.
The left screenshot shows PIE under WM2003SE. As can clearly be seen, there’s no “Browse” button (and file path field) in it – while the WM5+ screenshot (on the right) already displays (and lets for using) it, showing it (still) didn't have upload support.
That's all, folks - hope you liked this all And, yes, feel free to ask questions even here, even now.

I’ve just published my last roundup, sporting the latest Web browsers available:
Iris 1.0.16 (1.1.0 b3)
Opera Mobile 9.5b2 / b15233 (!)
Opera Mini 4.2.13337
SkyFire 0.85.0.8184
PIE, along with Spb Pocket Plus 4.0.2
Internet Explorer Mobile 6 (IEM6) (!)
NetFront 3.5.009 b729
… and compared all these to the Safari running on the iPhone with firmware v2.2.
The new roundup is available at http://forum.xda-developers.com/showthread.php?p=3130648

Web browsing news: Opera Mini 5b; no Iris browser any more; Fennec 1.0b3

1. The first beta of Opera Mini 5, with a completely redesigned interface on both touchscreen and non-touchscreen phones has been released.
It’s accessible at m.opera.com/next (which takes you to the official homepage when visited from a desktop browser) from your handset, should you prefer installing it on-the-fly. (This worked without problems on by BB 8800; in my WinMo tests, I used the JAR downloaded and transferred to the handset separately.) The dedicated threads are HERE, HERE and HERE).
I’ve thoroughly tested it on my VGA iPAQ 210 running the Jbed MIDlet manager and the BlackBerry 8800.
Pros
- Tabbed interface
- Support for saving passwords
- Built-in support for copying text from a web page. Note that, on Windows Mobile, you can only use text copied this way to copy into either the (non-native) address bar or in-page search bar (by pressing and holding the Action button) but not onto the system-level clipboard. Switching to using the native (system-level) text input field doesn’t help either (so that you can copy the text further – just like using my Opera Mini text copying service explained HERE). On the Blackberry (tested on the 8800), this doesn’t seem to be the case, where everything is copied to the system clipboard and made available to other apps like Notepad.
- Natively tabbed interface with explicit “Open in new tab” link context menu
Cons
- Still no support for Italic fonts. Again, Opera Mini folks, this would be really easy to implement – and, some of the alternative MIDlet-based Web browsers (see THIS for a full overview & really detailed comparison) already do this.
- Scrollbars have been removed, which makes it far harder to scroll down / up large amounts of text on a touchscreen phone without a hardware keypad (see #3)
- No automatic “History” any more – the tabbed interface substitute in earlier versions without having to explicitly bring up a link context menu and selecting “Open in new tab”. That is, the present solution is a bit more time-consuming for the seasoned Opera Mini user used to quickly switching between pages in the History tab, particularly on a phone with a hardware keypad (#5).
- No support for the native text input field (which would make it possible to copy from Web pages too) on BlackBerry (at least the 8800), unlike on Windows Mobile. There’s a “Disable inline text entry” setting under Advanced in Settings but it only seems to have effect on Windows Mobile.
- Major problems on the BlackBerry (at least the non-touchscreen-enabled 8800): I just couldn’t get rid of the “Find text in current page” text input field without removing the battery (simply initiating a power off with the hardware switch / the Power off menu item wasn’t sufficient)
- Doesn’t work on low-resolution, earlier or cheaper phones (176*220 Windows Mobile Standard / MS Smartphone phones or 176*208 older Nokia s60 phones, for example) with the native resolution less than QVGA (320*240). The reason for this is that it can’t render all its GUI components on screens this small. That is, if you’re a WinMo user sticking with a touchscreen-less, non-QVGA (that is, 176*220) MS Smartphone, don’t even bother – stick with Opera Mini 4. This wasn’t the case with the previous versions.
All in all, the new version shows a lot of promise but definitely has its share of problems on both Windows Mobile and BlackBerry. Fortunately, it nicely co-exists with earlier versions so you don’t have much to lose if you do give it a try.
2. The company, Torch Mobile, has been acquired by RIM – no Iris browsers for Windows Mobile any more
A lot of Windows Mobile folks love the Iris browser. (Not me, as I find its text reflowing capabilities far worse than those of Opera Mobile and Opera Mini, both running just great under Windows Mobile. I, most of the time, used the latter to browse the Web before switching to the iPhone.) A very bad piece of news for them is the complete termination of the Windows Mobile version.
Also see the user comments (including mine) HERE for more info.
3. Fennec 1.0b3 released
Fennec is the official Windows Mobile port of the renowned Firefox / Mozilla Web browser.
I’ve thoroughly tested it on my iPAQ 210 having 128 Mbytes of RAM (it’s stated it doesn’t work on 64M ones) and found it useless. Yes, it has a nice, tabbed interface and some goodies. Still, it seems it’s as bad as Minimo (the previous attempt at porting the browser to WinMo) was, even at version 0.2. For the time being, I don’t think you should bother.
Note that the MsMobile folks were pretty happy with the new version. Also see the user comments HERE - they are less than enthusiastic.

Thanks my friend!
As always very usefull information