Safe limit size for EXE file in FVP9 1

[Piotr Czekalski]

Hi all.

I have 2 similar projects in VFP9. I would like to join them in one. I compiled them for a testing and the EXE file size was about 800 KB.

I would like to ask experienced colleagues. What is the safe limit size for EXE file in FVP9 ?

 

[Joe Crescenzi]

If there is a limit, you are nowhere near it. My EXE is over 16MB.

 

[GriffMG]

I think it is likely around 2GB...

I have exe files in VFP 9 that stretch to 80MB - I sometimes include binary files in them, documents, dlls, other stuff

 

[Chris Miller]

I think you could even go over 2GB EXE size, after all, the number space of 32bit is up to 4GB. See for example https://stackoverflow.com/questions/11271441/how-can-a-32-bit-process-use-nearly-4gb-memory

Anyway, a VFP exe and/or the VFP9r.dll runtime is likely not "large address space aware" and so I think is limited to 2GB. You could easily try the limit by including a lot of large files into the EXE. Just add large files into a project and include them into the build.

For practical reasons, I'd not take it to the max, if you distribute the EXE in a company over a network share or even use it directly from there - but an MB is small, still.

 

[Mike Lewis]

I've worked on some pretty huge projects over the years, but I've never encountered a problem with EXE size. Nor have I heard of anyone else having a problem.

Mike

 

[Piotr Czekalski]

Thanks all for the reply. I asked because my EXE files are not much bigger than 400 KB. I had problems in the past (Pascal Clipper). I've always tried to keep the code as small as possible.

I'm happy to hear your opinions.

My users like to have multiple Excel spreadsheets or Word documents open at the same time. Standard office computers in my users have 8 GB of RAM and Windows10. A few have Windows11.

 

[Chris Miller]

You'll have a hard time programing that much code, but it's easy to create a large file fast:

h=FCREATE("dummy.txt")
FCHSIZE(h,2^31-25*1024)
FCLOSE(h)

Add the resulting dummy.txt file to the text files section of a new otherwise empty project, add in an empty main.prg, and build the project. The 25 KB smaller than 2GB size of the text file is there to allow a stub of 24KB any FoxPro EXE has.

I managed a 2GB file size EXE, exactly (size on disk, actual size 1.99 GB). Trying to add this file in twice fails, so the technical limit is exactly 2GB (theoretically it could be 3GB or more, I didn't test for a slightly larger txt file and leave it as an exercise to anybody interested in finding out).

The EXE is also starting and running (include a read events in main.prg, of course). The first start just took very long, but only the first start.

The 2GB EXE size limit is not mentioned in the "System Capacities" help topic, but it doesn't surprise me as other file related maximum sizes are 2GB, too.
Anyway, as you already realized, it's not really a practical limit. Even if you decide to embed files in your exe like a large database, you could do so up to 2GB. It makes more sense to keep data separate, though. You could use a lot of large images for the look of an application, though, and have them all included in a larger EXE.

A slim EXE, of course, is a good goal, but even the large 2GB exe doesn't allocate that much memory when it runs. Just look into details of Task manager.

 

[Mike Lewis]

I've always tried to keep the code as small as possible.

That's a sensible thing to do, with any development platform.

I sometimes do a cleanup of the project before a build (from the Project menu). It can substantially reduce the size of the project files and therefore the EXE.

Mike

 

[Mike Lewis]

Two other things you can do to help keep the EXE file size down:

- Untick "Debug info" in the Project Information dialogue. (This can make a big difference.)

- Manually remove any dead code, such as class definitions or procedure code that is not used.

Mike

 

[tomk3]

You may try REFOX which can protect and compress an exe, very useful if you include graphics, tables,..

we have .exe > 20 MB on customers sites
we have other .exe compressed from 16 MB to 1,5 MB (refox)

 

[Dan Olsson]

My EXE is 800 Kb but I also have 15 APPs with a total of 1.5 Mb

 

[Gerrit Broekhuis]

Most of our EXE’s are 8 to 14 MB, no issues whatsoever and still very very fast.

Regards, Gerrit

 

[Piotr Czekalski]

Thanks for your help and very useful comments. I'll start preparing to merge the projects code.

 

[Scott24x7]

I never even thought to look at the size... If it compiles to EXE it will run.

Our main application is just a hair un 16mb.
A lot of this will depend on "excludes". Some things you don't need to compile into your application (and some you don't want to as it's a bad idea), but it's easy enough to control, as most of the "size" in the application isn't the code, but the things you add in like images, text files and unused class libraries (keep the classes in that you need, but get rid of stuff that's no longer used). It's good to keep good discipline in your project, but size isn't really something to worry about (in this day) when it comes to size of VFP EXEs.

 

