Relocate .NET Compact Framework 2.0 to your storage card: free up 5.4 Mbytes of precious internal storage! A never before publis
UPDATE (06/06/2006): In the meantime, .NET Compact Framework Version 2.0 SP1 Beta has been released. It supports installation to storage cards; the main storage usage, then, remains at about 1M.
The standard installer is available at http://www.microsoft.com/downloads/details.aspx?familyid=6548dd53-a418-42d9-a481-19ba3ceca1a6&displaylang=en . I've made the individual CAB files (so that you don't need to download he entire installation package) available at http://www.winmobiletech.com/sekalaiset/CF2SP1/ .
You should prefer using it to the standard, "old" CF2 so that you can avoid the laborous relocation.
For historical reasons, I still keep the original article, which is as follows:
One of the biggest complaints with Microsoft's Compact Framework 2 (CF2 for short) (and, consequently, with programs relying on it - Hitchhiker, SMS Notifier, Webby, IBE Mail etc.) has always been its storage needs, which, by default, is some 5.4 Mbytes. See for example this thread for users' opinions on the memory consumption on CF2 and their subsequent not wanting to install it.
I've always tried to reduce the main memory load on Pocket PC - with great success. Just search for the word-start "relocat" in the Pocket PC Magazine Expert Blog and on my old homepage for some examples of them. No wonder I've also decided to look into this, so far, unsolved problem to greatly help my fellow Pocket PC users. And, after a day's work and testing, I can present you a 100% working solution, which has been thoroughly tested on four of my WM2003+ PDA's, all with success. This IS a big thing, considering that internal memory is still precious, even with most Windows Mobile 5 (WM5) Pocket PC's. (For example, most WM5 PPC's are shipped with 128M of ROM, of which in general 40-45 Mbytes is free.) The situation is even worse with pre-WM5 Pocket PC's, where the available RAM is very rarely (only with devices shipped with 128 Mbytes of RAM) over 50 Mbytes, from which CF2 takes away 5.4 Mbytes.
Note that this will work on all Pocket PC and Pocket PC Phone Edition devices that are able to run CF2 (that is, all WM2003+ devices, including WM5).
The complete tutorial
- create a directory on your storage card or, if you have, in the built-in File Store. (Note that the files, as they are surely not needed at boot time (unlike some Today plug-in DLL's), may also be relocated to a storage card. That is, they don't need to be stored in the more scarce File Store - if it's available at all; that is, if you have a pre-WM5 device). Let's assume you give this directory the name "DLLs".
- move the following files from \Windows to this directory:
cgacutil.exe
MSCOREE2_0.dll
netcfagl2_0.dll
netcfd3dm2_0.dll
GAC_CustomMarshalers_v2_0_0_0_cneutral_1.dll
GAC_Microsoft.VisualBasic_v8_0_0_0_cneutral_1.dll
GAC_Microsoft.WindowsCE.Forms_v2_0_0_0_cneutral_1.dll
GAC_Microsoft.WindowsMobile.DirectX_v2_0_0_0_cneutral_1.dll
GAC_mscorlib_v2_0_0_0_cneutral_1.dll
GAC_System.Data_v2_0_0_0_cneutral_1.dll
GAC_System.Drawing_v2_0_0_0_cneutral_1.dll
GAC_System.Messaging_v2_0_0_0_cneutral_1.dll
GAC_System.Net.IrDA_v2_0_0_0_cneutral_1.dll
GAC_System.Web.Services_v2_0_0_0_cneutral_1.dll
GAC_System.Windows.Forms.DataGrid_v2_0_0_0_cneutral_1.dll
GAC_System.Windows.Forms_v2_0_0_0_cneutral_1.dll
GAC_System.Xml_v2_0_0_0_cneutral_1.dll
GAC_System_v2_0_0_0_cneutral_1.dll(netcf2_0license.txt can also be copied here - or just deleted.)
This means only Microsoft .NET CF 2.0.GAC and mscoree.dll needs to stay in \Windows. Never ever try to touch the former (Microsoft .NET CF 2.0.GAC). Even if you copy it back to \Windows (after starting any CF2-dependent app), CF2 won't work again until you reinstall it.
Copying the files can be done in several ways, of which I show the one way that requires no third-party apps, that is, without having to resort to, for example, the WindowsCE File System plug-in of the desktop-based Total Commander.
Start the built-in (Pocket) File Explorer and navigate to \Windows. Tap and hold an empty (not highlighting any file or directory) region anywhere (for example, the end of the list) and enable "View All files" in the context menu:

Now, click the "Name" drop-down menu in the upper right corner; a "Sort By" list will be displayed, defaulting to "Name". Switch it to "Date":

Scroll to the region with filedates of Aug 26 and, with cgacutil.exe, 27, 2005 (this is the easiest way to find the files) and mass-highlight all files that are listed in the above list. Note that mscoree.dll should not be highlighted (as has been pointed out, it should be left in \Windows). Also note that the filedates of the current, 2.0 version of CF2 are all dated at Aug 26/27 last year. They will only have a different filedate if you've restored them from a backup. Then, they will have the timestamp of the restoration and you'll may end up having to hunting for them one-by-one, based on their name.

Now tap-and-hold the selection somewhere so that the context menu comes up. Choose Cut:

Go to the target directory (in this case, DLLs on your storage card); tap-and-hold an empty area and choose Paste:

The transfer of the files will start:

Note that you can also use other file handler tools on the Pocket PC; for example Resco File Explorer or Total Commander. In Resco, go to File/Options/Browser and make sure "Show all files" is chosen (instead of the default "Hide hidden files and files...") as can be seen in this screenshot.
- get a registry editor that is able to (flawlessly (!)) edit multiline strings (that is, all known, up-to-date registry editors except PHM Registry Editor and Total Commander; please check out The Ultimate Roundup of Registry Editors for the Pocket PC for a thorough explanation of why I don't recommend these two applications if interested). In this tutorial, I use Resco Registry Editor (Resco for short). It's commercial, but the 14-day, unrestricted trial version is fully sufficient for our purposes. Start it.
- First, we'll modify the so-called "System Path" (which is a bit similar to the PATH in traditional operating systems) so that it includes our new directory. To do this, go to HKEY_LOCAL_MACHINE\Loader:

Note that, in here, I've switched to "Tree Mode" in View/Show Tree View as can be seen in here.
Now, click SystemPath (highlighted in this screenshot); you'll be presented the following dialog:

Note that there may be some values already in the text input area in here. For example, if you've ever had SKTools or MemMaid relocate DLL's for you, the target directory will be in here. Also, by default (if you haven't ever touched the System Path), there may be a \Release\ or \windows\oem\ in here. These can be safely deleted as they're not used. You can, naturally, leave them in there; of course, then, you must make sure the new path is entered in a new row as can be seen in this x51v or this HTC Wizard (latest Qtek ROM) screenshot. Once again: you can safely delete them.
All you have to do is entering the full path of your new DLL directory in here. For example, if you've moved the CF2 files to a directory named DLLs on your storage card named CF-Card (Storage Card, CF Card, SD Card, SD-MMCard are also widely used), enter
\CF-Card\DLLs\
in here, as can also be seen in here:

Don't forget to add the leading and the trailing backslash characters (\)!
Now, click OK in the upper right corner and answer Yes:

In the list view, the new, just-entered value should be shown as can be seen in here:

Note that, again, if you want to keep the previous values of System Path, then, the new entry should be put in a separate row. For example, if the previous value of HKEY_LOCAL_MACHINE\Loader has been
\SD-MMCard\Programs\CrEme\bin\
\LOOXstore\DLLs\then, you need to add the new value in a new row as can be seen in here:

- now comes a bit more complicated part. First, go to HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETCompactFramework\ Installer\ Assemblies\ Global.
Note that, on some devices, in the above path, SOFTWARE may not (all) be uppercase. This varies from model to model and shouldn't be paid attention to. (Also note that I’ve added spaces after every backslash characters (\) in the above registry path so that the blog engine nicely renders it. In the reality, it should not contain any spaces!)
Here, look for names (on the left) that have 2.0 in them. Note that almost all values (except for CustomMarshalers, Microsoft.WindowsMobile.DirectX and Microsoft.WindowsMobile.DirectX, which have all been introduced in CF2 and didn't exist in CF 1.x) seem to be duplicated and their name will start with the same (Microsoft.*, mscorlib.*, System* etc.); it's only after this that they start to be different. One set of them will continue in Version=1.0, the other set will continue in Version=2.0. The only exception from this "must contain Version=2.0" law is the value starting with "Microsoft.VisualBasic, Version=8.0.0.0" (that is, 8.0 instead of 2.0).
In all these Version=2.0 values, you'll need to modify the original path referring to \Windows to the new home of the relocated files - for example, in our case, \CF-Card\DLLs.
In order to be able to see this as easily as possible, enabling Show Header in the View menu is highly recommended, as can be seen in here. Then, you'll be able to greatly increase the displayed length of the value names if you drag the header to the right. Of course, switching to Landscape and/or VGA mode (if possible) is highly recommended. Then, you'll be able to see the version number in all the values. For example, this screenshot shows a QVGA WM5 device in Landscape - here, it's also possible to increase the width of the "Name" column so that the version number can also be seen without having to click every value.
All you need to do is just click all the values that have Version=2.0 in their name (except, as has already been pointed out, the 8.0 Microsoft.VisualBasic) and just change \Windows to the new value in the first row. An example of this:
before:

after:

Another example of a changed value (WM5, QVGA device, with files relocated to \Storage Card\_):

and with the VGA x51v in standard VGA mode:

Note that, much as it refers to the main storage (\Program Files\.NET CF 2.0\), you don't need to pay attention to the second row in all these values. Just leave them there.
Consider using a PC-based Pocket PC controller tool to do this (please read this article for more info on them if not sure). Using them, you can speed up the registry modification by orders of magnitude, particularly if you use copy/paste to insert the new directory path.
After you've modified all the affected values, check once more if it was successful. Fortunately, you'll see all the names (showing that a given value is 2.0-specific) and values (showing whether it refers to the original \Windows directory in the main storage or somewhere else) on the same screen as in this screenshot.
You may also want to export the just-modified branch to a registry (.reg) file. Then, in case you reinstall CF2 and want to avoid hand-editing the entire stuff, you'll only need to reimport this file. To do this, tap-and-hold Globals in the upper, tree pane and choose Export:

On WM5 devices, you will also want to make sure the changes are flushed back to the ROM (as the Registry is kept in RAM and changes are rarely flushed back to ROM, which will result in a simple soft reset getting rid of all changes and, therefore, CF2 not working after the relocation). To do this, on many WM5 devices (like the HTC Wizard), just long-press the Power button. On some other devices, you must explicitly configure the device to shut the PDA completely down upon a long-press (instead of just dimming the screen). For example, on the x51v, you must go to Settings/System/Power/Power Button and enable "Full power off" instead of the default "Dim/light the display" as can be seen in this screenshot. You'll only need to power off your PDA for some seconds because it's before shutting it down that the Registry is flushed back to the ROM; that is, you can safely switch it back on instantly.
Congratulations! Now, the relocated CF2 will be working! If you've modified the System Path, you'll need to reboot; otherwise, you can start your CF2 apps right away.
Advanced remarks for geeks/advanced hackers
- Exporting, editing and re-importing the contents of HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETCompactFramework\ Installer\ Assemblies\ Global (so that you can much easier change all occurrences of \Windows to the new path) just won't work because the values in here are multiline strings, which are exported as hexadecimal values by all export-capable Pocket PC-based registry editors (I've checked this!) like in here:

- The \Windows paths in HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETCompactFramework\ Installer\ Assemblies\ Reference (note that the last word is Reference, not Global!) don't need to be modified. Actually, you can even get rid of the entire subkey because it's not used at all.
- Technically, the GAC*.dll files don't need to be in the System Path; it's only with the other files (cgacutil.exe, MSCOREE2_0.dll, netcfagl2_0.dll and netcfd3dm2_0.dll) that must be. That if, you have already set up a relocated DLL directory somewhere in the System Path, you can safely move the files to there. It's in order to be as easy as possible for a novice user that I've instructed copying all relocated files to the same directory in the System Path.
- Login or Register to post comments
Printer-friendly version




This is a great fix to a common problem. Thank you for the real hard work in isolating the changes required and implimenting them so thoroughly.
eVB can be relocated much easier - it's just that you need to get the latest version, which can be installed to a memory card. Also see http://www.smartphonemag.com/blogs/index.php?blog=3&title=an_important_note_on_the_application_you&more=1&c=1&tb=1&pb=1 for more info.
Wowz! Welcome to my blog! I'm also a big fan of compressing compressable Web content, particularly because of the current GPRS prices/speeds (I have to use GPRS at home and when I'm in Finland - can't afford ADSL everywhere I turn up). This is why I've written several articles on compresser clients - have you seen for example this article?
As far as the interface is concerned, I haven't ever used it, programming-wise, and it indeed seems to be really undocumented. I, for example, haven't found anything on MSDN or my books (for example, Douglas Boling's Programming Microsoft WindowsCE .NET, 3rd edition) on it. Interestingly, not even a binary file search (also in Unicode) in VS8 has found anything.
All I've found is this - but that doesn't contain much info either.
That is, it seems some serious debugging / hacking is needed to find out how it works.
Are you sure you've chosen the right (2.0) DLL's, and not the old, 1.0 ones? The latter are in ROM.
Also, in some cases, cgacutil.exe will not be moveable. Try moving the DLL's only, without cgacutil.exe.
I used to publish articles on PDA's in several languages (before entirely switching to English to reach the biggest audience possible) and they're translated by a lot of (independent) people to languages like Greek and Russian (and there may be other languages too). You mean this article? I may translate / rewrite it some day into English. Some of the stuff explained there can be found in the above-linked article on Pocket PC-based compression techniques and the article on mobile phone-based connectivity.
(BTW, all WindowsCE built-in Internet Explorers support compression (gzip at least) starting with Pocket PC 2000 and Handheld PC 2000. That is, not only WM5 users will profit from server-side content compression - it will work with any WindowsCE-based device manufactured in the last six years. This is what is shown in the comparison chart starting with "WinCE 1.0, HP 320LX" in the above article.)
“That's the article I was referring to... what language is it written in? We're willing to get it translated.”
It’s Hungarian, but there is an (older, not that up-to-date) Finnish version as well (offline). Let me know what part of it you would need. It discusses Gzip, compression and similar stuff, but doesn’t contain much more than my Skweezer & et al.-specific articles (the latter being much newer) – it’s maybe only at some WinCE comparison that they offer more at. I can translate/summarize the compression-related stuff and the benchmarks in there so you don’t need to look for translators (which, with small and rare languages like these, can be pretty hopeless).
“It's good, but not good enough (in our opinion) for mobile with the increased latencies involved transmitting data.”
Yup, GZIP'ing may put an enormous, additional burden on servers and may be really time-consuming. This is why I, on the HTTP server side, prefer storing the pre-GZIP'ed (or, dynamically re-GZIP'ed when needed - for example, when one of the components in the page change) uniform (that is, pages that can be delivered to all users - that is, pages without containing the name of the current user if he/she is logged on etc) HTML pages. (Dunno, though, whether the latest versions of, say, Drupal support this. As far as blog engines are concerned, the latest version of b2evo, alpha 1.6, doesn't - only an unconditional, non-cached, always-gzips-at-responsing model.)
Unfortunately, current portal / blog engines don't really support this - so far, I had to do this by hand in PHP/JSP + the underlying database engine. Hope, however, that future engines will be better in this respect.
“One other area we are looking at is segmented data compression... it amazes me what I have to suffer through a 300K page download from some of the web sites out there... why can't the server recognize who I am, the device capabilities I using and then send me just the first 10,000 bytes (compressed of course) for me to read. If I want the rest i can simply hit page down and download it.”
Segmented data compression would be very nice, especially because the HTTP protocol itself doesn't support it. The only "segmentation" it supports is the “chunked” mode, but it doesn’t support compression – or, at least, not that I know of (and, it can’t be made deliver non-visible contents later either). That is, segmentation could only work on a higher level – that is, on that of the HTML document itself. The latter, however, can’t be sliced up without actually knowing what it contains so that all the delivered pages are valid, contain all the necessary JavaScript etc. client-side codes, CSS imports etc.
“Also the whole SSL issue needs to be re-thought when it comes to mobile. It's nuts to encrypt the entire page when all you need to do is protect the field. I know the purists will say it's easier to crack a protected field of a few bytes rather than an entire page - that's not the point. The point is to send less data and increase the users experience. It's easy to pack the protected field with a few more bytes and then encrypt it to thwarte the hackers.”
Wowz! That’d be also very nice.
BTW, your work should indeed be made official – did you speak to the World Wide Web Consortium people (see this) so that the next revision(s) of HTTP would make all this stuff official? All HTTP users would benefit a LOT from segmented, on-request-only transfers.
BTW 2: if you need a HTTP expert (I've done a lot of server-side compression optimization stuff (as portal server includes), written several HTTP proxies etc (see for example this) - see my articles on this stuff), you can also count on me ;) (Not that I have THAT much free time...)
Yes, I have two WM5 devices of my own. I'd be really interested in any client-side compression clients.
Thanks; private e-mail sent.
I think you should check out the IEM cache first. To make the process easier, I recommend either SKTools or MemMaid to clean up the cache. See for example this article on these two applications (and the alternatives).
Let me know if these apps help; if they don't, we'll dwelve into individual directories in the file system to find what's causing the storage memory being so filled up.
Also see this for a disucssion of this article.
It's a full desktop-only .NET framework; Compact Framework (the one that runs on Pocket PC's) are still at 2.0 SP1. That is, you can (still) safely stick with 2.0 SP1.
Nope, as the current CF2SP2 (available as a CAB at http://www.winmobiletech.com/sekalaiset/CF2SP2/NETCFv2.wm.armv4i.cab ) can be directly installed to a storage card. That is, no need to relocate it.