reduce compiled exe size 1

[codetyko]

Is there a way to reduce the size of a compiled exe. I usually create a new project, add the main program and build the exe by letting the application builder search for all directly referenced screens, programs, reports and bmps and adding those not referenced indirectly later and then check the "open file" and "close file" for all screen files. I have seen somewhere a method to reduce the size of an exe by manipulating the screen file by converting the screens i.e myscreen.spr to myscreen.prg and compile it again (I'm not sure, it was a long time ago and didn't take notice at that time 'cos there was no need for it as the exe at that time was quite small - 2.5 Mb)


Any advice or suggesstion will be appreciated. Thanks.

 

[rgbean]

In FPD and FPW (as opposed to VFP), the only code in an .EXE (or .APP) for a screen is the compiled code for the .SPR. So I don't believe that this is the direction you need to go.

The two biggest space wasters are Debug Info and .BMPs. The first stores a lot of information that is often worthless in a runtime environment - consider shutting off for "production" builds. Depending on the BMPs usage and required quality, you can sometimes substantially reduce the size reducing the number of colors and/or going to an RLE format.

When you have the project open, you can also choose the Pack option the the Project Menu items. I have seen this reduce the size of the generated .EXE (although it probably shouldn't).

Another technique I've used is to separate logically independent areas into a separate application, and simply call this .APP with parameters to access it's pieces. While it can complicate certain aspects of development and version control, and the total size of all the pieces will likely be larger, it does have the advantage of smaller pieces.

Rick

 

[codetyko]

thanks rick for the lenghty explanation. By the way, what do you mean by RLE format? I use a lot of bmps in my application to spice it up with custom colors instead of using the standard colors provided. I used them to separate the different data entry options in the screen. If the background color has to be light gray to acommodate genscrnx's "tabs and folder" effects, I have to paste a color in the form of a bmp file to maintain the style.

Do you think this will impede performance and if I want to upgrade to VFP6 (sooner or later I would have to with Windows XP and all) would I be able to migrate without having to forgo this style? If the answer is yes, what is the best way to go about it. Read somewhere in the forum dgrewe is still using fpw26 code while using VFP6. Any comments?

 

[rgbean]

RLE is Run Length Encoded, an &quot;old&quot; way to reduce the size of BMPs. These were often used in Win 3.x when disk space was much more exprensive and modems were a lot slower. (Note: Some RLE files don't work in VFP <s>.) Any graphics program will normally allow you to save BMP files in at least 4 different formats - OS/2 or Windows, RGB or RLE (not including the color depths or 1-bit, 4-bit, 8-bit and 24-bit).

Handling of colors is very much an individual thing. In general I tend to follow the Windows' standards, which basically say allow the user to change them through the color panel. I personally dislike when a programmer has decided that my taste in color schemes is &quot;wrong&quot; and his is &quot;right&quot;. On the other hand I've had some customers that have well established corporate standards for all custom software, and you have to follow those.

The good news is that color and BMP handling is much easier and more flexible in VFP, assuming you go the whole OOP route.

While I've done conversions in a number of different levels, including running 2.x code under VFP, the best solution is to re-write. Maintenace on most converted stuff is at least frustratrating due to not having access to some of the new features, to plain impossible. (There are times when you have to do the changes in FP 2.x and then &quot;reconvert&quot; it - really not much fun after the 3-4th time.)

The most useful information I got on migrating, came from MicroEndeavours, Inc. They have a self study course VF610 &quot;FoxPro 2.x to Visual FoxPro Migration Manual&quot;

http://www.microendeavors.com/training/default.asp,

choose &quot;Self-Study&quot; at the left, then down near the bottom of the page.

This includes a number &quot;why's&quot; and &quot;how to's&quot;, as well as some useful utilities to assist in the process. One of their techniques allows a gradual transition using a mixed model, but there are some downsides as you might expect. Also, one utility can create forms from the running code - you don't even have to have &quot;screens&quot; (.SCX files) to convert them. For the price - $249 that last time I checked - you can't get better advice. (I have no connection with them, other than being a satisfied customer.)

Rick