[Piotr Czekalski]

Thank you. The project generating the EXE has only program code. I don't have any graphic files there. The differences in projects are in the user interface. One looks like DOS, the other is typical for Windows. Settings for individual applications are saved in DBF tables. Macros defining the application's operation are saved to MEMO fields. Tables are not compiled into an EXE file. The EXE program works a bit like interpreter. It takes macros from the disk for processing and executes them. It clears the memory and executes other macros. This is convenient because the program is parameterized. Some users can edit macros themselves.

From your opinions it seems that EXE file 700-800 KB should not be a problem.

Thank you all very much for your feedback

 

[Chris Miller]

Of course saying you can have up to 2GB of images, data, and any other files embedded in an EXE doesn't mean you have to. If you embed data, you'd need to extract it to not only have read access, and that's just the first argument against doing that. But I came across people arguing a single file exe is their goal, and they can then extract and lock/exclusively use the extracted data files (for single user applications) so it's always protected against writes from any other process. I would recommend other ways, but that aside,

I was only pointing out what still works and thinking about how you could get to a 2GB exe in a sensible way. I think a photo heavy application would still better store images on disk, especially if users add and change images, so the only static images inside an EXE would be about a complex UI. Not unthinkable and a valid use case.

But overall I'd always think of separating large sets of data, documents, any files, outside the EXE. I wouldn't necessarily force out any images, though, if your UI has an icon set for buttons, toolbars, keeping them outside of the EXE just complicates things more than necessary.

 

[Piotr Czekalski]

It used to be possible to store overlays in EXE files. But that was in DOS. A fragment of the EXE was loaded into RAM. The main menu and other necessary things. The rest was loaded as needed. However, system reserved RAM for the largest overlay. That was the case in Clipper. I don't know how it is solved in VFP. If there are photos in the EXE file, does the system load them all into RAM?

I don't use photos in EXE. In tables, yes. I keep the names of photos in fields. Files of photos in a separate folder on the disk. I check consistency from time to time.

VFP needs a lot of RAM. I once did a test at a client's cvomputer. He complained that the program is working slowly. I started the program to create a report. The report was created in 10-15 seconds. Then I opened a dozen or so EXCEL sheets. The same report was created for several minutes. There were no errors, only time to create the accounting report was significantly longer. This mainly concerned the Select SQL operation.

 

[Chris Miller]

If you set a command button picture or simpler: use an image control and set its picture, you only set the file name, but for the PJX and build that means the image is included into the project and into the EXE. That's fine, because you usually won't want to provide an EXE and all the images used on buttons, toolbars etc. as spearate files.

Images like house photos in a real estate application, generally data images, of course are better kept outside.

But it's normal to use icons for buttons, and I don't just mean ICO files, though that's the only format usable for the EXE icon itself and the windows titlebars. Anything else, images on buttons, toolbars, background images on the form canvas, etc. can be formats like GIF, BMP, JPG, PNG. and some more.

The way an EXE is not fullly loaded into RAM is managed by Windows, you don't have to program anything for that, neither in VFP nor in any other programming language. I mean that only for the concept of paging - which is what it's called, what parts of an EXE and also the DLLs it uses, are loaded into memory or not.

 

[Piotr Czekalski]

Exactly as you say Chris. I just checked it. I added a lot of pictures to the EXE file (houses, forest etc). In the process manager RAM allocation did not change (7.5 MB). The EXE file has increased significantly (20 MB). If I used the pictures in the program the RAM allocation would probably increase. So that's how it works.

My system programmer friend always said. What Windows system statistics show is not always true. Especially when it comes to RAM allocation.

BTW - I have a lot of photos because my second hobby is photography

 

[Chris Miller]

What Windows system statistics show is not always true. Especially when it comes to RAM allocation.

I think that's a problem you always have when looking at a process from outside. But there are a lot more memory related columns in Task Manager than just the Memory column of the Processes tab. Details is always able to show more, there are a lot of memory related columns there, you can add in like "Memory (private working set)", "Memory (active private working set)" and a lot more.

Anyway, for all the images you know you'll use throughout form buttons, it would not differ that memory is used for images displayed, whether they come from separate files or from the EXE, embedded, they are not used in their file format anyway, which is usually compressed. So images take more RAM than their files, anyway. But since VFP uses gdiplus, I'm not even sure images would count to your process memory usage. In the details tab you have columns like GDI objects that tell you how many objects like brushes, bitmaps, colors etc. are handled by GDI+. Well, and images on display are stored in the memory of the desktop, that's "shared" with all processes and doesn't increase your process Memory footprint, it's the bitmap object that's existing on top of the copy of all the pixels on display, that would be exclusive to your process or the gdiplus.dlls handled memory.