Forum > PDAs and Smartphones
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 :D
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 :D
Navigation
[0] Message Index
[#] Next page