WinCE & archives

[CCRDude]

Well, actually, while I save nearly 50% or so (I've got quite a lot of functionality in that code, so the "huge" size has its reason) if I use the internal linker (-Xi), the emulator will tell me the that the file is not a valid PocketPC application. So I'll stick to the 1 MB working app vs. a 500 KB corpse
(But that were tests with the late-June-combination, haven't yet tried -Xi with the July 6/7th combination I did upload)

[Anonymous]

...if I use the internal linker (-Xi), the emulator will tell me the that the file is not a valid PocketPC application...

funny, I never used the emulator. My application is running well on a real device.

Regards, Bernd.

[CCRDude]

I've got three devices here for testing over the weekend, but the emulator is quickest thing for debugging...

I tried with the newer release. -Xi works well with the newer release, but something else seems to be different since my compression/decompression and encryption/decryption code stopped working with that release. Now I got access violations on the "end;" line of functions there when just starting the app (were this code isn't even called), so I'll stick with the older release for now

[_Bernd]

...So I'll stick to the 1 MB working app vs. a 500 KB corpse

BTW: UPX supports now ARM EXE files on WinCE. See http://upx.sourceforge.net/#news
My 1,3 MB EXE file results in a 360 KB compressed file.

Regards, Bernd.

[CCRDude]

I'm not really an UPX fan I have to admit

Especially with WinCE devices, I would accompany that suggestion ALWAYS with one to write the application such that it can't run in more than in one instance (because while normal applications may share memory, once you got it UPX'ed, each instance will take it's own expanded mem space - hazardous on a device with low memory -, unless they've improved UPX in that regard by now?).

I problably should add this to my sample app :

Code: [Select]

var hExisting: THandle;
// ...
begin // main loop
   hExisting := FindWindow(sMainWindowClassName, nil);
   if hExisting<>0 then begin
      SetForegroundWindow(hExisting);
      Halt(1);
   end;
// ...
end.

[Marc]

Not sure about this, but since memory and disk are virtually the same on CE devices, I always had the idea that the exe isn't loaded, but directly mapped from "disk". I can imagine that using UPX in such cases will result in a larger mem usage (one time for the compressed image and one time for the expanded)

[CCRDude]

Directly mapped from the disk? A whole filed can't be mapped from the disk imho... if I take a look into the PE header of a CE executable created with FPC, the physical address of sections differs from the virtual address. So they're clearly intended to not be mapped from the disk (wouldn't work ). Could be that it /would/ be possible, in this case the compiler/linker/etc. probably would need to create a PE file that supports this (identical physical/virtual addresses, and imho there's another header field that would need to be adjusted, which just won't come into my mind currently).

So even if applications would be stored in RAM (I've read something about old PocketPC phones loosing applications when battery is empty due to that?), they would need to get more memory where they could be stored correctly mapped when running.

Another reason why I think that they are not directly mapped: SHCloseApps, which goes and frees RAM by sending WM_CLOSE to other applications. If they were mapped on disk, this would be useless, as it wouldn't free any memory

Without UPX, some fixed sections would probably even be loaded only once even if multiple instances are running. With UPX, the PE loader can't determine which sections would support that, so all sections would be loaded for each instance, thus creating another memory overload in addition to compressed+expanded usage (just my few cents of thinking, I'm writing this where I've escaped too from the heat, and where I don't have my PE cookbook at hand ).

But imho: it makes sense to allow WinCE applications to run in only one instance anyway, since especially on smartphone devices without the touchscreen, killing tasks or even switching to already running tasks is a real pain. So it would only be the decompressor code (I hope it wouldn't load the compressed image into memory, imho the decompression could work fine with the disk as source ) that'll mean additional memory usage then.

[tony72]

Windows CE does support Execute-In-Place, but I don't know where it is used, I had the impression it was used for OS code only, not user applications, but ICBR.

And Pocket PC/Windows Mobile devices prior to WM5 did indeed use a RAM filesystem as the primary user mass storage, and would lose all user applications and data if the battery went flat (or backup battery if one was present), my 3850 is like that. Only with WM5 was the switch made to flash for storage.

[tango13]

Hi all,

googling around for some free possibilities to develop on PocketPC devices, I ran across an old friend of mine (that is Lazarus, which unfortunately I haven't used for some time) and saw with great pleasure how much it has already progressed toward the WinCE platform!

First of all, a big thank you to all the people involved in this project: you are really doing a terrific job.

Then I browsed this forum and found a lot of precious information and files, especially CCRDude's package (thanks for that!) including all that is needed to use Lazarus and FPC to create WinCE applications.

Following the simple directions, I was able to design, compile and run on my WinCE device a "Hello world" application in no time and effort!

I will probably come up later on with questions and doubts, but for now I just wanted to express my greatest appreciation to all the contributors for this really stunning achievement. Lazarus/FPC is getting absolutely huge!

Ciao,
Piero

[tango13]

@CCRDude
You wrote in your blog, regarding writing WinCE applications without a framework:

The results are very lightweight applications that don't even need object-oriented programming like shown in my simple demonstration application, available here; though I would recommend to capsulate the window and control creation at least, and for larger projects, classes do really make sense for creating code with a structure that's way more easy to read. Showing my whole framework unit that does this would have made the basics a bit more difficult to understand though.

My question is: would it be possible to see your framework unit in order to understand how it is structured and how it works?

Thank you so much for all of your help in this forum.

[CCRDude]

It's all in a temporary state somehow, since I'm still working on it. If I would publish it, there would be wishes for more features (that I probably wouldn't have the time to fulfill ).

I guess I'll need to add some more documentation to the class before thinking about publishing it. May have that time over the week though

Meanwhile, as a "teaser", here's a usage example, there you can at least see how it works from the applications side. Again I kept it small to make is easy to understand on just one or two pages. My full test app (which is too full of debug things right now ) looks this way (including the transparency groupbox bug I didn't deal with yet):

(http://img148.imageshack.us/img148/483/miniguidemoju8.th.png)

[tango13]

I guess I'll need to add some more documentation to the class before thinking about publishing it. May have that time over the week though

I really do hope so, because your teaser whetted my appetite and I can't wait to give it a try...

Thank you for your kind and quick reply.

[tango13]

Hi CCRDude,

In order to overcome Lazarus problem with fullscreen forms, is there a way to "mix" the two procedures, I mean using Lazarus visual tools as usual but replacing its normal way of creating forms by using your workaround (that is by directly calling Win API)?

I hope I am not doing too much confusion...

Thanks,
Piero

[CCRDude]

You mean getting a real fullscreen with the LCL? Never tried, but I guess it could be possible, what you need are just these:

Code: [Select]

function SHFullScreen(hwndRequester: hWnd; dwState: DWord): WINBOOL; external UserDLLAyg name 'SHFullScreen';
function SHSetNavBarText(hwndRequester: hWnd;pszText: PWideChar): WINBOOL; external UserDLLAyg name 'SHSetNavBarText';

const SHFS_SHOWTASKBAR   = $01;
      SHFS_HIDETASKBAR   = $02;
      SHFS_SHOWSIPBUTTON = $04;
      SHFS_HIDESIPBUTTON = $08;
      SHFS_SHOWSTARTICON = $10;
      SHFS_HIDESTARTICON = $20;

As well as SHInitDialog. I'ld suggest you try using them (you can see my example on how to use them) in OnShow of the form and see if it works

[tango13]

It works just great!
The only thing is that the code doesn't seem to work when placed in the OnShow event. Instead, it works when placed in the onActivate event of the form (haven't tried other events though, I'll make more tests).

Thank you very much for your help!!!!!!