[General Topics] Menneisyys:
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.)