So, this is probably going to be a series of posts on why Windows Mobile sucks, from both an user and developer perspective… and I’ll try to explore exactly what Windows Mobile needs to do to survive as a platform – and if what Microsoft is doing in Windows Mobile 6.5 is enough. Some of the topics I’ll be covering include developer tools and user interface. We’ll start today with #1. Note that this isn’t really in any order of how bad the problems are – but rather, when they come to my mind. So let’s start!

Problem 1: .NET Compact Framework

Okay, a good idea in theory – the .NET framework is proven in both client and server-side applications, and unless you’re a masochistic developer – you would probably prefer programming with the .NET framework if it didn’t have any performance issues. Managed code makes the programmer’s life much easier – among other things, you get garbage collection, somewhat automatic exception handling, lots of libraries for accessing both operating system functions, containers, and common algorithms… the list goes on.

Managed code is run inside a virtual machine known as the common language runtime (CLR) – for those familiar with JAVA, the concept is very similar. Think of the CLR as a special machine which runs Common Intermediate Language (CIL) as its assembly code. When a .NET program is run on the CLR, the CLR does Just-In-Time compilation of CIL code to the native assembly language of the machine. The advantage of this idea if you write a program in CIL, you can run the program on any platform with the CLR on it – you don’t have to recompile your code each time. The programmer only needs to write their C#, VB.NET or other code and compile it to CIL that targets the CLR. This managed code seems like it would be great for a platform like Windows Mobile, that runs on a variety of architectures. In fact, I’m pretty sure Microsoft thought this would be the answer when PocketPC devices were running on a number of architectures, including MIPS, ARM and SH3/4… and programmers had to recompile their binaries for each architecture. Today, nearly all Windows Mobile devices run on ARM.

Of course, you might have guessed, running managed code, has its negatives. The biggest problem on embedded devices is the resource and performance hit that you take from starting this virtual machine. If you’ve ever run a .NET program on Windows Mobile, you probably noticed it took 5-10 seconds for the program to start… during which you are presented with the annoying Windows Mobile wait cursor. This is the CLR taking the time to load up – which needs to be started for any .NET program that runs. After the CLR loads, performance is typically acceptable for non-processor-intensive applications. The problem here is that a 5-10 second load time is unacceptable for a mobile device. Windows Mobile users are probably all too familiar with how long it takes for the built-in calculator to startup. The built-in calculator is written in .NET! The 5-10 second startup time pretty much makes the calculator unusable for what its meant for – making quick calculations. I can’t tell you how many times I needed to do something like calculate the tip I needed to pay – only to be frustrated and outpaced by someone else with a “dumbphone”. The thing is – most applications on a mobile phone are meant for doing something quickly. Taking a long time to load up really takes away from the mobile phone “experience”.

Another problem is operability with native code. Many core Windows Mobile features, such a Today plugins, extensibility, chome, etc. Must be written in native code. But what if you want to use managed code from native code? This is something you might be able to do from a desktop computer, but the .NET compact framework doesn’t allow calling managed code from native code. Other problems include random functions not included in the .NET compact framework, and strange window handling behavior when using the UI editor – but we’ll skip over those for now.

Is the .NET framework a big step up over JAVA? Although I prefer C# myself, I would have to say that it is not – at least on embedded devices. Most modern Windows Mobile devices contain an ARM core that features Jazelle technology, which does hardware optimization of JAVA bytecode. Its unfortunate that we don’t have the same hardware optimization of .NET code. The main attracting factor to .NET though, are the Windows Mobile libraries that let a programmer easily work with Windows Mobile features that are difficult, if not undocumented – to work with natively.

So why is this such a big problem with Windows Mobile devices? It seems that it is more of a problem with the Compact Framework. The problem is that Microsoft encourages development of .NET applications on Windows Mobile, even though – in my opinion it is really only appropriate for prototyping and maybe some applications where some of the built-in libraries would be immensely useful. It is not appropriate for production applications. I guess you could say that it is nice that we have something like the .NET compact framework – but it should only be used when appropriate.

