You’ve installed a new application and, now, can’t boot in your Pocket PC? Ever wondered how you can boot into a Safe Mode similar to the desktop Windows Safe Mode to disable all third-party applications and services? Read this!

In the (highly recommended if you still haven't read it!) Safe Mode Bible, I’ve explained what Safe Mode applications there have been on the Pocket PC.

I've just updated the tutorial "Can I change the language a given Web page is requested by my Web browser on my Pocket PC?" with a newly-found Netfront 3.3 bug.

http://www.smartphonemag.com/blogs/index.php?blog=3&p=1255&more=1&c=1&tb=1&pb=1

Thanks to feedback I've received all around the Web, I've just posted a revised, updated edition of the today-published Safe Mode article ( http://www.smartphonemag.com/blogs/index.php?blog=3&p=1255&more=1&c=1&tb=1&pb=1 ).

1. A quick (executive) summary

If you don’t want to read the article in its entirety (I DO recommend the latter – it contains a LOT of never-before-published tips and plain English explanations of what is happening behind the scenes!), here’s what you should do:

1. depending on your preferences, get either Spb Pocket Plus or iLauncher, install it
2. if you encounter boot-in problems (the device wouldn’t boot after installing a new application and resetting the device), make sure you quickly (in less than one minute after the first reset attempt) reset the device so that the Safe Mode boot message is triggered and displayed
3. when the above-mentioned message is displayed, tap the screen area; Spb Pocket Plus / iLauncher will boot in Safe Mode
4. now, simply go to Settings/System/Remove Programs and remove the application
5. finally, click the “Reset” button on Spb Pocket Plus / iLauncher. It’ll reboot in the standard (non-safe) mode – now, without the offending application.

1.1 Non-bootable Pocket PC’s?

However much the Windows Mobile operating system is much safer than many desktop operating systems, there may be cases when things just go wrong and you just won’t be able to boot in: after resetting the device, it will just hang at the boot splash screen.

This is particularly true of cases when you install new software. There are some well-known software products (or unlucky combinations of them) that are bound to cause sometimes severe, reset-time problems. Just two of the well known “dangerous” cases:

1. some old(er) ThinkOutside StowAway drivers (for example, version 4.3) installed on some specific Pocket PC models (for example, the Fujitsu-Siemens Pocket Loox 720): after the (self)-reset upon installation, the device, in general (particularly if you don’t enable Bluetooth before starting the install), most probably just hangs and not even subsequent resets help in most cases.
2. trying to install the two great Pocket Internet Explorer / Internet Explorer Mobile plug-ins MultiIE and PIEPlus on the same time (not all the time, mostly when it’s not a clean device). In these cases, if you’re unlucky enough, the device is rendered unbootable and you will need to do a hard reset if there are no other chances to make it work again. (Note that alone these plug-ins cause no problems at all. Also note that this is the case with all the versions I’ve tested – even the latest ones.)

In this article, I explain how, with which applications you can fight all these problems. First, I provide a generic overview of the booting sequence of the Windows Mobile operating system so that you know where things can go wrong. Note that you don’t need to understand it: if you don’t, it’s no problem, you will still understand the rest of this article. However, it casts light on a lot of issues discussed in the article and, therefore, is highly recommended.

UPDATE (04/04/2007): some bad news for WM5 / WM6 users: while the driver memory shortage is indeed much less prevalent in WM5+ operating systems, it certainly exists.
(End of update.)

You may have already heard about the difference between driver memory (don’t confuse it with the ‘static’ storage memory!) and dynamic memory. The two have nothing to do with each other. That is, you can have even 100 Mbytes of free dynamic (program) memory while having no driver memory at all.

The shortage of the driver memory is very well known for many WM2003SE device users; for example, those of the Pocket Loox 720. On the Loox, upon (re)enabling Bluetooth, you often run into this error message complaining about the lack of the driver memory. Other, mostly WM2003SE (and, to a much lesser degree, WM2003) users have also run into this problem.

Some programs use more and some less driver memory. For example, the Widcomm Bluetooth stack in the Pocket Loox 720 and in the WM2003SE HP iPAQ hx2xxx series uses quite a lot of driver memory. Other applications that consume a lot of driver memory are, for example, Qmail, the great alternative E-mail application, the beta (past) versions of Opera Mobile, the best Web browser for the Pocket PC (the final, trial/commercial version released late May has much less driver memory usage), the also nice Web browser NetFront 3.2/3.3, Adobe Acrobat Reader 2.0, TextMaker and PlanMaker by Softmaker.

I’ve made a lot of tests today to find out whether the final, commercial, 3.3 version of the NetFront browser causes problems with other (DLL/driver) memory-intensive applications.

While working on my thorough tests and benchmarks, I’ve run into the fact that Adobe Reader 2.0 constantly consumes between 29 and 36% CPU cycles – independent of the application loaded and even when it’s idling in the background.

I’ve tested this on all of my test Pocket PC’s (F-S Pocket Loox 720 (WM2003SE), HP iPAQ h2210 (WM2003), hx4700 (WM5), Dell Axim x51v (WM5) and HTC Wizard (WM5)), some of

Over at the AximSite forums, AximSite user Vinman has mentioned having problems with a company website with the trial version of great Web browser NetFront 3.3, while Opera Mobile, the new browser star on the Pocket PC horizon, has no problems with the same page.

I’ve, consequently, thoroughly scrutinized the page source and found out the following: both the latest (1.06D2; that is, the trial) version of NetFront 3.3 and the built-in Pocket Internet Explorer / Internet Explorer Mobile (yes, this problem also affects the built-in IEM browser in WM5, the latest incarnation of the Windows Mobile operating system) are unable to use the JavaScript code document.forms[<form index>].<some element ID>.disabled = true|false to disable form fields.

(Incidentally, if you have problems with a specific Web page and your Pocket PC Web browser(s), don’t be afraid of contacting me. Telling me about bugs is highly advantageous for the entire Pocket PC community because, this way, we can force (and help) Web browser developers to identify and fix the problems. So far, I’ve been able to find all the browser bugs Pocket PC users have reported to me.)

A HTML/JS code snippet demonstrating this can be seen at the bottom of this article. Note that it’s also available online here – feel free to click the link and note that it does render a second dialog box if clicked from a capable Web browser – for example, the desktop IE6. In Opera Mobile 8.6, it’s working just great. NetFront 3.3, on the other hand, will only display the first JS dialog (please note that, in order to see this dialog, you do NOT need to enable pop-up windows with the (Menu/)Tools/Browser Setting/Dialog/Pop-up drop-down list!). The case is the same with PIE/IEM – it will only display the first dialog box as can be seen in here.

Unfortunately, the same stands for the alternative way of dynamically hiding HTML form fields described and demoed here (the embedded, dynamic HTML form is really worth checking out with both a desktop browser and the Pocket PC ones) – it’s only Opera Mobile that is able to dynamically hide/show form elements based on user input (see screenshot), PIE/IEM (see screenshot) and NetFront (see screenshot) don’t.

How can you, as an HTML author, avoid situations like this?

I've reported this bug some half a year ago on various PPC forums (and, later, the Windows Mobile Developer Team has also confirmed this to be a bug & filed it to the Bug Database). Because the importance of this bug and the problems it may cause, I think it's worth repeating it here:

If you enter text in Pocket Word, never try to enter the character sequence -> because, then, Pocket Word may crash at once, killing your current, unsaved work!

http://smartphonemag.com/forum/topic.asp?TOPIC_ID=20477

Here at the Pocket PC Mag forums, I've just been reported a strange bug affecting Pocket Internet Explorer (PIE for short). The problem is as follows: PIE is unable to download files from various Web sites, one of them being Caiman. Give it a quick try if interested: try to click the "*Download from caiman.us" link at the bottom of, say, this page in PIE and check out what is actually downloaded (either a 0 or a 7x-byte HTML error report). Then, try to do the same in either NetFront (I've tested this with both version 3.2 and 3.3 TP 1.03) and the beta version of Opera – they will both work, unlike PIE. Note that as far as the the two alternative PPC browsers, Thunderhawk 2.1 and Minimo 0.012 are concerned, the former has absolutely no download capabilities and the latter is (still) unable to download anything. Please note that this bug, again, will no only affect Caiman downloads but all Web servers that offer binary (downloadable) files and check the original home page address in the request! There're numerous pages like these: Caiman is just an example. Affected Windows Mobile/Pocket PC operating system versions I've tested WM2003SE (Pocket Loox 720), WM2003 (iPAQ 2210) and Pocket PC 2002 (iPAQ 3660). The built-in PIE in all these three operating systems suffer from the problem.

http://www.smartphonemag.com/forum/topic.asp?TOPIC_ID=20296

As I know quite a bit about TCP/IP protocols, including POP3 (I've, for example, (with some beans, "only" co-)authored several IBM AlphaWorks TCP/IP-related JavaBeans back in 2000-2001, including the POP3 bean), in my previous article on this problem (alternatives: iPAQ HQ, AximSite, PPCT, FirstLoox, BrightHand) and in other, related discussion threas (for example this one; I particularly recommend the Pocket PC Thoughts one), I've been promising to dive into probably the nastiest Pocket Inbox / Messaging bugs. Now that I had some free time to write a minimalistic POP3 server emulator to generate debugging-friendly mails for this purpose and could allocate some time for debugging, I'm proud to present the protocol-level description of and several solutions to the problem.