Database Info

Opera 8.5 beta 2 is out!

Even the first beta version of Opera was a real relevation for the Pocket PC community. Much as it had several bugs (particularly on pre-Windows Mobile 5 devices), it has quickly become the browser of choice for many Pocket PC users (including me), at least on Windows Mobile 5.
The new version is, speed-wise, clearly the best browser I've ever seen for the Pocket PC. It's much-much faster than the alternatives. You'll certainly love it!
The good
* The WM2003(SE) version seems to be working great: I haven't encountered the infamous Opera-is-stalled bug under pre-WM5 operating system any more. I've tested the new version of Opera with all the test pages (the search facility at http://www.europe.com/en/ - screenshot here; RedHotPawn) that make the previous version stall at once. No problems encountered so far.
This may be related to the fact that now Opera senses some Web servers' not answering – see this and this message.
A iPAQ 2210 screenshot can be seen here and here (the latter taken at 25% zoom level so that the entire chessboard is visible) – as can be seen, as opposed to b1, I could log in and play on my iPAQ 2210 as well.
* It feels much faster than beta1, which is a feat in itself because beta 1 was already much faster than any alternative browser.
* There's tab support! (See the screenshots provided for examples.)
* The bug related to not being able to display loooooong pages is fixed. It worked great with all the pages I've thrown it at; an example screenshot of Tero Lehto's blog is here.
* Much as the new version is still using custom (non-native) GUI components, one of the biggest problems, that is, the text areas hiding the last characters in each row behind the scrollbar, is fixed as can be seen in here.
* The "You have XX days left of your trial period" dialog is no longer displayed at startup.
(There must be tons of other bugfixes, as far as previous beta1 bugs are concerned; these were the ones I've explicitly tested and compared to beta1.)
The bad
* After scrolling a page with any amount (or going to a new page), you will not be able to directly tap-and-hold a link to bring up the context menu (so that you can open the link in a new tab) without the need for at least partially highlight it (or the text that contains it). Fortunately, this is a minor annoyance and you'll quickly learn how to highlight (part) the link without clicking it.
* The new version is still using custom GUI components, which makes it impossible to use any kind of common Windows keyboard shortcuts. This is a mayor annoyance to anybody using an external keyboard to enter a lot of texts and wanting to use the traditional Windows shortcuts to quickly navigate through / highlight / copy/cut/paste text in the text input components.
* On some Pocket PC's (for example, the Pocket Loox 720) the new version still uses non-proportional Courier New fonts in the address bar / in the tab titles. This is a minor annoyance, though.
* Unfortunately, the settings dialogs (screenshot 1 and 2) are as simple as in beta1. The latter, however, now has a new checkbox, " Set Opera as default browser", which makes it unnecessary to manually import a registry file (please see the articles in the Recommended links section for the registry import file I've created for beta1 to revert the default browser assignments) in order to revert back to using Pocket Internet Explorer (if you make Opera the default Web browser on your Pocket PC).
Nevertheless, the lack of detailed settings dialogs are not a problem – with manually editing (or, downloading my sample configuration files) the main configuration files of Opera, you can fine-tune it (scrollbar visibility, proxy usage, scroll behaviour etc).
* Under WM2003, Menu/Display/Landscape still doesn't rotate the viewport. Again, this would be pretty easy to implement because Opera, unlike for example the Pocket Internet Explorer (PIE) plug-ins or almost all ( uBook and Mobipocket Reader being the most important exceptions) e-book readers, doesn't need to rely on the Portrait-only, underlying PIE engine. This is a minor problem though and "only" affecting WM2003 users – screen rotation works great in post-WM2003 operating systems.
* Still no advanced context menus (copy link, save image), no in-page searching etc. These are, however, only minor annoyances, which don't have a negative effect on the browsing experience itself.
* Still no " One Column" view mode like that of PIE starting with WM2003SE or the PIE plug-in PIEPlus (see this review on the latest version of latter, including a detailed comparison of the "one column" modes offered by PIE and PIEPlus). This would be very useful to maximize the usage of the available screen estate on many pages; for example, the XDA-Dev forums (example screenshot of Opera 8.5b2 rendering the latter here – as can be seen, the useful contents of the page only occupies about 65-70% of the available horizontal screen estate. With a real "One Column" mode, it'd be close to 100%).
* Still no support for system-level favourites. This would also be really easy to implement as there's nothing particular about the .url files in \Windows\Favorites – they're really-really easy to process. (I'd say a hour's work for an average C++ programmer.)
Verdict
I can only use superlatives when speaking of this application. Despite its (still) missing functionalities, its speed and compatibility is just phenomenal.
Recommended links
The following articles/tips all discuss/are all related to the previous, beta 1 version. Note that some of their contents is now that they are fixed are outdated. They may still be worth checking out - particularly the ones on manually editing the Opera configuration files. You'll find a lot of information in these articles never published by anyone else.
ESSENTIAL (NEW, UNIQUE BUGFIXES!!!) to know about the great Web browser, Opera beta! - I haven't run into the same problem with the new Opera version – yet. This doesn't necessarily mean it doesn't exist any more – therefore, if the address bar auto-completion crashes your Pocket PC with beta2 too, make sure you read this article.
Modify the default scrolling behaviour of Pocket PC Web browsers. Note that even the beta 2 of Opera uses jump-by-link by default (on all operating systems, not just WM5), as far as its D-pad navigation is concerned; you will most probably want to override this and switch to the 'scroll a page at a time' behaviour. Note that the new scroll a page feature (invokable via the Space key) only works on devices with a built-in keyboard; for example, on the HTC Wizard (screenshot of Opera running on my HTC Wizard here).
Opera 8.5 beta on WM5 - it is certainly different from the WM2003(SE) version and is working GREAT!
WM5 compliance report: the bandwidth reduction service OnSpeed works pretty good; additional Toonel information – this article will be useful for everyone that wants to configure his or her Opera to access the Web sites through a HTTP proxy.
Pocket PC version of Famous Web Browser, Opera 8.5 beta Officially Released!

Definitive guide to downloading files, images and saving Web pages with Web browsers

A lot has been changed after publishing my well-known Pocket PC Browser Bible (see the links in the final section) over a year ago. Windows Mobile 5 (WM5 for short) has hit the market with, on the engine level, vastly (and I really mean this!) improved Internet Explorer (ignore people that say the opposite - it's only at the GUI level that it hasn't changed much. The underlying engine is much better.) Minimo (which is a PDA port of the well-known, popular desktop browser Mozilla / Firefox) has been constantly improving and, now, it's really becoming a decent alternative to all the other Pocket PC browsers on many PDA models. So has Access' NetFront, the other alternate browser: there has been a major (3.3) release in the meantime. Last but not least, well-known multiplatform Web browser developer Opera AG has released no less than two Pocket PC-compliant browsers, Opera Mobile and Opera Mini, the former being, more or less, a Pocket PC browser based entirely on the desktop core, meaning superior compatibility with Web standards and the latter being a super-lightweight Web browser running even on a "dumb" Java mobile phone. It's only the developers (Bitstream) of Thunderhawk that haven't really done almost anything in the meantime (except for adding left-hand landscape support for HTC Wizard / Universal / TyTN etc. users).
This (and some additional bug reports & fixes I've promised for example for some AximSite forum members) made it necessary to completely rewrite the section on everything downloading- and resource saving-related.
This includes everything that results in a file saved to your PDA: saving the Web page you're browsing and would like to have a local (offline) copy of; an image in a page you'd also like to save to your PDA for further use or a file download (for example, an Over-The-Air (OTA) CAB installer file downloaded off a developer's homepage or a central CAB repository.)
Also, the article contains a lot of low-level compliance and bug reports. Very few people do know the HTTP protocol (the underlying protocol of the Web) inside out: the Windows Mobile community has the luck of having me as the resident expert on these questions. This means I also elaborate on HTTP compliance issues and also explain why some Web servers don't work with some current Pocket PC web browsers. This chapter will be a must particularly for the Opera, Microsoft, Bitstream and Access folks and everyone that would like to know why some web sites (for example, RapidShare) refuse to work with the browsers of these companies. This section also explains why you can't directly download .CAB files off certain Web sites when you use NetFront, Thunderhawk or Internet Explorer, unlike on your desktop. I provide a full list of the available solutions to these problems as well - that is, if you've ever had problems with CAB files not downloading in your Pocket PC Web browser, you'll find the solution in the third chapter.
Finally, I've made a LOT of new benchmarks on new WM5 devices / ROM versions to see how browsers behave on current devices and operating system versions and which one to choose if you want to download a file as quickly as possible.
Note that this review is in no way a complete overview / comparison of all the new, lately-introduced features of the available Web browsers. I'm still waiting for some new versions of some major Web browsers (for example, the official WM5 AKU3 Internet Explorer Mobile with, at last, vastly enhanced AJAX / JavaScript support); it's only after their debut that I'll publish a brand new, generic roundup. This roundup is all about saving something to the PDA, let it be a web page, an image or a file and discussing everything related to downloading files off the Web. You may want to check out the Web browser reviews I've published in the meantime - albeit not in an all-in-one, big roundup comparing all the new browser versions in one article, they contain all the information not contained in this article.
In the first chapter, I elaborate on generic resource saving capabilities like image saving, current Web page saving, link target saving and link copying - probably the most important areas of improvement in the last year. In the second and third chapters I elaborate more on strictly file saving issues; the second will be mainly of interest to people that want to have the best / fastest / most reliable HTTP (Web) download tool on their Pocket PC and the third will concentrate on compatibility issues and common problems. The latter will be a bit more technical than the first two chapters and explains on the protocol levels why some browsers are unable to download files off certain pages or for example doesn't offer the server-side name for a given downloaded file. It will be of paramount interest to affected Web browser developers (Microsoft, Opera, Bitstream and Access).
While the article is self-contained and, therefore, not necessarily requires the reader to read my earlier articles (most importantly, the Browser Bible), checking them out is still thoroughly recommended. Please consult the last, "Recommended links" chapter for the links.
1. Generic browser resource saving capabilities
Most (no wonder these features are in high demand among computer users) Web browser users have at least once wanted to save resources off the Web to the local computer (here: a Pocket PC PDA).
1.1. The three types of resources
Resources, as has already been pointed out, can be of three types on the Web (I use a slightly simplificated approach to be as clear as possible - that is, I don't include intricacies like how for example Flash animations or videos can be fetched from the Web. Consult for example this article on this question.):
images themselves contained in Web pages
web pages (HTML files) containing some text, links and inline images
files on the Web (for example ZIP and CAB files) you'd like to download.
On desktop browsers, you may already know how you can save these kinds of resources onto your computer.
1.1.1. Images
For example, if you want to save a single image in the desktop version of Internet Explorer, you right-click the image and choose Save Image As in the context menu as can also be seen in this screenshot. (Note that, from now on, I link in a lot of screenshots like this; for brevity, I won't, in most cases, mention they're screenshots. Therefore, if you see a link in this article (including the comparison / feature charts), it will most probably be an image link that you will really want to click if you want to see in real what I'm referring to.)
1.1.2. Web pages
The same stands for saving a Web page for offline access (or, when you know it'll change / will be removed and, consequently, want to save it before it happens). To do this inside the desktop Internet Explorer 7, just go to Page and choose Save As (or, in the previous - up to 6 - Internet Explorer versions, File / Save As). In there, you can name the file you're saving and can also change the format you're saving it in: an one-file, really useful Web Archive (.MHT) format, a single HTML without inline images or other related resources (for example, JavaScript or Style sheet includes) or full HTML's with all the related resources (which, then, will be put in a subdirectory of the target directory).
After saving a Web page, you can safely archive / transfer these files - all you will need to do to see them is clicking them. With non-MHT files (there is only one browser on the Pocket PC, NetFront, that does support MHT files), you can even use Pocket PC web browsers (except for the external server-based Opera Mini and Thunderhawk) to read your saved HTML files after transferring and clicking them in File Explorer on your Pocket PC. (Note that there are several other tools (non-browsers) on the Pocket PC to read local, offline HTML files, uBook and Mobipocket Reader being the two most important.)

1.1.3. Files
Third, when you right-click a link to a file you'd like to save (without, for example, directly passing it to an application that knows how to handle it - for example, a MP3 file to Windows Media Player, a PDF file to Adobe Acrobat Reader etc), you can save it in the desktop Internet Explorer by choosing "Save Target As..." in the context menu. Note that with some (mostly binary) contents, you can safely (left) click the link for the same effect on the desktop to be presented the same download dialog box.
On the Pocket PC, particularly with the built-in Pocket Internet Explorer (PIE) (it's called Internet Explorer Mobile (IEM) starting with WM5; this is why I'm referring to it under both names. Also see this article on this and similar name changes if interested), the situation may be different due to the core, in this case, not at all welcome differences between the desktop and Pocket PC versions.
1.1.4. Getting a link of a page or resource
Finally, when you want to, say, e-mail a friend the address (URL) of a Web page or a resource you've found, you can easily do this in the "traditional" way: left-click the link and, then Copy the new URL address to the clipboard (so that, from there, you can easily Paste it to the mail) by highlighting the contents of the address bar of the browser and, then, choosing Copy (or pressing Ctrl-C on the keyboard).
There is, however, a much more elegant and simple solution: instead of left-clicking (following) the link leading to the given resource / page, right-click it and select Copy Shortcut in the context menu. This will not only save you time (you don't need to wait for the page to load - if you don't cancel it in between), but also will work with all kinds of resources, unlike the former, which can not be used if, for example, the accessed contents aren't on a new page but dynamically offered or the content will be passed straight to, say, Windows Media Player.
This functionality may prove useful in other situations too; for example, when you need to use external tools (for example, EZDownload or WinMobile Download Accelerator, which will be discussed later, in Chapter 2) on your Pocket PC requiring the address of a downloadable file on the Web.
So, you'd like to see how you can do these four activities on the Pocket PC? The next sections discuss this.
1.2. Desktop Windows, Pocket PC and resource saving / link address copying to the clipboard
The following chart shows what Pocket PC (and, for that matter, desktop Windows) Web browsers support these kinds of functionalities and how you can access them. As with all my comparison charts, I've tried to make this chart as user-friendly as possible; this is why I've even included screenshots showing how the given functionality can be accessed in different desktop and Pocket PC browsers. (Click the provided links to see them.)
I've also added some version change information in here (as with the other charts); for example, with NetFront and "Copy link address to clipboard?", "new in 3.3" means this functionality was introduced in (the latest) version 3.3 and, therefore, doesn't exist in the previous, 3.2 version. These remarks will be highly useful if you plan to stick with the older version because of the upgrade fee and would like to know what isn't available in it.
Note that the chart doesn't contain PIE plug-ins, only top-level, stand-alone browsers; plug-ins will be discussed in the following section.
As with all the charts, plus (+) means existing feature while minus (-) means the lack of it. OS stands for Operating System (WM2003SE, WM5 etc).
THE CHART IS HERE - CLICK THE LINK!
As can clearly be seen, all the three major desktop Windows browsers support all these (in the desktop word, basic) functionalities. Not so with Pocket PC browsers, not even with desktop ports: for example, the current (8.6) version of Opera Mobile (which is a "dumbed-down" port of the excellent, highly, particularly for (W)UXGA users, recommended desktop Opera browser) doesn't support any kind of explicit resource saving or link copying and the same stands for the free Firefox / Mozilla clone Minimo. Thunderhawk is in the same league and, because of the very simple engine, it's highly unlikely it'll ever support this functionality.
NetFront supports everything; unfortunately, it's only able to save Web pages into MHT files (and not to simple HTML files), which means non-MHT-capable Web browsers (all the other Pocket PC web browsers) will be unable to read the pages it saves, unlike with HTML. (However, there are certain "hacks" that may help circumvent this problem - for example, saving a linked Web page as a file if you have some link pointing towards it or searching for the given Web page in the NetFront file cache.)
Finally, the built-in PIE/IEM is pretty incapable too; it's as late as in WM5 that it has received image saving capabilities. In previous operating systems, you don't have any way of saving images (unless you manually browse the file cache and look for the given resource - more on this later in the section devoted to this question). In this respect, the PIE plug-ins discussed in the next section help a lot: they implement most, or, with the more advanced ones, all the missing functionalities.
(A quick note: with Opera Mini, the free, Midlet-based Web browser running on a wide variety of devices (not just Pocket PC's but also your Java-capable smartphones or even dumb phones), image / link downloading doesn't work in IBM J9 5.7.2 (I've tested this on both WM2003SE and WM5). It, however, is working great in the latest, 6.1 version (tested on WM5). Therefore, you must upgrade J9 to the latter version if you want to access this functionality. Please see this tutorial for more info on version 6.1, the installation etc. Note that you won't have any kind of problems with the other, widely-known Pocket PC Midlet environment, the Intent Midlet Manager, which comes with most Pocket PC Phone Edition devices / ROM versions and, if you don't find it on your particular mobile operator ROM - as is the case with some US operators - is also accessible here as a download. Please read my generic Midlet article on its usage.)
1.3. PIE plug-ins and resource saving / link address copying to the clipboard
If you stick with PIE (and don't use another browser), you can still have additional capabilities with the help of the well-known PIE plug-ins, of which there are, fortunately, several, two of them being even free (ftxPBrowser and the free version of Webby). In the following chart, I list them all and also show (click the links in the chart for the demo screenshot) how the given functionality can be accessed. (Click the links in the first column to read the reviews / comparisons of the most current versions of all these plug-ins.)
THE CHART IS HERE - CLICK THE LINK!
Remarks:
As far as the current (D72) build of MultiIE 4 is concerned, it no longer has image saving capabilities (unlike the previous, 3.x series), which is certainly bad news. This means if you still have a pre-WM5 device, you need to either wait for a new version of the 4.x MultiIE series for this omission to be fixed or need to stick to the old, 3.x series. Unfortunately, MultiIE (along with Spb Pocket Plus) has never had the "Save Target As..." functionality either.
Webby (current version: 2.6) doesn't have explicit current web page/image saving capabilities either. Image saving is only possible under WM5, where PIE itself has image saving features (see the related screenshot in the comparison chart). Under previous OS’es, you can’t save images out of Webby.
Also note that its (existing) link target saving and link-to-clipboard copying features must be accessed in a radically different way than with the other browsers or plug-ins because it has no custom context menus and, therefore, everything must be done via traditional, "global", non-local / non-context menus.
Spb Pocket Plus, while having the other functionalities, painfully lacks the "Save Target As..." functionality, which all the other PIE plug-ins (except for MultiIE) have.
Also note that, as is mentioned ("only via Save Target As") several times in the chart, you can save HTML Web pages if the given browser / plug-in doesn't support Web saving, but it has the "Save Target As..." functionality. Then, you can still save a copy of the Web page - without images or anything related, of course. This, however, won't really help with for example (non-linked) images. This means you can't save images in any way under the MultiIE 4 + pre-WM5 PIE combination or in Webby. You should, however, not give up - there are ways of finding these resources with some additional tweaking (cache hunting), which I explain in the following section.

1.4. What should I do when I need to save some resource but my Web browser doesn't let for saving its type?
With browsers not supporting saving resources (for example the pre-WM5 PIE or Opera Mobile), there is another way of saving resource files by finding them and copying them off the local file cache.
(Quick note: in file caches, caching-capable Web browsers store the (recently) browsed Web pages and all the accessed resources. For example, if you don't disable displaying images and go a Web page that have five in-line images, six files will be created in the cache: the HTML file (the webpage itself, containing the text and the page layout markup) and the five images. Therefore, by manually browsing the cache, you can easily find all the (cacheable) pages, images and even other resources used by the HTML web page. This makes it possible to find resources in the file cache that, otherwise, would be inaccessible / not savable.)
This assumes the browsers
do have a local cache and
the files in there have the original, non-tampered (without, for example, added HTTP response headers - as is the case with NetFront) content
with either somewhat or vastly different names.
Depending on these three conditions, Pocket PC Web browsers belong to one of three groups.
1.4.1. Browsers lacking in (native) resource saving capabilities but having a local file cache that has all the files in the original, non-modified form
There are three browsers in this category. I've already written a fully-fledged tutorial on finding the resources these browsers store in the local file cache; please follow the links in the bulleted list below:
Opera: TUTORIAL: Here's how you can save images from inside best Pocket PC Web Browser, Opera Mobile!
PIE/IEM: Ever wondered why some of the Web pages saved with MultiIE or Spb Pocket Plus are completely unreadable? (alternatives: PPCT, AximSite, PPC Magazine, MobilitySite, FirstLoox) - it, in addition to explaining the GZIP problem, also contains a complete tutorial on manual page/resource finding and saving.
Minimo: you can easily browse the cache files of this browser. First, you need to enable the, by default, disabled caching in Preferences / Advanced. (Fortunately, now, caching works, as opposed to some earlier Minimo versions.) Then, all you'll need to do is scrutinizing the contents of the cache to find the files you want to save (it's a bit more complicated than with PIE/IEM or even with Opera Mobile because of the cryptic, machine-generated filenames Minimo uses in the cache.)
1.4.2. Browsers both lacking in (native) resource saving capabilities and NOT having a local file cache
With
Opera Mini (with this, you can save images but not explicitly pages or link targets) and
Thunderhawk,
you can't do the same because these browsers don't have local file caches. That is, in no way can you save for example the current Web page in either of these browsers - not even with looking for it in the (again, non-existing) cache.
1.4.3. The rest
Of the cases remaining, there is only one browser: NetFront. It, as of version 3.3, offers everything as far as resource saving is concerned (except for non-MHT - that is, HTML - saving). It also has a cache, which, as opposed to the first subcategory in this section, doesn't store the cached files in their original form but with the HTTP response headers embedded in them.
This means you won't necessarily want to use the binary files in there (as you already have "Save target as" functionality). Textual HTML files are different as you can very easily edit them and delete the additional HTTP headers. That is, if you REALLY need to export / save HTML files from NetFront (as opposed to saving pages in the default, only-supported .MHT format), browse the cache as with how the PIE / Opera Mobile / Minimo cache must be browsed by hand.
1.4.4. A comparison chart of the different caching cases
In the following comparison chart, I compare all these cases (whether a given browser has a cache, whether it contains the files in their original, non-modified form and, in addition, whether the filenames are easy to guess or have at least some kind of similarity to the original filenames). In addition, as a bonus, I've also added cache relocation information (and links to related articles), which can be VERY useful in a lot of cases, particularly on WM5-upgraded devices like the HP iPAQ hx4700 and the Dell Axim x50 series (see for example this article for more information on this problem).
Also note that, should you want to relocate the cache to even a volatile (one that gets deleted upon soft resets), but still highly useful RAMDisk, you can safely do this with ALL the cache-enabled Web browsers. This is pretty straightforward with Minimo (where you can select the RAMDisk from the drop-down drive menu), PIE and NetFront (please see the article relocating the Pocket Internet Explorer / NetFront cache (alternatives: PPCMag, iPAQ HQ, AximSite, FirstLoox, BrightHand) for a complete PIE / NetFront tutorial). With Opera Mobile, you need to do some additional work explained here. Make sure you only relocate the cache, not the history / cookie files (you don't want your cookies / browsing history to be entirely deleted upon soft resetting your device, do you?)
Note that I've also listed the three most important desktop Windows Web browsers - this information can be highly useful for you when you browse the Web and want to, say, save Flash animations or Java applet .jar archives for further use without third-party tools.
THE CHART IS HERE - CLICK THE LINK!
2. More thorough elaboration on "Save Target As..." and downloading in general; benchmarks
Particularly hardcore leecher... I mean downloaders (for example, people that would like to download hundreds of Megabytes off the Web on their PDA's) will find this chapter hugely useful. Based on the information contained here, you will be able to choose the best tool for a given task: if you can download a, say, 700 Mbyte .AVI with the fastest browser in, say, 10 minutes, why suffer with a slower browser that takes four or five times more time to download the same file?
Even if you "only" make smaller downloads right on your Pocket PC, you will want to read this chapter as it's full of tips, tricks and real-world benchmarks, explicitly telling you what browsers you should use and how, what to avoid and what pitfalls you may run into with some of them. After all, time is money - the faster the browser, the more efficiently it utilizes the available bandwidth, the better.
Note that, in addition to the desktop Windows and Pocket PC Web browsers, I have included two additional, stand-alone downloader applications, one of them (EzDownload; a free, fully WM5-compliant, slow, particularly when downloading files straight to storage cards, application; it, additionally, doesn't support a lot of other functionalities; for example, non-standard (non-80) Web server ports) being already known to the readers of my older, Web browser & downloading-related article. The other, new one is WinMobile Download Accelerator, which deserves special attention & treatment and will be introduced in the next section.
By the way, if you thoroughly read the above download-related article, you may rightfully ask why I have purposefully left out ViTO Downloader and ftxPBrowser from the current roundup. The reason for this is pretty simple: the former, ViTO Downloader is pretty unreliable (and hasn't been updated since my review); and the latter, ftxPBrowser, isn't at all WM5-compliant when it comes to downloading files. Needless to say, there is no new version of ftxPBrowser ; that is, the above-linked, previous review is still topical.

2.1. WinMobile Download Accelerator (WMDA) 1.8.1.0 (Build 2805)
This is, as has already been pointed out, a standalone downloader app (not a plug-in). It's a bit pricey ($20.00) and can be pretty slow in some downloading situations but well worth the money if you want to stick with "pure" PIE / IEM (without using PIEPlus or Webby, which are, currently, the only WM5-compliant PIE plug-ins with Save Link Target functionality; or, without switching to, say, Opera Mobile or NetFront, which both have much better download compatibility / capabilities) and often run into problems like "the CAB file I've clicked is displayed and not downloaded".
It's unique in that it's the only Pocket PC download application to support multisegment downloading (see the next section on what it means and when it can be advantageous). This means it's particularly recommended if
you often download files from slow(er) Web pages where multisegment downloading may be of use
you use plain PIE / IEM (NOT with a Save Target As-capable PIE plug-in like PIEPlus 2.0+ or Webby) and often have problems with rendered (and not downloaded) binary files
As opposed to what the developer's homepage states, it's not only compatible with WM2003 and WM2003SE, but also with WM5.
It's pretty extensively configurable; for example, you can even supply server auth code and enter referrer explicitly, which is very important with several Web sites (see the Caiman section in Chapter 3 for more info). Some other screenshots: 1 2 3.
Note that it also integrates into PIE / IEM, even under WM5, unlike EzDownload. That is, if it intercepts a download request (you click or, to the Address bar, enter a link that, for example, ends at .EXE or any predefined, freely editable "binary" extension), its dialog will come up and will be used for downloading. This can be configured in Tools / Options / IE; it's also here that you can supply a referrer (just like with EZDownloader).
The download extension list can be freely edited and new extensions added; for example, if you want to add CAB to the list (so that, when you click a CAB link, it'll be downloaded by WMDA and, if you aren't lucky, just rendered as a text file by PIE), just add ".CAB" to the list as can be seen in here. Then, the text/plain-related problem of PIE (of which I'll speak in the next, third chapter) won't be an issue any more - whenever you click a link that ends in .cab, it will be passed to WMDA for download. (Note that the same doesn't apply to NetFront or Thunderhawk - WMDA doesn't integrate into any other Web browser.)
2.1.1. Where can WMDA be really useful? Multisegment download and the (dis)advantages
You may have already heard of desktop Windows-based download managers like FlashGet and/or GetRight. The former is free software, the latter commercial. Give (one of) them a try if you're a serious downloader - you'll really like the really enhanced speed. Both support all the three major desktop Windows browsers: Internet Explorer, Firefox and Opera.
These plug-ins really speed up most transfers by using multisegment (parallel) downloads, which means the client not only downloads the given file in one thread, but in several.
On the Pocket PC, there is a similar solution delivered by WMDA. I've done a lot of tests to find out how good and reliable it is. I've also made some extensive benchmarks comparing the one-threaded and the (by default) five-threaded multi-segment mode of it with both fast and slow sources.
When accessing really fast (over 30 kbytes/s transfer speed) sources, you will NOT want to use it because it's definitely slower than the native download speed of ANY Pocket PC Web browser. However, if you are downloading something from a very slow HTTP server, the situation will be different: I've measured about two times shorter download times with WMDA than with any other Web browser (Opera, IEM, NetFront etc. - with slow sources, these one-threaded / one-segment browsers all produce roughly the same transfer speed).
The benchmarks of accessing (downloading from) fast servers will be in a later section elaborated on (because, unlike with the "slow" case, then, there may be considerable differences in how quickly a given Web browser downloads files off fast servers, which also necessitates a big chart listing a lot of cases and benchmark results).
The "slow server" case is certainly worth elaborating on: it's downloading from servers with slow connections that WMDA really excels (and, in addition, helping with downloads that, otherwise, would result in the browser's trying to render the binary contents of the file instead of downloading it).
For the slow test, I've used two well-known (at least from here Europe) "slow" servers: that of revolutionary software front and Octopus Studio (see the Definitive Roundup of All Pocket PC Dictionaries Part I - WordNet-based English Dictionaries and the Pocket PC Wikipedia Bible for more information on their, in cases, excellent products).
With the former site, I've chosen this file for testing; with the latter, this. Both are around 8 Mbytes. For the test, I used my Dell Axim x51v and downloaded to main storage (in this case, there is little importance of this because of the slow speed - it's only with fast downloads that the device model and the target of the download may have any effects on the overall speed, not with comparatively slow, 10-20 kbytes/s downloads.)
I've conducted the tests several times (listing all the individual results in the table cells below) to get as usable results as possible and to "weight out" the extremes. Note that cells with only one benchmark result can be safely ignored because the non-segmented download time benchmark results wildly vary. The results are given in minutes:seconds; the smaller, the better.
THE CHART IS HERE - CLICK THE LINK!
As can clearly be seen, with both servers, WMDA resulted in a clear speed increase in both cases. With the Revolution.cx file, it took less than 4:16 in all cases to download the file, while, with Opera Mobile, at least 60% of the transfers took more than 5 minutes (once even 11 minutes). The case is very similar with the octopus-studio.com tests.
2.1.1.1. Usability matrix - when WMDA should be used?
I've also created a matrix showing when using WMDA may be really a good idea. (Note that it does not contain the case of binary-files-not-offered-for-download case, which can be an issue with a plug-in-less PIE. If you have PIEPlus 2.0+ or Webby, you won't need WMDA to fix the above problem; in all other cases, you will, unless you're ready to hunt the file cache by hand.)
In the matrix, I show four cases: accessing slow/fast servers through slow/fast connections. All this compared to the speed offered by regular, traditional one-segment-download Pocket PC Web browsers (except for the slow Thunderhawk, which is even slower than WMDA in the "fast server" case).
Note that
I've assumed the server allows for multisegment downloads. Many don't. With them, you won't be able to use WMDA (or, you will be able, but in one-segment mode only, which will result in a really bad (further) speed decrease and, in addition, an additional byte containing a zero byte added to the file. This both means in this case you will not want to use WMDA but use "traditional" downloading methods / browsers instead).
I assumed slow client Internet access is in the range of GPRS speeds (3-5 kbyte/s) - that is, at least 3-4 times lower than the throughput of the slow server (which I considered to be between 5-20 kbyte/s, which is pretty common - see the above-tested two "slow" servers). By fast Internet access, I mean over 1 Mbps speeds; the same stands for fast servers.
That is, the chart:
THE CHART IS HERE - CLICK THE LINK!
That is, you should only consider using WinMobile Download Accelerator if you aren't downloading from fast servers (where you can download with more than 20-30 kbytes a second from). In all other cases (accessing a fast server), WinMobile Download Accelerator will deliver clearly inferior speed than all the other solutions (except for the even slower EzDownload and ThunderHawk), as will be clearly seen in the forthcoming, "fast server" download benchmarks.

2.2. Downloading in general - chart
In this chart, I've collected everything that has direct impact on downloading. These are not benchmarks but generic features (and, with the last column, possible sources of problems / slowdowns).
Explanation for the chart:
Resuming, stored download list: The first column (pause/resume) elaborates on whether the transfers are stored through restarts (which would be highly preferable and is also implemented by all decent desktop-based third-party accelerator plug-ins). As can clearly be seen, only WMDA supports this.
The second column shows whether a partial download can be resumed (which the HTTP protocol supports; so do desktop browsers). Unfortunately, only WinMobile Download Accelerator and EZDownload support this.
Multisegment (multithreaded) downloads: The third column shows whether the given application supports multisegment (multithreaded) downloads, which can considerably speedup transfer with slow(er) Web servers. As can be seen, it's only WinMobile Download Accelerator that supports this.
2.2.1 Implicit buffering in built-in storage?
The fourth column, "Implicit buffering in built-in storage?" is one of the most important: it addresses a common question / problem with built-in (or, in cases, third-party) Windows Mobile Web browsers and downloader applications: When you download a file to a storage card, does the given Web client use the built-in storage as a temporary storage medium and only flushes the (temporary) contents to the storage card when it's absolutely necessary (or at the end of the transfer). The two approaches (buffering-less and one that does use in-storage buffering) have radically different consequences.
Advantages of the buffered mode:
It may be, in cases, considerably faster than the non-buffered case. This would particularly be the case with RAM-based storages in operating systems prior to WM5 (see the benchmark results of the WM2003 iPAQ 2210 and the WM2003SE PL720: PIE is at least three times slower with them when writing to the storage card directly). In WM5, however, it's no longer the case: buffered solutions are not necessarily faster than non-buffered ones. (Unfortunately, none of the Web browsers that do use buffering use the dynamic RAM for this purpose, only the file system. This could be later worked on in later IEM or WMDA versions.)
Disadvantages of the buffered mode:
On WM5-upgraded devices that have slow-to-write and even-slower-to-delete flash ROM (Dell Axim x50 series, HP hx2xxx and hx4700), using these applications may result in lengthy filesys.exe sessions, which you don't necessarily want. (This is why, while benchmarking the built-in IEM of the WM5-upgraded hx4700, filesys.exe-based compactions have always kicked in during downloading the 8Mbyte-long test file)
If the built-in storage is smaller than the file to be downloaded, there may be problems (or at least severe slowdowns) when the built-in storage memory runs out (see the PIE/IEM- and WMDA-related comments).
The two applications that use the built-in storage for buffering behave differently in the second case. IEM under WM5 (under previous OS'es, PIE doesn't buffer) is very well written; when the memory fills in, it flushes everything out to the target card and then, continues downloading without any problems, crashes or CRC errors. The only problem you'll then encounter will be the drastically (about three times) reduced transfer speed.
WinMobile Download Accelerator, the other application that does in-storage buffering, behaves differently: when it completely fills in the built-in storage, the transfer just stops with an error message. This is very bad news: this means you will never be able to download bigger files than the current size of your free storage, unlike with all the other Pocket PC-based downloader solutions. Fortunately, this can be fixed by relocating the cache to a large, well-optimized memory card - with some (additional - fortunately, not really bad) speed hit.
2.2.2 The chart
THE CHART IS HERE - CLICK THE LINK!
Note that "See with PIE" with Opera Mini means the latter uses the PIE / IEM engine to download files / images. This means all benchmark / resumability etc. data are the same with the two browsers.
Now, let's have a look at how the browsers and downloader apps fare over fast connections, with fast servers. It's in here that there will be major differences, as opposed to the three other cases (where either the client or the server is slow - or both).
2.3. Downloading speed benchmarks
While with short downloads and/or downloads over a slow link (for example, if you have a slow GPRS connection), browsers behave exactly the same way, over very fast connections, accessing servers that also have a fast Internet connection, there can be huge differences between different Web browsers.
My benchmark results are contained in the next comparison chart, where each column contains the time needed to transfer a given test file off a local Web server on my desktop on the (freshly hard reset and containing only the tested applications) test device. I've benchmarked both built-in storage (which is RAM with pre-WM5 devices and flash ROM with WM5 ones) and a storage card (which was the same in all cases; always freshly formatted with exactly the same parameters).
Note that, with WM5 devices, I haven't tested the, otherwise, excellent RAMDisks because they are inherently small (6...10 Mbytes at most) on current, "official" WM5 devices (not the MDA III with the "hacked" WM5, where you can create even a 96 Mbyte-large RAMdisk because of its huge, 128M built-in RAM) and, therefore, of little utility in trying to speed up transfers.
Making clear distinction between the given memory types available in a given device is very important. As you may already know (and has already been pointed out in many of my WM5-related articles), writing to dynamic RAM is by far the fastest process. Writing to flash ROM-based memories (this includes both storage cards and built-in storage on WM5 devices) is, in general, slower than writing to RAM. This is why the "slow", over three years old, WM2003-based HP iPAQ h2210 smashed the WM5-based competition in all transfer tests into the main storage.
In the tests, I've used this file on a local Web server (with Thunderhawk, I used the, in size, comparable Minimo 0.016 CAB file because the central Thunderhawk server had problems with accessing my local desktop). Do NOT try to benchmark your browsers directly from this Web site as it may have slow international bandwidth. Make sure you upload it to a site (for example, one on your desktop computer your PPC directly connects to through USB or any Intranet web server at work) that you can access very fast so that there won't be bottlenecks in the achievable transfer speed.
Finally, as has already been pointed out, I also made sure I used the same storage card in all the devices so that the different card characteristics (write speed) don't cause any difference.
THE CHART IS HERE - CLICK THE LINK!
As can clearly be seen, there are huge differences in how different devices behave. For example, on the Axim x51v and the iPAQ hx4700, there are almost no differences. On the HTC Wizard, on the other hand, the differences between the only really fast-to-download Opera Mobile and the rest are really big.
It's also worth pointing out that on all the three WM5 devices, unlike with pre-WM5 OS'es, PIE / IEM-based downloads are almost equally fast when downloading to a storage card and when to the built-in memory (unless the latter has less free space than the file you're downloading to the memory card - then, even three-fold differences in speed can occur). This is because, as has already been pointed out, under WM5, IEM buffers in the main storage first and only flushes to the card at the end of the transfer (if the main memory doesn't fill in entirely in between); hence the similar (and, compared to pre-WM5 devices, in general - except for the Wizard - much better) results.
EZDownload fared equally bad on all the test devices when writing directly to a memory card; particularly on the HTC Wizard. It's best to avoid it completely, unless you, for some reason, really need it. Writing to RAM is of acceptable speed on pre-WM5 devices (but in no way as good as with any other application - except for WinMobile Download Accelerator, which is equally slow when accessing fast servers). Generally, download add-ons are much slower than other solutions.

As a rule of thumb, if you need to choose the fastest browser for downloading (from fast sites over fast connections), Opera Mobile is your best bet. It, incidentally, was much-much slower in the beta versions (see the previous download speed tests). It was really worth pointing out the bad transfer speed of Opera Mobile back in January: it has gained a great speed upgrade, which makes it for example on the HTC Wizard by far the best browser. This, of course, greatly depends on your particular model: as can clearly be seen in the chart, the x51v and the hx4700 has pretty similar speeds with all the Web browsers (except for, again, the slow Thunderhawk), so has the iPAQ h2210. It's only with the Loox and the Wizard that there are really huge differences between downloading efficiency.
Also note that I haven't included Opera Mini in this chart - as has already been pointed out, it uses the PIE / IEM engine for downloading and, therefore, has the same speed as PIE / IEM.
Note that I've not only made extensive benchmark tests but also CRC checked every downloaded file on all test devices to see whether they contain bit errors. I haven't encountered any problem (except for the additional byte (containing a zero EOF byte) of WinMobile Download Accelerator in the not recommended, very slow one-threaded mode).
2.3.1. A quick comparison of current and previous Opera Mobile and PIE/IEM versions
As has already been mentioned, the new version of Opera Mobile and PIE/IEM versions are radically different from the previous ones when you download straight to a memory card. The (really welcome!) changes, just to recap, are as follows:
THE CHART IS HERE - CLICK THE LINK!
3. "Why can't I download CAB / other binary files in PIE / any file off some sites?" - compatibility issues
Now that we know
how the available self-standing browsers and PIE plug-ins support saving resources (even with manual file cache browsing when there are no other choices)
what WMDA can be used for, how the different Web browsers and Web downloader utilities compare to each other and which of them runs on which Pocket PC model the best,
let us switch to a slightly different area: that of compatibility issues. There will be several of them.
3.1. „Content-Type"-related problems (AKA "When I click a CAB link, it's not downloaded but shown!")
First, I'll explain one of the most common problems of PIE/IEM, Thunderhawk and NetFront users: the problem of non-savable CAB files.
That is, when you click a CAB file on a Web to be downloaded (so that you can save it in the local file system and execute it there for the given Pocket PC application to be installed), PIE, Thunderhawk and NetFront, in cases (with some servers), renders (shows) the contents of the CAB file, instead of letting the user download it.
Of course, the problem not only applies to CAB files, but also other types of files; for example, the MDX files on octopus-studio.com (for example, the file used in the WMDA-related section to measure the download speed of the given Web browsers compared to WMDA) also suffer from the same problem.
The reason for this is very simple: the servers don't set one of the returning HTTP response headers, Content-Type, correctly, but leave it at the (for unknown / not manually configured file types) default text/plain type.
While the desktop IE (along with all the two other Web browsers) correctly handle these files, this is not the case with three Pocket PC Web browsers, the built-in PIE (yes, unfortunately, there are some algorithmic differences between PIE and the desktop IE), Thunderhawk and NetFront. These, when they receive content marked as plain text (that is, having the text/plain header in the answer of the Web server), will blindly render it (instead of presenting the user a save dialog) even if it's binary in reality.
Current examples of Web servers that return CAB and/or other, similar files as text/plain is that of the above-mentioned Octopus Studio site (with an example file here, linked from here), FinchSync (example file here) and TasksPlus (example file here). The last two examples are also linked from the Application category of FreeCabs.
To fix these problems is fortunately pretty easy if you have PIE:
consider using a link target saving-capable PIE plug-in (as far as WM5 compliant ones are concerned, PIEPlus and Webby (even the free version of the latter); under previous OS'es, you may also use the free ftxPBrowser)
alternatively, you can manually browse the cache to find the CAB file or,
if you have either Spb Pocket Plus or MultiIE (two PIE plug-ins NOT allowing for directly saving link targets but allowing for saving the current page directly, verbatim, without modifying it contents), you can use them to save the currently "rendered" binary file as a HTML web page. You'll only need to rename this file with a file extension-capable, third-party file explorer like Total Commander or Resco File Explorer and, then, you'll have the original binary file
if you often download from slow sites over a not very slow local connection, you may want to consider giving WMDA a try: it not only helps with downloading from sites with (comparatively) slow connections, but also integrates into PIE, making downloading even easier than with EzDownload (there is no need to copy any target / file URL to the clipboard). It's also considerably faster than EzDownload.
finally, if the pretty bad transfer speed isn't a problem (or not so important as not paying anything for any third-party, commercial utility like WMDA or the four above-mentioned utilities, you don't want to use the free version of Webby and don't want to manually search the cache either), you may also want to give a try to EzDownload. Then, you just copy the address of the current CAB / other binary file off PIE's Address bar to the clipboard, and invoke EzDownload.
Note that with Thunderhawk, you can't do anything to remedy this situation. It doesn't have any kind of cache to browse or current Web page saving capabilities.
NetFront, fortunately, has "Save link target" functionality in the new, 3.3 version; that is, you'll be able to directly save a linked binary file by not clicking it, but tap-and-holding and selecting Save / Link Target in the pop-up menu. The situation is different with earlier (even 3.2) versions without the explicit "Save link target", and not even cache hunting helps as it does have cache but it modifies all cached files (by adding the HTTP response headers to them) and doesn't offer verbatim saving capabilities.
Finally, don't forget to tell the webmaster of the site that your PIE / TH / NF receives binary files as textual to either adding the given file extension to the known so-called "MIME type" configuration file as either application/octet-stream (real-world examples of servers using this: 1 2 3 4 5 6) or, even better (because, then, PIE / IEM won't ever attempt to parse them for a known file type), application/ANYTHING where ANYTHING can really be anything; for example, x-MyDummyMimeType. In the latter case, it's preferable to start it with x- to show it's a custom (non-standard) type. Note that with CAB files, it's customary to use one of the following three MIME subtypes (in place of "ANYTHING"): vnd.ms-cab-compressed (as with this server; example download), x-msdownload (as with the PocketGear server; example here) and x-compressed (as with the Minimo server; example download ). (Incidentally, this excellent article suggests the usage of the x-download subtype.)

3.2. Double requests upon file download - the RapidShare problem
In the above-linked AximSite thread, I've been told of a strange problem affecting Opera Mobile and NetFront, making it impossible to download anything off the well-known file distributor service RapidShare.
I've found the protocol-level cause for the problem after some investigation: NetFront and Opera Mobile, when downloading any resource, resends the requests (in both GET and POST mode) sent out right after the download starts. This is what causes the RapidShare service to immediately close the transfer and just return an error page. (NetFront reissues exactly the same request (for example, two times the same POST), while Opera Mobile, if it sent out a POST request first, sends out a GET second - to the same URL. Both issue additional no-cache headers in the second request when needed.)
Note that the desktop Opera doesn't suffer from this problem - only Opera Mobile.
This means if you have problems with these browsers and RapidShare (or, for that matter, any Web page that only accepts one download request and just returns an error page upon the second), use an alternate Web browser like the built-in PIE or Minimo. Note that, specifically with RapidShare, Thunderhawk won't work either because it won't be able to count down - its JavaScript compliance is limited.
(Some debugging screenshots of what's happening, using the excellent, albeit expensive and easily crashing debugger proxy Charles (this time, I haven't used my debugger proxy). With PIE, the POST request sending the captcha code and the direct URL of the file to be downloaded is here; here's the response (the file itself), after which PIE doesn't send out another request(s). The initial request is exactly the same with the (buggy) NetFront; so is RapidShare's response. However, right after starting the download by the user, NetFront issues a second request for the same resource, which results in an error page to be returned by the server.)
3.3. Referrers passed to download? The Caiman problem
I've (re-)tested the "Referer" problem of PIE explained here (please read it for further info) with all the new browser versions. The best news is that, except for, it seems, Thunderhawk, none of the major browsers have related problems - including, fortunately, WM5. Kudos to Microsoft - PIE / IEM is really getting more and more stable and standards-compliant.
(This, of course, still means you can't use PIE under previous operating systems on sites requiring explicit Referer passing. There, use alternate browsers or some download managers which also allow for Referer setting.)
3.4. Comparison chart
In the following chart, I've listed all the above cases, with some additional ones. These explain whether a given Web browser parses the contents of a given Web resource returned with the application main MIME type and either the well-known widely used octet-stream subtype or with a deliberately unknown subtype. I've also thoroughly tested where the Web browsers look for type information and where they get their filenames from. I don't explain these columns as they are "only" of interest to Microsoft, Opera, Bitstream and Access developers and anyone knowing the HTTP protocol well enough to understand the separate cases. These columns are of no interest to ordinary, non-geek people - not even with explanation.
Note that, as usual with my thorough protocol compliance tests, I’ve used a custom-developed HTTP server emulator to test all this. It (the source – as usual, I release it as sources so that you can also have a look at it) is available HERE and should be used the following way:
the first parameter should contain the name of the file to return. This makes it possible to test the browsers with a lot of different types of files – image files, PDF files etc. The point in this the ability to find out that, say, does the browser try to find out the real type of files that are sent back as application/octet-stream or, horribile dictu, application/HERE-IS-SOME-UNKNOWN-SUBTYPE. (Also see the second parameter on setting this type)
if the second parameter is a single Y, application/octet-stream will be returned as the file type; otherwise, the custom and by Web browsers unknown application/x-download. The point in this parameter is that, testing the Web browsers with both combinations, you can see whether they differ in how they handle different subtypes of the application MIME type. Implementing and testing this was really useful and instructive: as you can see in the “Save (+) or render (-)., depending on the type” group, PIE treats files of type application/octet-stream differently than files with an unknown subtype.
Finally, the third parameter is either a “Y” (then, it returns the real name of the file) or a custom-given name in the Content-Disposition header. For example, if you supply an “anything.dic” name as this parameter, it’ll return this name and not the real name of the file. Implementing this conditional, I was able to test whether the Web browsers do parse the contents of the file to find out whether it’s of a different type than its name suggests in the Content-Disposition header. The results gained by using the two possible cases can be seen in the first two columns (“Peeks into file to decide its type to override the type given by C-D filename / URL?” and “Takes into account C-D filename?”) of the “It decides for the content type & gets the filename by...” group.

There was another test I’ve made (you can do the same too), which is listed in the last (“Takes into account last URL part? (Not usable with, say, servlets!)”) column. If you supply an additional path information to the URL (in the form of, say, http://test-PC-address:82/bogusfilename.bogusextension), fooling the Web browser into thinking it’s requesting a file off the server with the filename bogusfilename.bogusextension, you can test whether it tries to set the name and the type of the saved file based on this information.
THE CHART IS HERE - CLICK THE LINK!
Note that C-D stands for the Content-Disposition HTTP response header, which tells the client (in the "Attachment" property) what filename a given, dynamically served and/or generated file (that is, one whose name can't necessarily be guessed from the request URL sent by the client) should be saved at. (See this for more info.) Unfortunately, Opera Mobile (unlike the desktop brother) just ignores this header; this is why it doesn't know under what name a given file should be saved at.
3.5. Summary chart: the differences between desktop and mobile versions
Now that we've seen the Pocket PC-based and the desktop Opera and Internet Explorer are different in some respects even on the protocol level, let's have a summary of these differences. This will be of great help to Web authors wanting to make sure their Web contents are accessible by both desktop and Windows Mobile clients:
avoid only relying on the client's ability to get the filename off the C-D HTTP request header of dynamically created files: try to use a bogus filename at the end of the invoking URL because it's from there that Opera Mobile tries to extract the filename from
upon receiving double requests in rapid succession for a given resource, don't return an error page (instead of the requested resource) to the second request but return with the same resource (the RapidShare problem with NetFront and Opera Mobile)
never use the text/plain type because it'll make PIE / IEM and NetFront try to render the page without actually checking for being binary. Even application/octet-stream should be avoided (use application/SOME-UNKNOWN-TYPE instead) if you don't want PIE / IEM to try to even peek into the file to find out what type it is. Try to keep your MIME type configuration as up-to-date as possible and make sure you include file extensions of all binary types you or your users put on your / their homepage(s).
THE CHART IS HERE - CLICK THE LINK!
It's worth pointing out that the desktop Mozilla / Firefox and the Pocket PC Minimo work exactly the same way in every respect - as has always been the case. Great, promising work - certainly the dream of webmasters sick of profoundly different desktop and mobile versions!
4. Recommended links
The Web Browsers category on my blog
How can you avoid the consequences of a new, file download-related bug I've just found in Pocket Internet Explorer? - now deprecated
Beware of downloading large files straight to memory cards, even over fast connections! It can take ages! - now deprecated
Downloading files with PIE (alternatives: PPCT, AximSite, PPC Magazine, FirstLoox, BrightHand). (Pretty outdated!)
Do you know ftxPBrowser? - somewhat deprecated: no WM5-related compatibility info; however, it provides a good overview of the features of the browser
Here's how you can save images from inside best Pocket PC Web Browser, Opera Mobile! - still topical
New version 1.06 of Great Alternate Web Browser NetFront is out! A full review - with some page loading / rendering data
Link collection to the latest Pocket PC Web Browser reviews (will update some time)
Relocating the Pocket Internet Explorer / NetFront cache (alternatives: PPCMag, iPAQ HQ, AximSite, FirstLoox, BrightHand)
Bible of Web Browsers (alternatives: MobilitySite, AximSite, FirstLoox, PPC Magazine, BrightHand) – over a year old, but still contains topical info
UPDATE (10/14/2006): PPCT frontpage; added an explanation of the HTTP server emulator.

(Finally, guys, sorry for posting the article in so many pieces. Have to slice it up because of the 10k char limit)

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

FULL ROUNDUP:Browsing the Web on Windows Mobile just like on iPhone,incl. IEM6 review

After purchasing an iPhone 3G, I immediately fell in love with Safari, its Web browser. Granted, it's somewhat less capable as the best, comparable Windows Mobile (WinMo for short) titles (no Flash, no page saving, no copy/paste, no Opera Link, no explicit text size settings, no caching etc.) and, from time to time, it crashes even with the last, 2.2 firmware version, but it's still much better usable and much faster than anything on Windows Mobile.
Needless to say, seeing the immense success and popularity of iPhone's Safari, Windows Mobile software developers followed suit and, for quite some time now, have been trying to simulate the interface and easy controllability of Safari. Sure, they can't circumvent the problems caused by the hardware (namely, the resistive touchscreen, which, in cases, require a lot of pressure, unlike on the capacitive iPhone); nevertheless, the Windows Mobile developers have indeed managed to come up with some really decent alternatives.
In this roundup, I mostly explain how current Windows Mobile Web browsers are able to provide the same user experience as Safari on the iPhone (again, apart from the much inferior hardware, touchscreen-wise). There have been several shots of providing the same; see for example THIS and, most importantly, THIS article. The latter one, unfortunately, severely lacks in that it only compares Internet Explorer Mobile and Opera Mobile 9.5 - read: no SkyFire, no Iris, no NetFront, no Opera Mini. In addition, the date of the article also shows that it doesn't test the latest Explorer Mobile 6 and the latest, further enhanced builds of Opera Mobile.
Being focused on Safari-like finger-only controllability, I've also reduced the stuff that is more technical: for example, Web compliance testing, strict benchmarking and documenting even the most hidden features. Please consult my previous all-in-one article (my W3C speech) for more info and further links on all these.
I've only tested browsers capable of finger-based scrolling. This is why I've completely disregarded older, non finger-based scrolling-capable plug-ins and that I used Spb Pocket Plus with the older (but still exclusively used) Internet Explorer in order to add this kind of functionality.
Note that I provide a lot of info never before published; for example, a decent (!) comparison of the latest buzz, Internet Explorer Mobile 6 (IEM6) to the previous version, running on real(!) devices - and not just emulators. As you will see, the current IEM6 version is simply not worth bothering with - it's definitely slower and, configurability-wise (see the lack of One Column mode or the lack of the, on (W)VGA devices, highly useful Use High Resolution switch), far less capable than the previous IEM. It's just not worth flashing your device with a ROM containing IEM6 - for example, Tomal 8.5 for the HTC Universal and MoDaCo's Touch HD ROM's - currently, there [still] aren't easily-installable CAB distributions of IEM6, you need to hunt down an XDA-Devs or MoDaCo-cooked ROM coming with it; currently, it's the only way to get the browser onto your phone.
Also note that, now with high-resolution screens being increasingly used in devices like the Diamond and Diamond Pro (VGA) and the X1 and the HD (WVGA), I've found it sufficient to run the tests on VGA devices, and only some on QVGA ones (mostly for testing QVGA-only versions). Therefore, most of the screenshots and the additional hacks (for example, the VGA Jbed one) I provide are for VGA devices.
Note that I paid special attention to elaborating on how the reviewed Web browsers are able to use large(r) fonts so that you'll be able to use them while, for example, commuting to/from work. (Actually, it was, at first, because of this that I started testing browsers in this regard. I generally love riding the bike in the gym. I want to remain thin and biking is the best way to do this. It, however, can become very tedious, particularly if you ride three hours without any pause so that you can always keep your pulse over 120. Watching a movie from one of my 15" UXGA ThinkPads is one way of killing the time during this; another is browsing the Web on my PDA's and smartphones. This, however, requires you to use comparatively large characters as you're constantly moving and keep the device in your hand.) In this regard, the VGA screenshots I present and the approach I take (let's find out whether the browser is able to render the test pages with sufficiently large characters) can be perfectly applied to QVGA devices. After all, it's only when rendering text with small character sizes ("requiring a magnifying glass") that there's significant difference between low-res (QVGA) and hi-res (VGA or WVGA) screens; with large character sizes used, the difference pretty much diminishes. (Apart from the characters' being much prettier and less blocky / pixelizated, of course.)
Mozilla's Mozilla / Firefox port still has no Windows Mobile version. Finally, note that while Makayama's Touch Browser does support iPhone-like scrolling, I just don't see any point in actually paying for it. In the tests of the latest, 1.16 version on my HP iPAQ 210, it proved to be vastly inferior to the IEM + Spb Pocket Plus 4 combo. The latter scrolls pages orders of magnitude faster and nicer. There is just no comparison between the speed of the two browsers. Speed issues aside, the current, 1.16 version still isn't much better than the initial version I've reviewed HERE (albeit some of my biggest, interface-related, complains have indeed been fixed; for example, a QWERTY keyboard has been added.)

1.1 Opera Mobile 9.5
Let's start with Opera Mobile, which is, especially with its latest version (so far, only released for the Samsung Omnia, but already ripped by the XDA-Developers folks and released as an easily-installable CAB file), offers everything a decent Safari-alike should - and more. With Opera Mobile, the only difference in browsing the Web will only be your having to actually hold down the touchscreen for it to work.
Currently, there several versions of Opera Mobile. Of them, I’ve reviewed the (currently) official and, compared to the Omnia version, old (Oct. 2008) version 9.51b2 available for download HERE and the much more recommended, latest, unofficial Samsung Omnia version available HERE (direct links to download HERE and HERE. Note that there’s a combined VGA + QVGA + Flash Lite 3.1 version HERE; it has all the three CAB’s in one RAR file). The latter is the way to go if you have a QVGA Pocket PC or want to see embedded, Flash Lite 3.1-compliant videos (currently, YouTube, Google Video, blip.tv and PornoTube - nothing else; please see THIS for more info). If you, on the other hand, have a VGA model, you absolutely don't want built-in support for the above-mentioned video services or don't need the freedom of the zooming the new version offers (most of the time, you'll find the old, official version in this regard just OK), you may want to stick to the official version.
Note that there’re a lot of (slightly) older “unofficial” Opera Mobile builds. Some are, in some respects, better than the Omni release reviewed in this roundup; for example, some support being installed to a memory card, while the Omni version doesn’t. I haven’t included these older builds in the article to keep its size down.
Speaking of “unofficial” “rips”, also the question of legality should be mentioned. While, strictly, it’s not really legal to rip a browser off a ROM (and installing it on a device), as Opera, currently, doesn’t offer any kind of a downloadable and purchasable, stable and final version of Opera Mobile, I think that, for the time being, you can freely install these XDA-Devs rips on your phone. However, when a commercial (and superior) version of Opera Mobile is released, you will want to upgrade to it. Not only because you it’s everyone’s interest to support the, currently, best multiplatform browser developer that produces browsers that are really pleasant to work with on both desktop PC’s and mobile phones / PDA’s so that they can continue improving their products, but also because the final version will surely have Opera Link.
Support for Opera Link, unfortunately, is severely missing from the currently available 9.x Opera Mobile builds. I’ve played a bit with overwriting \Application Data\Opera9\opera6.adr with the desktop Opera’s \Documents and Settings\username\Application Data\Opera\Opera\profile\opera6.adr, but in vain: it didn’t work. (The reason for this may have been my bookmark file containing some 3000 bookmarks.) I’ll go on with hacking the file to see whether there’s an easy way of doing so. If I succeed, it’ll mean you’ll be able to easily replicate your desktop Opera favorites on your WinMo phone (and vice versa), which will, to some extent, fix the lack of Opera Link.
1.1.1 Problems on VGA devices
Note that the CAB above is strictly meant for QVGA devices; if you want to install Opera Mobile on VGA devices, you'll need THIS file instead. It fixes all the issues of the original version: provides a VGA skin (directly available HERE, should you want to deploy it on the original, QVGA version), which, in addition to providing large icons, also doubles the size of the on-screen zoom arrow and, finally, increases the zoom magnification to 200%.
You may want to know what the latter means (even if you no longer need it - the VGA CAB comes with the hack applied) - after all, Opera Mobile has excellent (!) configuration and tweaking capabilities worth knowing of (some of them are listed HERE - and, of course, my chart.) With the QVGA version, automatic (the one with double-taps) zoom-in seems to calculate the right zoom level based on QVGA horizontal sizes; that is, the zoomed-in state will contain at most half the size of the actual, zoomed-in contents as can be seen in the following screenshots:
{
"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 same screenshot taken showing the exact same screenshot on a QVGA model (also showing the newly-introduced, albeit, for quick positioning, useless minimap in the upper left corner):
This means you, unless you do the hack I'll describe soon, almost always want to prefer using manual zoom to correctly zoom into the text. To avoid having to do this, just enter "opera:config" in the address bar:

Then, select Adaptive Zoom (it's on the top) and scroll down to Maximum zoom. Change 100 to 200:
After this, automatic (!) zooming will work just fine.
Important: this version (both the QVGA one with the additional tweaks explained above and the VGA one) uses pixel doubling with images (and videos). This, to my knowledge, can't be fixed. Nevertheless, it, otherwise, works just fine on VGA models.
1.2 SkyFire
The second, particularly for QVGA users, most recommended browser is SkyFire, which works in exactly the same way as the pretty much useless, incapable and, since then, cancelled DeepFish did: everything is done on the central server(s) of the developer. The server only transfers (QVGA-resolution) images to the client. In this regard, it's less data use- and CPU-efficient, than Opera Mini, the other (current and recommended) solution using the central server approach. Yes, it constantly uses your data connection and CPU; which means both (at times, dramatically) decreased battery life and increased data usage. Keep this in mind if you plan to use it over a non-unlimited cellular connection. Furthermore, if you have a VGA device, you may want to look for something else if you can't put up with the low-resolution, pixel doubled text and graphics.
It has a lot of goodies. For example, it has one of the best zoom-in algorithms: it has never failed to zoom into text. With all (!) of the other browsers, there have been problems doing this with some sites or forums - even the latest, b15233 version of Opera failed at this sometimes, necessitating some kind of a manual zoom-in, let alone the others.
Furthermore, it supports playing Flash, Java applets, Ajax and everything else Firefox / Mozilla on the desktop Windows supports. This means it's capable of playing back YouTube etc. videos - and not only them, but virtually everything: as it uses the "real" Flash behind the scenes, it has no problems playing back Flash 9 contents either - that is, the video services Flash Lite 3.1, used together with Opera Mobile b15233, is incompatible with.
Note that it does have some disadvantages at playing back YouTube (Google etc.) Video compared to the Flash Lite 3.1 + Opera Mobile b15233 combo. Granted, it's far better in that
1, it uses far less CPU at rendering videos than Opera Mobile: about 40-50% on my 624 MHz HP iPAQ 210, while Opera Mobile is around 90%.
2, initially loading a page containing several compatible videos doesn't result in a major performance hit. Just try to load a TouchArcade page containing more than two or three videos in Opera Mobile and you'll see what I mean. Opera spends minutes loading it; SkyFire, on the other hand, only spends some seconds. Quite big a difference! (Note that the same stands for the Opera Mobile & Flash Lite vs. iPhone Safari relationship – the latter loads pages having a lot of directly embedded YouTube videos - like TouchArcade – in some seconds only. Yes, at times, not having true Flash Lite, “only” YouTube support pays off.)
3, video playback works just great on slow Pocket PC's; for example, ones based on 195 MHz TI OMAP CPU's like the HTC Wizard. The Opera Mobile + Flash Lite 3.1 is plain incapable of playing back any videos on this kind of a CPU without major stuttering and pauses.
However, particularly in not supported countries, the speed of the video playback will be much lower - between 4-5 fps (frame per second) and there will be times there won’t be any sound at all (and, if there is, it’ll be of worse quality than with direct, non-streaming playback like that of Flash Lite). While, on faster WinMo devices, Flash Lite 3.1 has no problems in playing them back at full speed - that is, 25-30 fps.
Fortunately, now SkyFire is accessible from all around the world – in the first few year of service, you could only register to it from the US and Canada.
1.3 Opera Mini 4.2.13337
Opera Mini, along with all Jbed versions (the MIDlet manager - that is, the execution environment - I recommend the most to be used with Opera Mini), offers a lot of goodies; for example, finger-based scrolling. It surely isn't as nice as Safari or Opera Mobile (there're no "rubberband", that is, inertia effects); however, the traditional strengths of Opera Mini (for example, the very low data traffic essential if you're on a limited cellular data subscription and Opera Link, which, unfortunately, is still not supported in the latest Opera Mobile versions) can easily make this browser the browser of choice.
For VGA users, I especially recommend the VGA-hacked Jbed 5.1 version; please see THIS for more info. For QVGA users, you can safely stick with older versions of Jbed.
Opera Mini behaved pretty nice in my tests - it zoomed into text very well and reflown the columns intelligently. No problems in here - much as it's "only" a Java MIDlet, it's still a very decent browser, particularly if you want to make use of its excellent (!) Opera Link and multitab capabilities.
Finally, note that, after my W3C speech, I've published a full tutorial on making Opera Mini your default system browser.
1.4 Iris 1.0.16 (1.1.0 b3)
This browser was another nice surprise - no wonder for example the MSMobiles folks liked it very much. While it's still lacking a bit here and there (the most important of them being the lack of keeping the previously zoomed-to screen contents horizontally aligned when finger-scrolling vertically), it can already be rightfully compared to the other browsers available on Windows Mobile. I, however, would still stick with Opera Mobile, SkyFire or Opera Mini (depending on your needs) instead - they're (still) superior.

1.5 Pre-6 Internet Explorer Mobile (IEM) with Spb Pocket Plus 4.0.2
Unfotunately, the "old" (but still the only built-in IEM version shipped with even the latest devices) Internet Explorer Mobile (IEM) is far inferior to anything else, even with the really decent, 4-series Spb Pocket Plus plug-in to allow for multitabbing and iPhone-like scrolling.
The biggest problem with this browser, along with the heavily outdated HTML / scripting engine, is the inability to dynamically zoom in/out to/from the page: to switch between reading some text (with sufficiently large and readable characters) in the zoomed-in state and the page overview. All the other browsers are capable of this via single or double taps on the selected (textual) area. (Yes, even Opera Mini - it's just that you can't use the same screentap(s) to switch back to zoomed-out, page overview mode but have to use the hardware Action button [if available] or a menu command to do so.)
Add the poor testpage rendering results to this (many times, you will need to switch to One Column mode very often to be able to make use of the entire screen estate), the comparatively slow page loading speed and you'll see why I don't recommend this browser at all.
1.6 Internet Explorer Mobile 6 (IEM6)
Unfortunately, the current version of IEM6 has turned out to be a real disaster. While it supports goodies like dynamic zooming (with screen taps) and built-in, rubberband-like finger scrolling, it is very slow (actually, much-much slower than even the previous, pre-6 IEM version(s)), its zoom-in capabilities are really bad (doesn't take advantage of the entire screen and, in addition, it uses really small characters, which can't be fixed) and, what is more, you can't even use the One Column mode to make it render properly.
All in all, stay away. This browser is pretty bad and, currently, not worth installing (which, currently, involves flashing an entire XDA-Devs or MoDaCo “cooked” ROM). Hope Microsoft does fix these issues before releasing a "real" version for OEM's to be included in their ROM's. Again, note that the current version of IEM6 most probably doesn’t represent the final version Microsoft releases some time. I’m absolutely sure they’ll for example include for example the “Use High Resolution” checkbox, which will make it possible to make it render large(r) fonts. That is, my “trashing” the current IEM6 doesn’t mean the final, official version will be this bad at all. The current version is definitely an early alpha.
1.7 NetFront (NF) 3.5.009 b729
NF has recently received screen dragging support. Unfortunately, it can barely be used as, as soon as you start to drag the screen, in most cases, the context menu is displayed. The situation is way worse than with other browsers also having a context menu (Opera Mobile etc.).
It has other problems too: compared to the, in this regard, best browsers (Opera Mobile / Mini, SkyFire and, of course, the really fast iPhone Safari), it is slow to load pages. Even screen orientation or view mode changes require (lengthy) page reloads, unlike with most other browsers (except for Opera Mini and SkyFire, which also reloads pages if you dynamically change your screen orientation).
All in all, I cannot recommend NetFront at all. There is simply no point in preferring it to the three most recommended browsers: Opera Mobile, SkyFire and Opera Mini.
2. The feature / comparison chart
It's available HERE. Make sure you open it in a maximized (F11 in all the three major Web browsers under Windows) Web browser window. Also use zoom in/out (Ctrl+mouse wheel on all the browsers; if you don't have a wheel, Shift + and - in Opera; Ctrl + and Ctrl - in both Mozilla / Firefox and IE) to avoid having to scroll the chart horizontally.
Explanation (and additional comments) of the chart:
2.1 Real-world rendering tests
The first part of the chart elaborates on rendering some forum engines, also with some that caused iPhone Safari some problems. Note that I've tested (and published) the results in both orientations because, at times, you'll want to prefer browsing in Portrait mode simply because most phones are easier to hold that way, particularly while walking / doing some physical exercise - or, if you have a phone / PDA with a screen that has issues like that of the Dell Axim x50v / x51v. I used the letter "L" to denote landscape and "P" the portrait orientation.
A very important note: I’ve evaluated the browsers based on their ability to render text with large, well-readable-even-when-commuting-or-walking characters (or, with character sizes that are well readable on 2.8” VGA or 3” WVGA screens like those of the HTC Diamond, HTC Diamond Pro or the S-E X1), NOT based on the overall rendering quality of the engine. That is, I’ve only given “Poor” to browsers that could render textual content with small characters, regardless of the overall quality and standards compliance of the engine.
This is why IEM6, which is plain incapable of rendering text with acceptable-sized, in general, got very bad marks. Nevertheless, the IEM6 engine isn’t THAT bad – it’s pretty much on par with, say, NetFront. That is, based on the “Poor” and “Unacceptable” marks I’ve given IEM6 in most cases, don’t think it is THAT bad. It’s currently bad for reading in circumstances where you do need considerably larger characters. If you have a (W)VGA phone (like the HP iPAQ 210, hx4700, the HTC Touch HD or the Athena with the 5” screen) with a large (at least 3.8”) screen AND you aren’t moving, you may find IEM6’s rendering quality just fine. (It’s another question IEM6, being just an alpha version, severely fails in many other areas: speed, capabilities etc.)
The first link takes you to a pretty problematic site with code not compatible with the zoom-in engine of any of the Web browsers (except for Mozilla / Firefox, which has no problems with zooming them in) - which is a major problem on higher-resolution, but not very large screen like the UXGA 15" or WUXGA 15.6" screens of high-end ThinkPad models. I've paid special attention to checking out how the browsers render the number of the post (it's in the upper right corner of every individual entry). As you can see (of the three most recommended browsers), Opera Mobile is the best to retain this - at least in Landscape mode, using automatic (non-manual) zoom and large char. Unfortunately, only the first part of this number is visible in Opera Mini (and only in Landscape), unless you switch to the more restrictive (albeit a bit more bandwidth-friendly) Mobile View mode (either the “Mobile View” context menu or in Settings) – then, it’ll show these numbers without problems. SkyFire fares the worst in this regard: it not only hides the number of the post, but also (in Landscape, part of) the date.
Other than these, I haven't found other problems related to zooming-in in order to display large characters (where it was at all possible - for example, the maximal size I could get was still very tiny with IEM6 and it was only by switching to the very restrictive One Column mode that I could get readably large chars with Iris.)
(Incidentally, you can easily make these forum pages work in the desktop Opera by just removing all occurrences of <div class="art_t"> [and the accompanying </div>] from the source. Nevertheless, the Opera / Microsoft folks could really look into this problem to make the non-Mozilla/Firefox folks' life easier that long for the ability to freely zoom in.)
The second link takes you to the Pocket PC Thoughts frontpage. I've chosen this page to one of the standard test pages because iPhone Safari severely fails at rendering the contents of this, otherwise, when it comes to the HTML source, very simple page: it uses relatively small characters you may not be able to read (particularly not while moving). In this regard, all of the Windows Mobile browsers behaved orders of magnitude better - except for, again, IEM6, which behaved far worse than anything else.
The third link points to a Thinkpads.com thread, where one of the posts contain a very long thread. iPhone's Safari fails at rendering these kinds of HTML pages without any advanced markup. Needless to say, zooming in (with pinching the screen) doesn't help either - Safari isn't as sophisticated as Opera Mobile, where the latest build already supports reflowing the text at any (manual) zoom level - not just automatic ones. IEM6, as usual, sucks really bad; with Iris, you again have to switch to the One Column mode, but even then the charsize may still turn out to be too low. Speaking of the most recommended three browsers, Opera Mini and SkyFire had no problems with fully taking advantage of the available screen estate (note that, in SkyFire, you can hide the address bar as is also explained in the "Full screen" row). Opera Mobile, in Landscape mode and using Large characters, only used the two-third of the screen on the left (and left the rest unused); this is why I only gave it a "Fair". Again, only using dynamic, automatic zooming; I haven't tested the text reflowing capabilities of b15233, used together by manual zoom fine-tuning, with this particular case. You might want to give it a try to see whether, then, you can use the entire screen estate or not - I bet you will.

The fourth link shows how the DPReview main page is rendered by default. As can you see, you will most probably want to use manual fine-tuned zooming with Opera Mobile so that the text fully fills in the entire screen estate. Alternatively, if you use the latest, b15233 build with the VGA hacks I've explained (or, straight the VGA version), you won't have problems with the zoom - the screenshots here have been made with the official, earlier 9.51b2 and not the latest b15233.
The fifth link takes you to the DPReview forum. The recommended browsers have no problems rendering this, not even with large characters. Iris, again, needs to be switched to the restrictive Column Mode and IEM6 uses uselessly small characters.
2.2 Scrolling-related tests
In the first test, Scrolling speed, I've elaborated on how quickly you can scroll and how much time it takes to display the text you've just scrolled to. The best and fastest browser is, in this regard, Safari; Opera Mobile and NetFront aren't much worse, though.
The second one, "Real rubberband and inertia", elaborates on whether the tested browser is able to measure the speed of your finger when the latter leaves the screen, and if the speed is above a certain threshold, the screen will continue to ‘roll' in the last direction of your finger when it lost contact with the screen. This is one of the best features of iPhone's user interface, and, of course, Safari. As you can see, of the three most recommended titles, neither Opera Mini nor SkyFire support this. Hope this will be later implemented.
"Does it try to keep the same horizontal position while scrolling?" lists whether a slight horizontal displacement while you quickly scroll up or down results in the screen content dragged to the left / right, which, then, may result in having to re-position the text column you were previously reading. As can clearly be seen, the two Operas (and, of course, Safari) are the least sensitive to this kind of error.
"Minimap? Quick positioning possible on it?" shows whether there's any kind of a minimap on the screen and whether it can be directly used to quickly change your zoomed-in position. In this regard, Iris is by far the best. Note that it's only the QVGA version of Opera Mobile b15233 that supports minimap (but, unfortunately, no quick positioning); the VGA version doesn't have this any more. However, you can add this back with some manual hacking, should the need arise.
Other scrolling issues: here, I listed the problems you may face during scrolling the web pages. NetFront has the biggest problems of all with displaying the context menu almost as soon as you start dragging. This makes NetFront almost useless for this kind of usage.
Manual (free) zooming?: in addition to the well-known automatic zoom (which has been elaborated on in the first section), some browsers also support freely zooming into any area of the screen. You may already seen this on the iPhone, where the two-finger "pinching" of the screen does exactly this - in not only Safari, but also a lot of other apps as well. Of the other solutions, Opera Mobile b15233's is by far the best because it allows you to use any zoom level: it'll always make sure the text is correctly re-flown in the given level. Unfortunately, this kind of functionality is really missing from Safari. Yes, this is one of the areas where Opera Mobile is way better than its iPhone alternative.
2.3 Input
This group examines the various input capabilities of the browsers.
Finger-friendly drop-down lists: if you've ever used Safari, you may have already noticed it has very nice and finger-friendly drop-down selector lists:
Here, I explained (and shown) how finger-friendly Windows Mobile browsers are. Unfortunately, none of them excel; probably the best are the two Opera browsers, but they're still a far cry away from iPhone's Safari. Note that if you have a D-pad, you can use the up/down arrows to move the selection and the Action button to select the current one, which, to a certain degree, provides a solution to this problem. Too bad some WinMo phones (for example, the Touch HD) don't even have a D-pad…
How does it work together with third party full screen keyboards?: as the built-in on-screen keyboard in Windows Mobile is almost impossible to use (even after switching to Large size in Settings / Input / Large Keys) with fingers, you may want to take a look at alternative, considerably bigger (or even full-screen ones) on-screen keyboards to allow for finger-based, stylus-less input. I've, in this regard, tested Spb's Full Screen Keyboard. It turned out to be working wonderfully with all browsers, the only exception being Opera Mobile 9.51b2, which always switched back to the standard keyboard on my iPAQ 210. Fortunately, I haven't run into the same problem with version b15233 any more.
2.4 Misc
This category, as you may have guessed, lists all the miscellaneous tests I didn't want to put in other categories.
Copy / paste: iPhone's Safari is heavily lacking copy/paste capabilities. In this regard, most WinMo web browsers are clearly better. Unfortunately, two (SkyFire and Opera Mini) of the three most recommended apps fail at this: they don't support copy/paste at all. (With Opera Mini, of course, you can still save the current page and, then, find and copy the given text from a simple text viewer like Total Commander.) As usual, with the other browsers, I've explained how you can switch to the text selection mode, as the default "screen dragging" mode, in general, needs to be disabled first.
Other goodies: I've listed some additional features I didn't want to create a separate row for: finding text in the current document (Iris, Opera Mini & Mobile, NetFront), Opera Link support etc. Unfortunately, SkyFire doesn't support finding in page - the only goodie it supports is image saving (also available with all the other browsers). Note that I haven’t listed all features of Opera Mobile: in addition to what the chart contains, it also supports sending image/links via MMS, SMS and E-mail. It even has a download manager that can even pause/resume a download – as has also been explained in my two-year-old article on downloading with Windows Mobile Web browsers.
DPReview top left menus: DPReview.com has a menu in the top left area none of the WinMo browsers can invoke subcategores of - unlike Safari. (An exception is Opera Mobile if you navigate over the main menu items with the D-pad - then, they don't get selected; still, their submenus are displayed, where you can already select anything. This means Touch HD users will need to use the custom onscreen keyboard displaying a virtual D-pad to fix this problem - not the cleanest solution...)
Page saving: the two Operas, Iris, NetFront and PIE, thanks to Spb Pocket Plus, are capable of saving the current page into the local file system. Unfortunately, the pretty barebone (but, still, excellent) Safari doesn't - neither does IEM6 (not that I'd recommend it to anyone) or SkyFire.
CPU usage: I've also benchmarked the CPU (and, consequently, the battery) usage of the tested apps (except for that of iPhone, as I don't know of anything like Windows Mobile's acbTaskMan for the iPhone. I may need to write it myself? After all, Unix does support getting the CPU usage of a given process.) NetFront has turned out to be buggy if and only if it's in the background. SkyFire has a continuous CPU usage: 40% while not doing anything (on the 624 MHz iPAQ 210). This may be quite much a stumbling block for many requiring as good a battery life as possible.
Dynamic zoom, only zooming into a given column: here, I elaborated on whether the browser supports the dynamic two-tap zooming in/out pioneered by Safari. The three most recommended titles work just great in this respect. Unfortunately, IEM6 has nothing comparable.
Clicks vs zooming: here, I explained how easy it is to click / activate links. With some browsers (for example, Iris), it's a bit harder to do this on most Windows Mobile phones, unlike you're using the D-pad and the action button to do this. Sometimes, you need to re-tap the same link some three or four times in order to activate it. This isn't an issue on the iPhone, where links do get activated at once.
Makes use of VGA?: as you can see, SkyFire will always use the 320*240 (QVGA) resolution to converse bandwidth, reduce the load on their servers and speed up screen rendering. This, unfortunately, results in a not-that-spectacular rendering quality on VGA screens. Opera Mobile's current Omnia b15233 rip, having come from a QVGA device, is VGA-unaware and, therefore, displays images (and, via Flash Lite 3.1, compatible videos) pixel-doubled, resulting in low-resolution images.
Quick(!) navigation to beginning of page: in cases, it might be very important to be able to navigate to the beginning of the page without having to waste some 10-20-30 seconds to continuously scroll everything up like mad. In this case, I've explained whether the browsers have a way of quickly doing this. As most current WinMo browsers (except for PIE, IEM6 and the non-native Opera Mini) no longer have a verticalscrollbar, this, in cases, may turn out to be very tedious. Of course, you can still avoid having to scroll all the way up by just reloading the page.

…end of page: unfortunately, getting to the bottom of a page can be even more tricky if a browser doesn't have a draggable scrollbar or hardware button / key shortcuts as simple page reloading won't help in this case. This can be a real pain in the butt if you want to quickly visit discussion threads where the (new) posts you'd like to see are at the bottom of the page.
A quick note: while the iPhone Safari supports quickly going to the top of the page, there's no support of doing the opposite, unfortunately.
Multitab/page: here, I explained whether the browser supports opening more than one tabs (windows) and, if it does, whether you can force the current link to be opened in that tab. The latter is really missing from the iPhone Safari. The fact that Safari always reloads the previous page when you tap the Back icon makes things even worse. Fortunately, it's still the fastest browser to download and render pages, even when compared to Pocket PC's that have an 1.5 times faster CPU, but still...
As you can see, of the WM web browsers that do support mutitabs (unfortunately, SkyFire isn't one of them; nevertheless, it's also very fast to reload previous pages as it just sends over the image of the current viewport to the phone, not that of the entire page), Opera Mobile lets the user to select whether the link should be opened in a new tab. Note that, by default, Opera Mobile only allows for 3 tabs; this, fortunately, can really easily be raised. Opera Mini should be also mentioned: it automatically opens the link in a new tab and only after opening 30 links (new tabs) does it start closing the previous ones.
Making use of memory : especially on memory-restricted devices (for example, most Windows Mobile devices only having 64Mbytes of RAM and running WM5 or later) and with browsers supporting multitabs can the memory consumption be of high importance.
Fortunately, the best (and most recommended) browsers (the two Operas and SkyFire) all have pretty low memory requirements, even with (with the first two) tons of tabs (web pages) open. Not so with Safari: in addition to it always reloading pages when you press Back, if you load a page in another tab, the Web page on the old one will be reloaded except when the page you loaded in the new tab was a small one.
Stability: as you may have heard, Safari's stability isn't the best: it often crashes, particularly upon loading large pages (for example, the comments at the old [before the recent switch] iPhone Dev-Team Blog). Yes, this is indeed the case, even with the latest, 2.2 firmware. Fortunately, it remembers (and quickly and automatically reloads after restarting it) the last page you were on - or the one before, so, this issue isn't that bad.
In general, I've found the stability of all the tested WinMo browsers significantly better than that of the Safari. Another thumbs up for using Windows Mobile for Web browsing. (Now, I can only hope there were WinMo phones with capacitive touchscreens not requiring any kind of physical force when scrolling or doing stuff!)
Flash support?: as has also been explained in my earlier articles (particularly the one on the Flash Lite 3.1 hack and in my Flash bible), you need Flash or Flash Lite support to play back (most) Web videos, play games etc. Safari, again, is really bad at this: all it offers is playing back most YouTube videos but doesn't support Google Video (and the other, less relevant ones like blip.tv and PornoTube) at all. (Note that not even its YouTube support is as full as that of Flash Lite 3.1. For example, THIS video can't be played back in Safari. Furthermore, it doesn't play back stereo videos in stereo like THIS either, which is played back without problems by Flash Lite 3.1).
As you can clearly see, the current, hacked Flash Lite 3.1 is only compatible with the latest (b15233) Opera Mobile version (but not the official 9.51b2) - and not on all devices. (It worked OK on my HTC Wizard and HP iPAQ 210 but not my HTC Universal with Tomal 8.5.) SkyFire supports even the latest, desktop Flash (as it's running on the central server) and PIE only supports the old and pretty much useless, full Adobe 6/7 plug-ins (and the even more useless Flash Lite 2). NetFront, unfortunately, isn't a tad better either because of its sub-par Flash engine, which is even worse than the native Pocket PC Adobe 7 support.
Full screen?: finally, I elaborate on whether the browsers can use the entire (full) screen estate. Most of them can; the two exceptions being Iris (which will always display the bottom bar) and iPhone's Safari.</p>
3. Verdict – will I switch back to WinMo from iPhone Safari?
As has already been mentioned, the three most recommended Windows Mobile browsers (Opera Mobile, Mini and SkyFire), generally, are more featureful, stable (no crashes) and compatible (see for example the PPCT or the ThinkPads test cases) than iPhone Safari. The latter, however, is definitely faster at both loading and scrolling pages than any of these browsers (unless you want to do some special kind of scrolling; for example, going straight to the end of a page, which is very easy in Opera Mini.) If you can live with WinMo browsers loading your pages slower, you may want to prefer them to the iPhone.
This was strictly about the software part. As far as the hardware is concerned (and my switching back to WinMo to browse the Web), the advantage of the capacitive touchscreen of the iPhone pretty much negates the software superiority of particularly Opera Mobile. It’s just far easier to scroll and control the iPhone Safari than any of the browsers on any(!) of my Pocket PC’s and Pocket PC phones. (I’ve, in this regard, tested the following Pocket PC’s with Opera Mobile 9.5: Dell Axim x51v, HTC Wizard and HP iPAQ hx4700 (all three with a high-quality, expensive [Brando] screen protector) and HP iPAQ 210 and the HTC Universal (both without a screen protector) so that I can have a picture of how each of these models, with varying force needed to make screen taps / drags registered, fare. (Yes, I did test at least Opera Mobile 9.5 on five different WinMo models and the rest of the browsers on at least one [mostly the iPAQ 210, except for IEM6, which, currently, is only available in flashable ROM images and not as freey installable CAB files] of them) It was painfully harder to scroll around a page on all(!) of them. While I have a screen protector on my iPhone 3G as well, even with it, it’s way easier to scroll around. In this regard, the Safari (that is, browsing the Web on the iPhone and not any of the current WinMo models) is simply unbeatable. (Note that I use the screen protectors that come with the Switcheasy Rebel cases; according to THIS thread, they’re Pure Reflects. They make screen taps just a little bit harder to register and make the surface a bit less slippery, meaning it’s a little bit harder to drag the screen with the screen protector on. Nevertheless, the touchscreen interface still remains orders of magnitude easier to use than any of resistive WinMo models I’ve ever tested or had.)
All in all, while I’d prefer using Opera Mobile on Windows Mobile because it’s more powerful and stable, the fact that scrolling around pages is way harder than on the iPhone, I’ll stick with the latter. I’m afraid I’ll only change my mind if and when Windows Mobile hardware manufacturers, at last, come up with real capacitive screens, as easy-to-use (even through screen protectors) than those of iPhones. Hope the Microsoft folks are listening…
If you "only" have a Windows Mobile device and, consequently, must select from the browsers available for the platform (and can't go for the iPhone instead), selecting the right one should be based on your personal preferences. In my opinion, Opera Mobile (particularly when backed up with Flash Lite 3.1) is the best. However, if you absolutely must have a browser that either supports Opera Link (Opera Mobile, currently, doesn’t) or have the lowest available data usage figures, go with Opera Mini. It’s not as spectacular as its big brother (there’s, for example, no copy/paste or “inertia” support) but still does what it’s meant to – and it’s free.
SkyFire is, on the other hand, a perfect choice if you have a QVGA device (or a VGA one, but the QVGA-resolution text / image rendering isn’t a problem), have an unlimited Internet subscription (its data usage is far higher than that of even Opera Mobile, let alone Opera Mini) and the much higher CPU usage (and, consequently, battery consumption) aren't an issue.

Very nice write up. Thanks a lot for all your hard work. This will make choosing a browser easier for many in the community.
I personally have used a combo of Opera Mobile and Mini and found that between the two I found most of my needs could be met.
Thanks again!

Thank you very much for these in-depth explanations.

UPDATE (01/05/2009 3:33 AM CET): I’ve cleaned up the article a little; for example, added a Verdict section. I've also very thoroughly explained the evaluation of the tested browsers largely reflects on how they're able to render text with large(r) characters, NOT the overall rendering fidelity / quality. After all, one of the main aims of this article is explaining which of these browsers can be used when you simply can't use small characters on a VGA screen because you're either moving, the screen physically is just too small (2.8...3") or you have bad eyesight. I’ve also added some explanation of why the current, “hacked” IEM6 version (hopefully) isn’t a representative of the final one Microsoft will release some day. (They have a lot of time bugfixing it and they too surely realize IEM6 is plain useless in many usage scenarios like the one requiring large(r) characters.)
There’s a frontpage of the article at WM Power User.

UPDATE (01/05/2009 4:26 AM CET) : MobilitySite frontpage

1. MSMobiles frontpage at http://msmobiles.com/news.php/7944.html
2. The MS folks have just published a (not very deep, but still worth checking out) roundup at http://blogs.msdn.com/windowsmobile...urvey-of-web-browsers-for-windows-mobile.aspx

Bolt Browser
In the family of the server-optimized/rendered browser like Opera Mini or Skyfire, there is a promising newbie: the J2ME-based Bolt Browser by Bitstream. Here is a preview of that (private beta) browser.

gaelynx said:
In the family of the server-optimized/rendered browser like Opera Mini or Skyfire, there is a promising newbie: the J2ME-based Bolt Browser by Bitstream. Here is a preview of that (private beta) browser.
Click to expand...
Click to collapse
Promising, but even scrolling is very slow (so far, tested on my Blackberry 8800). Mobile View also involves a lot of positioning at first, which is pretty annoying as, as has already been stated, scrolling itself is very slow.
Opera Mini is WAY faster (at scrolling around, including scrolling down)- at least on my BB. That is, it still needs a lot of work. For the time being, I'd prefer Opera Mini.

You have not mentioned UCWEB6 which is my browser of choice.

i currently have Opera. as soon as Fennec releases its public beta for there browser im switching (mozilla mobile)

And what about compatibility?
Nice job with this review.
However, I did come to your post looking for a choice for flash and frames and metaframes web pages, something that makes a lot of web-based services simply UNAVAILABLE in the current PDA browsers.
Something so "simple" as checking my terra web mail, is plain impossible either in the latest Opera or IE6 browsers. Not to mention many banking services.
Any suggestion on that particular limitation?
Regards.
Edit: Found some workaround in IE6 to set the browser to identify itself as a Desktop browser instead of PDA browser.
Also some frame rendering seems to work only every other time. Hyperlinks don't always show up or work properly.
And forget about finger browsing, of course. :-(

Wow, this is the kind of USABILITY-driven stuff I love!
Fantastic framing of the issue, description of the process, and clear identification of pros and cons. This thread rates a 10 out of 10 in terms of its focus on what is now driving touchscreen phones -- web browsing as though on a laptop.
This was strictly about the software part. As far as the hardware is concerned (and my switching back to WinMo to browse the Web), the advantage of the capacitive touchscreen of the iPhone pretty much negates the software superiority of particularly Opera Mobile. It’s just far easier to scroll and control the iPhone Safari than any of the browsers on any(!) of my Pocket PC’s and Pocket PC phones.... While I have a screen protector on my iPhone 3G as well, even with it, it’s way easier to scroll around. In this regard, the Safari (that is, browsing the Web on the iPhone and not any of the current WinMo models) is simply unbeatable. ..The touchscreen interface still remains orders of magnitude easier to use than any of resistive WinMo models I’ve ever tested or had.)
Click to expand...
Click to collapse
Fantastic!

Tried Fennec, its really slow on my HTC Touch Diamond

quicksite said:
Fantastic framing of the issue, description of the process, and clear identification of pros and cons. This thread rates a 10 out of 10 in terms of its focus on what is now driving touchscreen phones -- web browsing as though on a laptop.
Fantastic!
Click to expand...
Click to collapse
Thanks

kosmos5457 said:
Tried Fennec, its really slow on my HTC Touch Diamond
Click to expand...
Click to collapse
DOn't bother with Fennec. Remember the first alphas of Minimo? They were equally bad and buggy. Wait for half a year for a usable version to come out; in the meantime, use Opera Mini, Mobile, SkyFire or Bolt. (I'll review the latter very soon.)

REVIEW: New Windows Mobile Web browser "Dorothy"

A new Web browser, Dorothy, has been announced slightly more than two months ago.
I’ve waited until now so that I can give the developers some time to enhance it so that I can recommend it. Unfortunately, the (today) current version, 0.2.2, still only has files dating back to August. (Compare this to the frequency (in general, at least one per month) of updates arriving to the now-extinct Iris, which was also based on WebKit.)
As you may already have guessed: in its present incarnation, I in no way recommend the new browser. Going for Opera Mobile, Opera Mini 4.2 (not the beta-stage 5.0 - see my dedicated article HERE) with a decent MIDlet manager (refer to my MIDlet manager-related articles) or SkyFire is a much-much better choice. Of the three, you‘ll surely find the most useful. (For example, if Opera Mobile doesn’t really work on your phone – which, unfortunately, is the case with some models –, you still have two other, excellent browsers to choose from; if SkyFire’s using QVGA resolution only is unacceptable to you if you’re a VGA user, go for the other two browsers etc.)
(Note: I haven’t tested the brand new BOLT 1.5 yet so I don’t know whether it’s worth checking out and/or recommending. Some people – see Serola’s article - reported it isn’t at all bad.)
The problems with the current Dorothy version are as follows:
- Absolutely no support for tabs (both Opera Mobile and (via History) Mini support this)
- Absolutely no link / page / image context menus
- No text reflowing, unlike in all the three recommended browsers. This means your only way to make the text readable is zooming in (with the on-screen + and – icons in the lower right corner). Then, however, you’ll end up having to extensively scroll back and forward. All the decent browsers (not only the three most recommended ones, but also almost all WinMo-based ones – see THIS) are able to reflow text and/or switch to more mobile-friendly (for example One Column) views.
- There’s not even built-in favorite support. This also means you won’t have access to, for example, scriptlets, which can become life-savers with all scriptlet-capable Web browsers (even Internet Explorer Mobile) (latest, related article HERE)
- It seems to be incompatible with several WinMo PDA’s / phones. For example, on my HP iPAQ 210 standalone PDA (with the official ROM version it’s coming with and the “dummy” Phone and SMS DLL hacks in place so that both Jbed and SkyFire run on it), it constantly displayed a missing resource. On the other hand, it runs OK on my HTC Universal running WM 6.1.
- No full screen
All in all, it's much-much less usable than any of the recommended browsers. Even the built-in Internet Explorer Mobile is far better (full screen, context menus with goodies like image saving, reflowing, settable character size, different view modes including One Column, favorites etc.)
Getting it
If you would still want to give the browser a test ride: Register on the official homepage; after the account activation, you’ll be sent the link to the installable CAB archive.
Additional info
See THIS XDA-Devs thread.