WinCE & archives

[CCRDude]

I've tried for some hours now to get some kind of unpacking done on WinCE.

First idea: use CABs, since they're supported on Windows nearly by default (IE 4 or something). I had two CAB units for Delphi, adjusted both for FPC and got them to run under Win32 - but linking for WinCE caused some problems in FCI...something functions.

I then found the unit unzip in the Lazarus/FPC folders. Works fine on Win32, but on WinCE I get the misaligned data access error.

I gave up on those components and wrote two simple routines using TCompressionStream and TDecompressionStream. Oldest thing in the world and quite simple. But even on Win32, TDecompressionStream fails after byte 32767! CopyFrom will simply cut the file at 32K, manually copying 4KB blocks results in a file of the proper size, but with all bytes after the 32767th one wrong (FPC from subversion, release 3873, since never versions won't allow to build an ARM environment, thanks to the Interlock changes in systemh.inc and other files that now result in an unresolved forward or something).

Four methods - all somewhat broken. Is there any part of the compression/decompression routines in FPC that is known to run with WinCE?

Update: method 5, using bzip2 and pasbzip example. Works on Win32, stops the application without any apparent error message on Windows CE.

Now if the DecompressionStream would at least work... it behaves the same faulty way on both Win32 and WinCE, so if it would work on Win32 again, I guess it also could on WinCE...

Update method #6: gzip from freepascal throws an AccessViolation on WinCE where the same code works on Win32.

[felipemdc]

This doesn´t really answer your question, but you can find a pair of wince executables, like compress.exe and decompress.exe and just use them. The method of compression doesn´t matter, so just find a command line binary for windows ce that can compress. You can use this method until there is working compression on Free Pascal for Windows CE.

Another option is to test paszlib. It is purely written in pascal, so it is possible to fix any misaligned data access errors it may have with some ifdefs and the unaligned keyword.

[CCRDude]

Oh, paszlib was one of the things I tried - I just didn't really find the possible alignment problem

Since I heard & saw that WinCE uses .cab files for installers and all, I imagined that it would have more or less the same cabinet.dll as Win32. So yesterday I wrote my own interface to use that DLL after two others failed. And then I noticed that file was missing on the device

Using command line executables would be possible, but even better - I finally got TCompressionstream / TDecompressionStream to work! I guess the problem was related to the older file open error I found; which was fixed in SVN, but since the newest SVN didn't compile and I had to step back...
So now I built a miniature file directory in front of the compressed stream to be able to store multiple files, and it works fine on the device!

In combination with another unit for interfacing InternetOpen etc. functions, my app now gets files from the Intranet, and I'm happy

[felipemdc]

Great news! =)

Can you send us a test application that gets files from the internet and does compression?

I think it would be valuable for other FPC-WinCE users. It would be nice to add it as an example on Lazarus CCR: http://wiki.lazarus.freepascal.org/index.php/Components_and_Code_examples#Example_programs

[CCRDude]

Sure will do! I just need to finetune the test apps... right now they're based on the mini framework I created to have my app fullscreen etc (the stuff the LCL can't do yet); I should probably change them into command line apps, and I need to add comments to the two units). I bookmarked this page to keep me reminded for tomorrow

Btw, I only now noticed the term CCR... what does it stand for? The CCR in my name is just Creedence Clearwater Revival and has nothing to do with it

[Anonymous]

Hello,

I think it would be valuable for other FPC-WinCE users.

I fear, it is not so easy to become a FPC-WinCE user. I tried http://wiki.lazarus.freepascal.org/index.php/User:CCRDude (thank you CCRDude, for this work) but it was impossible for me, to get a running crosscompiler out of the latest FPC 2.1.x snapshot.  I got the ppcrossarm.exe, but compiling the rtl failed.

Regards, Bernd.

[Legolas]

I have submitted a bug report for this issue. BTW, try to add to rtl/arm/arm.inc this code:

Code: [Select]

function InterLockedCompareExchange(var Target: longint; NewValue: longint; Comperand: longint): longint;
  begin
    if Target=Comperand then
      Target:=NewValue;
    Result:=Target;
  end;


and recompile rtl

[felipemdc]

I fear, it is not so easy to become a FPC-WinCE user.

The 2.1.x subversion source code is very unstable, so some days it works, some days it compiles but doesn´t work and some days it doesn´t even compile.

We could use a snapshots with a reasonably stable precompiled fpc-wince. I hope we can create this on July where at least I will be on partial vacations.

