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)