The next post in this series will probably cover the Windows Mobile SDK and how it compares horribly to other mobile phone SDKs.

Approximately six users may have been affected with a bug in the donator CP that caused their passwords to be invalid. I upgraded the security on some parts of my system, and these users created accounts during the upgrade. If you are experiencing this problem, reset your password using the password reset form:

http://www.nuerom.com/nueDonate/forgot.aspx

The site no longer stores your password and uses a password hash + salt instead, so instead of being e-mailed back your password, you get a token to reset your password instead.

I also changed the “log in” link on the top of the site, I guess it was causing confusion for some as it logged users into my blog instead of the donator CP.

nueROM3 6150-pre2 is available via the donator CP.

Some of the changes include a fix to the reply all, the moving SIP (thanks verizonguy @ ppcgeeks). Thanks to LennySH and the PPCKitchen crew for build 20748.

6150-pre2 introduces nueKernel, a new feature that allows you to switch between high memory (camera disabled) and low memory (camera enabled) as well as change your pagepool straight from your titan. The setting is written to a special section of your flash rom, so the setting will persist between ROM flashes, as long as you flash a ROM with nueKernel. It is recommended that you NOT change the pagepool on the rom with an external tool such as PagePool changer.

nueCPL-performance is also included. Due to low bandwidth here, the baseKit will be uploaded in a few hours. The Titan camera is included by default. To use the vogue camera, drop the package in and rename the camera “HTCCamera.exe” and use the “Camera.exe” from the Titan package.

nueROM services is ready for test. If you have donated, you can create a new account at http://www.nuerom.com/nueDonate/. Click on Don't have an account, and enter the e-mail address you donated with to create an account. If you donated with multiple e-mail addresses, you can associate the other e-mail addresses in the control panel. Currently, you can only submit trouble tickets, I hope to have the download repository working soon with stuff to download.

A few people asked me where to get the sliding sounds (Synthetic, Mechanical, Sword) that were in pre8. The sliding sounds are from a HTC Raphael ROM, and I’ve posted both OEM packages and cabs with the sound here. You don’t need nueSlidingKB to get them to work. I’ve also posted nueSlidingKB, and several other tools are going up.

For reference, if you wanted to add your own sounds, you would add registry entries such as:

[HKEY_LOCAL_MACHINE\Software\HTC\SlidingSound\NUMBER]
@="My Sound"
"in"="soundin.wav"
"out"="soundout.wav"

Where number is a integer from 0-99, “My Sound” is the name of the sound you want to add, and soundin.wav/soundout.wav are the sliding in and out sounds, respectively.

I just finished writing the custom download script - nueSPL is now posted, and several nueTools should be coming soon in OEM and CAB format. Hopefully this will make it easier for people to find stuff.

Also, access via http://nuerom.com has been fixed, thanks turbofool for pointing that out.

After getting some backend stuff set up, I thought it would be a good idea to discuss why nueROM is moving to the new format as a test. There are several reasons we are moving to this new format.

• PPCGeeks.com has been a great home for nueROM so far, but  the forum thread-based format makes management difficult. Even though I was granted the honor of moderator status at PPCGeeks, shifting through bug reports and feedback was still a difficult task.
  
• Threaded discussions weren’t the best format for posting about nueTools, as small tools would frequently just end up being pushed back several pages, and I would continue to get e-mails asking about where to find them.
  
• The ftp site based hosting is still great for small project, but with the number of builds nueROM goes through, it becomes difficult to manage. Even with mirroring offers, it still wasn’t the best setup.
  
  

Hello,

After several days of setting up new scripts and getting new infrastructure set up, we finally have a new site up and running. I apologize in advance for the rather generic looking theme, hopefully a new and better looking theme will be up shortly.

This site is meant to be the new hub for nueROM development as well as nueTools. Over the next few days, you’ll see the site slowly populated with content, and eventually, an updated copy of nueROM 2.2.