[Anonymous]

We could use a snapshots with a reasonably stable precompiled fpc-wince. I hope we can create this on July where at least I will be on partial vacations.

This would help a lot.

Regards, Bernd.

[oro06]

hi,

using dev branch has his counterpart,
globally it improve a lot but several big changes can brake little things...and in last weeks there have been several big changes.
it will be better after 1st release including arm-wince (it seem not to be planned for 2.0.4 release)

i'm using a lot fpc for arm-wince (native api call, not with lcl) and as you already know : not all snv are usable.
svn versions on wich i've had good results are :
3068, 3462, 3539, 3621, 3672, 3732, 3919
not that on latests ones you must use -Xi to use internal linker.

on my pov it's better to have 2 fpc trees one 'stable' (i suggest 3919 or 3732) for working and one for testing latest svn improvement AND reporting bugs, if there are


regards
or

[CCRDude]

Ok, the first example (communications) is available here (I'll try to keep my installation batch file updated on that blog as well); by now I've read that the Indy FreePascal port is said to work on WinCE as well, but I stopped liking Indy when I received too many complains about apps hanging when a server is not reacting (and even Stop etc. didn't really work) I guess a class with a simple wrapper function with URL, target TStream or TStrings is simple enough and doesn't need an app using it to complete the example?

An example for compression will follow later or tomorrow or so, but somehow I think they're quite too simple to be mentioned on the Wiki page - they're just wrappers really

Thanks for the list of usable svn revisions, oro06 I've seen there's also a newer source download (June 29th), so I guess I'll be trying that shortly.

(and yes, of course one stable and one test environment are always a good idea - it was just that the last "stable dev" (June 4th) source wasn't that stable at all with the EFFileOpen bug and I had to use a newer subversion to be able to open files on the Ce device )

[Anonymous]

Hi

I tried your batch file and I am getting following error

------------------------------------------------------------------------
Press any key to continue . . .
The necessary files were found, you may now continue.
Press any key to continue . . .
------------------------------------------------------------------------
The cross compiler will now be created...
------------------------------------------------------------------------
'make' is not recognized as an internal or external command,
operable program or batch file.
------------------------------------------------------------------------
If you don't see any error messages, you may now continue.
------------------------------------------------------------------------
Press any key to continue . . .

Please help!

Regards

Sandeep

[felipemdc]

Your PATH environmental variable is wrong.

Try adding to the start of the batch file:

PATH=C:\Programas\fpc\bin\i386-win32;C:\Programas\arm

where C:\Programas\arm contains the arm-cross-binutil, and fpc\bin is the 2.0.2 compiler binaries and utils (make for example).

I don´t know if the batch needs other things on the PATH, like Lazarus for example. Maybe it does need.

[CCRDude]

The batch file actually sets the path itself before doing any make, just to avoid such problems (well, usually at least):

Code: [Select]

set path=%x_armdir%;%x_lazdir%\pp\bin\i386-win32;%x_lazdir%\pp\bin\arm-wince;%APR_ICONV_PATH%

This uses two environment strings defined at the beginning of the file:

Code: [Select]

set x_lazdir=C:\Apps\Lazarus
set x_armdir=C:\Apps\arm

If you did install Lazarus or the ARM utils into a different place, you need to edit this (second and third line of the batch file). But then, if it hadn't find a Lazarus install in that folder, it would have displayed an error message. Do NOT use trailing backslashes in that definition of paths though.

(btw, make was also a problem why I created this batch file settings the environment path for itself - having Delphi installed, "make" usually called the incompatible one from Borland)

I'm going to try it with the latest download now, time for an update anyway

Update: Lazarus-0.9.17-20060702-win32.exe and fpc.zip from June 29th (links from the batch file and the Wiki page), both extracted into a clean folder: compiles quite without problems. startlazarus.exe is not a valid Win32 application it tells me now, but running it through lazarus.exe, I was able to successfully compile my main WinCE  project.

Please post the first lines of your batch file, and the paths were you have the ARM and Lazarus stuff (and also make sure the Lazarus sources were extracted properly - not the comment about the pp subfolder!)

[Anonymous]

Hello,

I have now a running ARM FPC/Lazarus packet, which was built with CCRDude's batch file. I still had to copy the ARM binutils to the pp\bin\arm-wince directory and I added the -Xi, -Xs, -XX options to the fpc.cfg file in the same directory.

Has anyone built a real application with the WinCE interface?

Regards, Bernd.