nueROM

Where the WidgetAPI stores values; Problems with WM Marketplace

no2chem — Sun, 21 Jun 2009 22:09:01 -1200

It’s really a shame that Microsoft doesn’t document the widget API any better than it currently does. It actually has quite a bit of potential as a platform, but I’m sure developers find it problematic that the documentation is sparse, and debugging facilities are practically nonexistent.

There is a short document on MSDN, here for those who want to get started. One small problem though. Microsoft Windows® Mobile Marketplace, the place where these widgets are supposed to be distributed will charge a hefty price for developers to publish on it. I guess I didn’t really read the terms that carefully before and assumed that Microsoft would have put their terms to be competitive with the iPhone SDK. It turns out that Microsoft is charging a 99$ application fee and 99$ per application, which in my opinion is a total deal breaker. If Microsoft wants WM to survive as a platform, they probably should make marketplace – a place where free apps can be distributed as well as pay apps – and I doubt too many developers will be willing to shell out that fee. I was for a time considering distributing apps on Marketplace, but sorry Microsoft, you’ve lost my vote on Marketplace … I’m not even going to bother anymore. Sure, they’re running a “limited time promotion” – five free apps with your $99 application fee, but come on Microsoft, as big of a software giant you are, your infrastructure for software distribution is currently worse than Apple’s, which means you should be offering better terms than Apple - Apple charges only a $99 application fee, and no per application fee. Honestly, which developer is going to put their free apps on Marketplace for 99$ out of their own pocket? If Microsoft were to do this right, they would have offered a $50 application fee and no per application fee to attract developers. It’s almost like Microsoft just wants Windows Mobile to die… I’m not even going to get started on how Windows® Mobile Marketplace is not available on versions of Windows Mobile prior to 6.5.

About the WidgetAPI, you can find the values in:
[HKLM\Software\Microsoft\Shell\Widgets\Settings\”number of your widget”]

Where you’ll find the key/value pairs of your applications in plaintext. Guess there’s not much you can do about saving passwords in widgets, except warning the user that they will be stored in plaintext.

CDMA audio codecs

no2chem — Fri, 19 Jun 2009 19:46:16 -1200

It’s been awhile since I’ve played with QPST, but there are several interesting codec settings I didn’t notice before:

EVRC is an old audio codec.. more than 10 years old, (I think its circa 1995). I guess old standards live long… although it seems to me that the newer equipment that carriers have been putting in should support the newer standard, after all – these new codecs are designed to be both higher quality and more efficient. I haven’t done much testing on it, but I think I can say that Sprint seems to have SMV at least enabled and working – it seems that SMV gets better audio quality and clarity vs EVRC. 4GV is Qualcomm’s newest codec – so I’m not sure if the support is there. 4GV comes in two formats, NB (Narrowband) and WB (Wideband). I’m guessing WB gives better quality at the cost of bandwidth. You can set these settings in QPST, if you have the phone’s SPC code. Hopefully someone with a better ear for quality can test and try this out, and maybe report the results.

More ImageUpdate

no2chem — Thu, 18 Jun 2009 15:23:01 -1200

I’ve spent quite a bit of ImageUpdate the last few days – many hours on ImageUpdate. I did manage to find out:

1. Module –> MNGE conversion is not working perfectly
The current tools for converting modules to the flat MNGE file format need to be updated before we can use ImageUpdate to work with modules.

2. A GSM Kernel will boot on CDMA phones
In a desperate attempt to figure out why one of my packages wouldn’t work, I put uldr from a GSM Raphael on my Diamond. Guess what? It booted, past the splash screen, but reset soon after.

3. Packages without modules are easy.
I’ve written several tools to automate the generation of .cab.pkg files, including tools to change certificates in DSMs. Once everything is done, I’ll have it packaged up and posted shortly.

ImageUpdate workings, with videos!

no2chem — Tue, 16 Jun 2009 17:39:08 -1200

After a lot of work and collaboration with Da_G, I was able to get some custom imageupdate packages working with the CDMA Touch Diamond (results should port easily to other CDMA devices). The first video (sorry its flipped, I can’t figure out how to rotate it, and I took it on the touch pro) below shows installing a ImageUpdate package (simple.cab.pkg). In this case, we simply copy the package file via activesync to the device and run it. ImageUpdate first runs ImageValidator, which among other things, checks if the update was already installed to the device, and if the certificate matches one of the certificates located in defaultcerts.dat. Once verified, ImageValidator sets the flag to boot into the uldr partition, and runs uldr from there. Uldr is basically a special, minimal build of CE 5.0, you can see that the “dirty” display driver is being used with the occasional lines present on the screen. Uldr handles updating the imgfs partition, moving and relocating modules, etc. Finally, the device boots back to WM, where we are presented with a screen indicating the update was successful.

ImageUpdate for CDMA Touch Diamond Part 1

Part 2 shows the device being hard reset. After a hard reset, we try to install the package again, but the update fails because it has already been applied.

ImageUpdate for CDMA Touch Diamond Part 2

Before we get too excited, its important to note that there are some quirks that will hold us back a little bit.. First, kitchens cannot be used to generate uldr compatible images (this is why I am running a near-stockish ROM). The reason is that nearly all kitchens today delete the package manifest (.sof) and relocation sections, which are required by the update mechanism. Second, imgfstools in “bigstorage” mode will reduce the size of imgfs so that updates are not possible. Running imgfstools in conservative mode helps, but we’ll probably have to fine tune the memory allocation so that we have a good compromise of “updateable space” and user storage. Finally, .cab.pkg files aren’t the easiest thing to generate, but Da_G tells me a bit of people at xda-devs are already on the job. Da_G has a working ImageUpdate ROM for the GSM Raphael… I plan to follow suit with a CDMA version.

