Smartphone & Pocket PC magazine - Comments for "Relocate .NET Compact Framework 2.0 to your storage card: free up 5.4 Mbytes of precious internal storage! A never before publis"

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.

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.

Also see this for a disucssion of this article.

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.

Thanks; private e-mail sent.

Yes, I have two WM5 devices of my own. I'd be really interested in any client-side compression clients.

â€œ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...)

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.)

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.

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.

Smartphone &amp; Pocket PC magazine - Comments for "Relocate .NET Compact Framework 2.0 to your storage card: free up 5.4 Mbytes of precious internal storage! A never before publis"

Smartphone & Pocket PC magazine - Comments for "Relocate .NET Compact Framework 2.0 to your storage card: free up 5.4 Mbytes of precious internal storage! A never before publis"