Wiki Home

VFP Runtime Compression


Namespace: Wiki
If you are really clever < g >, and want to reduce the size of your distribution severely, then you can use UPX to pack the files - if you use "upx --best --crp-ms=999999 --nrv2d [filename]", then you can get vfp7r.dll and vfp7renu.dll down to 1.8 MB, for BOTH!

Note that you cannot use UPX on a VFP EXE, as it reads code from itself. You can, however, use http://www.hieroglyphix.co.uk/konxise.php (I have no personal experiance with it, but the concept is sound). -- Peter Crabtree

This comment doesn't really belong here but how does UPX compare with RAR compression?

With UPX (upx --best --crp-ms=999999 --nrv2d), the 4,249,360 bytes of VFP6R.DLL and VFP6Renu.DLL get compressed down to 1,910,784 bytes (55.034% smaller).

With RAR (with Solid archiving, SFX, and Best compression), the 4,249,360 bytes of VFP6R.DLL and VFP6Renu.DLL get compressed down to 1,888,157 bytes (55.566% smaller).

A difference of 0.53%. However, one must take into account that the UPX version has two copies of the decompression code. Also, the RAR must be unpacked before the DLLs are usable - the UPX version suffers no such restraint. Also, if the DLLs get loaded into memory across the network, the network with only have to transfer the packed data (which is also true locally, lowering HD read time), as it all gets decompressed directly into memory, at very high rates (~10 MB/sec on an ancient Pentium 133, ~200 MB/sec on an Athlon XP 2000+, according to http://upx.sourceforge.net).

If you want to save on space and drive/network load time, than see http://compression.ca/act-exepack.html (for DLLs, FLLs, OCXs) and http://www.hieroglyphix.co.uk/konxise.php (VFP EXE compressor). An additional note: most EXE compressors will not work on VFP EXEs, due to how the EXE reads from itself. -- Peter Crabtree

I think there's more to this than "If you find space really that important". The comments above yours give an indication of possible additional, and more relevant, value that can come with compression.
Given today's systems with ultra-fast processors and HUGE RAMs, the HD's impact on performance is becoming more evident. So there is important value in anything that might reduce data access and data transfers. This would be most pronounced on laptop units with thier really slow HDs, but even the fastest 15,000 rpm HDs can't compare to RAM access / cpu execution. Moving less in (or more in the same 'space') from the HD only helps things.
A friend who is a FlightSim user says that afficionados of that software have found that they get smoother performance and better frame rates when they compress its directories. -- Jim Nelson

Jim: I wrote those comments above mine, and you're absolutely right. I don't know what I was thinking. :) -- Peter Crabtree

You may also look at armadillo. It has better compression than konxise, works with VFP8 has a lot more settings, provides keys and is cheaper. I've tested it successfully in various cases. -- Walter Meester


Are you referring to http://www.siliconrealms.com/armadillo.shtml? This program seems to be an anti-cracking piece of software, not compression, but are you saying it does compression as well? Since VFP EXEs are very dissimilar to 'regular' EXEs, I find it hard to believe anything not specifically designed for VFP EXEs would work unless it does something not-too-secure (and SLOW, if you're looking for performance benefit) like decompressing the whole EXE to %TEMP% first. -- Peter Crabtree

Yes, it does do compression and security. Last time I reviewed this it was though somewhat slower when accessing files, but on the average a far better solution than konxise -- Walter Meester


So I am correct with that link? Since VFP EXEs are not like normal EXEs, I can't imagine it is secure. It would have to either have explicit VFP support (which I find no mention of), or have a slow and insecure system such as extraction of the entire EXE to a temporary directory. Have you directly tested Konxise vs Armadillo in terms of loading/execution time, and the size of the EXE after compression? -- Peter Crabtree

Armadillo does indeed have special code and settings for handling VFP Exe's (given that they are not true PE format) - I have used Armadillo successfully with VFP 6 - 9. Anti-piracy, compression, number of concurrent applications running, turning on/off application features based on the key are all provided for. It encases the executable and though it does impact load time as Peter suggests, it is highly secure - I've yet to find another product that offers more security for VFP applications. I would recommend Armadillo as Walter has and for the record I have no affiliation with the company other than being a very satisfied customer. -- Craig SBoyd

That's very good to hear. I find myself very curious as to how Armadillo implements a secure solution for VFP. -- Peter Crabtree

Do not use VFP Runtime compression if you have VFP exe's that were compressed with either Konxise or Refox XI because that will generate errors and prevent that your VFP exe is able to run. Either use VFP Runtime compression or use the VFP exe compression techniques available such as Konxise and Refox XI -- René Brioul

VFP exe compressed in ReFox XI+ does work fine with compressed (ASPack) VFPxR.DLL
see the demo on http://www.refox.net -- Jan Brebera

Contributers: Peter Crabtree Jim Nelson Walter Meester
Category VFP Tips And Tricks


VFP exe compressed in ReFox XI+ have a problem (in ReFox XII the same problem)!
Write a code like the one below, in the Click Event of a Command Button, in a form. You can put an image object too or something big to give a big size (more than 1 MB) to the executable file.
STRTOFILE(FILETOSTR("VFPExe.exe"),"Lenght.txt")
Compile project and build it like exe, and name it "VFPExe". Brand executable with ReFox with maximum compression.
Run the exe file and click on button. The "Lenght.txt" file will be created. Open the txt file and read the size. You will notice that the size of exe from Windows Explorer is different (smaller) like that from the txt file.
So, there is a problem in codding/branding executable files.

- there is no problem, size doesn't matter ...
( Topic last updated: 2013.08.28 06:27:19 AM )