Once ImageUpdate is ready, ROM kitchens (at least by the masses) will be a thing of the past – most users will download a minimal “reference” ROM, and update their ROM to their liking using the imageupdate mechanism. Maybe Microsoft will even begin distributing updates via WindowsUpdate as well!

TouchPro2 nueBatteryDriver

no2chem — Tue, 16 Jun 2009 12:29:54 -1200

Special thanks to Chainfire, I’ve patched the battery.dll driver from the GSM Touch Pro 2 (EU) to 1% increments. It’s untested, so use at your own risk. At this time, you’ll have to install the driver into a ROM. If there is interest, I’ll add fastcharge to this driver as well.

Download: http://www.nuerom.com/BlogEngine/page/nuePowernueBattery.aspx

ImageUpdate, CompositeFn

no2chem — Mon, 15 Jun 2009 08:28:40 -1200

The reason I’ve been holding back on a new release of nueROM is that I’ve been trying to figure out how to work the ImageUpdate system. This system would allow updating the ROM without flashing… curiously, the mechanism for the system has been there since at least WM5, so I’m not sure why its not used by HTC. Anyway, I’ve recently talked to Da_G over at XDA, who has done quite a bit of research on this, and managed to pull off a “updateable” ROM for GSM users. There are currently some hurdles in getting the ROM working for CDMA users, but, I’m sure we’ll get around those hurdles soon.

You can take a look at Da_G’s progress here: http://forum.xda-developers.com/showthread.php?t=520009

I’ve also successfully compiled the USB Composite Function driver from Windows CE 6.0 to Windows Mobile 6.x. If I can get it working, we would be able to use both mass storage, activesync and InternetSharing at the same time. Only one minor problem: using this function driver requires the recompilation of the USBClientDriver PDD (probably known to you as msm7500usbfnhs.dll or msm7500usbfn.dll) as well as all usb client drivers (rndisfn.dll, usbmsfn.dll, etc), so it might be a little bit more work than I previously thought. Still, definite progress. =)

back!

no2chem — Sun, 14 Jun 2009 16:08:16 -1200

I’ve been gone for about 2 weeks due to the culmination of studying for finals, graduation and various graduation festivities. I’m back to working on my projects now that I have some free time, and will probably catch up on my e-mail as well.

Oh, and I forgot to mention – I did an interview with thestumblebum.com a while back, you can find the post here: http://www.thestumblebum.com/2009/06/no2chem-interview/

Now, back to coding!

strcmp profiling, v6 optimized routines

no2chem — Tue, 02 Jun 2009 11:28:04 -1200

I was taking a look at some coredll routines when I realized that many of these routines come from an outdated C library. I looked around for some updated routines, and I found faster routines in Linux and in RVCT (RealView compilation tool, now owned by ARM). The routines in Linux are actually pretty much the same as in CE 6.0, so I guess Microsoft never updated the CE 5.0 routines to newer optimized ones. RealView's strcmp used new v6 SIMD instructions (namely, UQSUB8). I decided to test each routine out to see how well it performed. I tested 1 million iterations of strcmp() against 10 twenty-six character comparisons with a mix of identical, mismatch at end, and mismatch at beginning strings. The results are in the standard Excel spreadsheet below:

The ARMv6 instructions used by RVCT had the clear advantage here. While a 29% performance increase is impressive, this only applies to strcmp. However, updating the C library should have clear benefits as nearly all Windows Mobile applications use the library, and this would be a rapid way to increase performance across the board.

Another side thing to note is that strcmp isn’t actually used that much in Windows Mobile, the wide character version, wcscmp is usually used instead – maybe profiling that is next. However, it appears there are newer versions of that and many other functions as well. What we’ll need is an automated way to update the C libraries in coredll…

nueGxDMA

no2chem — Tue, 02 Jun 2009 01:41:10 -1200

I know I’ve been taking a bit of a break from PPC development – I have exams and other end-of-the-academic-year related stuff to take care of for the next two weeks, so expect a slowdown until I have all that taken care of. I did manage to start on a new project that encompasses rewriting several drivers, I started simple, rewriting the GxDMA.dll driver which is essentially a wrapper to some functions in DDI.dll. The dll has 3 exports, DmaDRAMtoVRAM, DmaVRAMtoDRAM and IsDMAReady. These are all found in the GxDMA class, located in the PrimGPE class – you can get an instance of the object by calling GetPrimaryGPE() in DDI. The class looks something like this:

class GxDMA
{
public:
		GxDMA();
		virtual DWORD DmaDRAMtoVRAM(DWORD dwLeft, DWORD dwTop, DWORD dwWidth, DWORD dwHeight);
		virtual DWORD DmaVRAMtoDRAM(DWORD dwLeft, DWORD dwTop, DWORD dwWidth, DWORD dwHeight);
		virtual BOOL IsDMAReady(DWORD dwSrcAddr);
};

I made some small optimizations, taking out a useless sanity check and returning true immediately for IsDMAReady (it seems that GxDMA::IsDMAReady() also just returns true). Source code to be available when I understand more of this stuff.

Download: nueDriverProject

Site Downtime

no2chem — Thu, 28 May 2009 17:37:10 -1200

Hi, I just got back a bit ago from tests and a nap, and it seems like the site has been down for the whole day. Apparently this was due to a botched update on my hosts side, and my DNS/SMTP server is not functional. I’ve pointed DNS again at temporary servers, so it should be working for now… You might need to resend any e-mail though. Sorry for any inconvenience this might have caused.