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 ?

 

[Piotr Czekalski]

Thanks for the extensive explanation. The old project (DOS interface) is written in VP6. The second one with Windows interface in VP9. I moved the required code fragment to VP9, made some corrections. Tt'is slowly visible that it will be working.

There is a question. Is processing DBF tables more efficient by VFP9 than VFP6 ?

 

[Chris Miller]

Depends how you process them. The major optimization with Rushmore has not changed that much, but the VFP9 help has some things to say about the optimization of counts while SET DELETED ON being better optimizable, there's also the binary index type and of course several new field types. We already talked about autoinc, other types like varchar mainly are added for simpler usage of such column data types from SQL Server, a varchar(X) does not make a record in a DBF have variable size, for example, the DBF structure still has fixed length records within the DBF file aka RECSIZE(). Any fields with variable length are put into fpt files, as always.

The only profit about varchar instead of memo is, you can read back a varchar field like a memo field without trimming. If you store "Hello, world!" you get back "Hello, world!" not "Hello, world! " padded to the right with spaces. Still the string is preserved as saved. The way it's padded to the field length is with CHR(0), and those zero bytes are removed from the value when reading it back.

What has improved quite drastically is possibilities of SQL queries, much more possibilities for subqueries, for example. And in that, I'm sure, also is potential for better performance.

 

[mjcmkrsr]

Sidenote

Hi,

If you're working with DBCs and the RI builder don't forget to run it again. Please have a look at thread https://www.tek-tips.com/threads/trigger-failed.1638030/

hth

MarK

 

[tomk3]

Hi,
to reduce ramusage / speedup I recommend :

• have a look on sys(3050,1,xxx) and sys(3051,1,yyy)
• have a look on sys(1104) and apifunction SetProcessWorkingSetSize()
• doevents force in loops and after starting excel for automation

 

[Piotr Czekalski]

Thank you all for informations.

 

[Piotr Czekalski]

However, size of EXE file can affect the program's incorrect operation. I joined finaly two of my projects into one. EXE file was 600 KB and now it is about 1 GB. ShellExecute, which calls MS Word and XML files (document emission based on DOC templates), stopped working. I optimized program code and ShellExecute started working. Additionally, I saved unnecessary to procedure working variables on the disk (SAVE ALL LIKE TO) and deleted variables"RELEASE". After procedure emissing documents was finished, I restored these variables "RESTORE FROM FILE ADDITIVE".

I got a little scared

Maybe it's a coincidence and error is hidden somewhere else ...

Computer memory RAM 4 GB, Windows7 VFP 9.0 SP2.

ERROR: shellexecute can not find entry point ....

Now it's OK.

 

[Chris Miller]

How did you join two projects of each about 600K to get to 2GB?

 

[Piotr Czekalski]

How did you join two projects of each about 600K to get to 2GB?

About 1 GB - exactly 820 KB.

 

[Gerrit Broekhuis]

What is it? KB, MB or GB. This makes quite a difference…

Our .exe’s are usally between 4 and 14 GB. Our installer (with 3rd party components and add-ons) is more than 500MB.

Regards, Gerrit

 

[Chris Miller]

820 KB is about 1 MB, not GB.

 

[Piotr Czekalski]

Of course my mistake. It's 820 KB - about 1 MB not 1 GB . Sorry for misunderstanding.

 

[Gerrit Broekhuis]

In that case you have nothing to worry about. You are definitely on the safe side with your 820 KB.

Regards, Gerrit

 

[Piotr Czekalski]

Yes, there is one more aspect. How much RAM will a 32-bit process use in Windows 64 bit? According to sources, it is practically only 2 GB 9 (Source StackOverFlow).There are some magic tricks to increase this, but I don't know how to do it. When I removed some variables Shell Excecute started to run a Word text processor and display a small document (2 pages) with transmitted employee data. The document has some company graphics in the template (200-300 KB).
XFPlik It is "C:\PROGRAM FILES\MICROSOFT OFFICE 15\ROOT\OFFICE15\WINWORD.EXE"
My program in the configuration part finds WinWord.EXE and saves path to program settings
In My clients' XML files are opened by NotePad, so I use this solution.

XFPlik Its Full path to run MS Mord:
C:\PROGRAM FILES\MICROSOFT OFFICE 15\ROOT\OFFICE15\WINWORD.EXE

template:




result:

XBufor=FileToStr(StrTran(Upper(_DOSTEP),"DANE","SZABLONY")+XP_Wzor) && loading MS Word document template (XML)
===========
processing
============

XPlik=_TMP+'FORM.XML'

StrToFile(XBufor,XPlik)0 && saving processed document (XML)

Release XBufor



DECLARE INTEGER ShellExecute ;
IN SHELL32.DLL ;
INTEGER nWinHandle,;
STRING cOperation,;
STRING cFileName,;
STRING cParameters,;
STRING cDirectory,;
INTEGER nShowWindow




XVPlik=["]+XPlik+["]


ShellExecute(0,"Open",XFPlik,XVPlik,"",1)

 

[Chris Miller]

What memory you reserve can be controlled mainly with SYS(3050). It's not working straight forward as memory allocation, it sets a maximum

If you automate Word, that starts a word process, which has own memory, not counting for your process memory. Which makes me wonder why that would break anything.
You talk of saving variables, SAVE wil save all but object variables (check it out yourself), so it wouldn't touch a word object that has whatever large child objects in it. Which in turn makes problems about too short memory for RESTORE a mystery. But how large are the files you restore from? And how about managing saving variables in a new way not using SAVE/RESTORE, if that's problematic?

 

[Piotr Czekalski]

Ha, these aren't big files. The maximum file size of a macro for a document transmitted by the program is 52 KB. I think the freed up memory of the saved variables is no more than a few MB. Errors are reported. Restore variables has never failed.

Give me some time Chris. I'm back from the hospital and can't work in computer where I have VFP long time (max 1-2 hours per day).
I have to service customers.

I have memory and variables monitoring from everywhere in my program.





Why ShellExecute stopped working after joining projects (about 100 new variables and new 400 KB of EXE code) I dont know .
I'll have to investigate this case.

A little optimization and it works.

 

[Chris Miller]

Are you scoping variables as close as possible to code using it, ie using LOCAL, variables, not PUBLIC or undeclared variables. If you have overlaps in names with other meanings that can cause all kinds of side effects, none of them would have to do with insufficient RAM, though, just overrridden variables that break code.

Generally I wouldn't recommend to use SAVE ALL to save and restore a state of an application, but only save a set of variables known to be needed from a RESTORE again.

 

[Piotr Czekalski]

That's more or less how it's done Chris . I had to do it in Fox-Pro 2.0 under DOS. The "ExecScript()" semi-interpreter needed a lot of variables, mostly arrays, and there was no memory.




Maybe I'm unnecessarily deleting and re-declaring variables with the same names. This is for clarity of process. This was done 30 years ago. It's better not to change it

Variables with names starting from "_" are variables and arrays from procedures called recursively.
There are more such places in program like this.

Exactly, I forgot about recursion. It also uses memory - mainly memory of stack. Maybe that's why calling SchellExecute caused an error. Code of procedures called by recursion has grown, new variables and arrays have been added. MS Word 64 bit did not fit on 4 GB RAM.

In Pascal I had message : "Stack Overflow"

 

[Chris Miller]

That code is not self explanatory to me, but I sense some mismatches already in the PUBLIC declaration after the RELEASE in the Start_Buf procedure.

It was never a good idea to use many public variables, private variables were always usable to pass in things without needing parameters, especially in recursive code. Anyway, you'll surely find out a mismatch in usage of variables in the seperate projects now bites you with errors in the merged project. Not alonw but also because mem files you restore in the unified project would only work for one of the previous projects. I see you only use the mem files (saved to) temporarily and erase them after RESTORE, but do you use save files to restore variables in a new application session? Then you easily suffer from these files not working for the combined project, i.e. you have incompatibiliites that would only go away after you also merge all necessary variables into new SAVE files.

 

[Piotr Czekalski]

Yes, _FME_OVR variable dropped out of the project. I will remove this variable from program code,I restore variables saved in files when recursively called procedures are closed. I restore the values of variables in the procedure to which the return occurs. Each level of recursion has variables with the same names, of course but variables contain different data. Executing Save, Release, Restore sequence commands allowed me to reduce memory usage with each recursive procedure call. Out-of-memory errors stopped occurring.

Public variables facilitate exchange of data between different procedures. Do they take up more memory RAM ?

What do you think about ShellExecute error Chris. What could be reason of this error ?

ERROR: shellexecute can not find entry point ....

 

[Chris Miller]

Do they (public variables) take up more memory RAM ?

Of course they do, like all variables. What's bad about public is the far too large overall scope, they are visible in any code, while you only need variables scoped to the currently running code, ie mostly local variables.

Private variables will be visible in recursive calls without passing them and you will only need to set them once and don't even need a save/restore mechanism that way. That means code you call with your own ExecScript replacement will not need a parameters line nor passed in parameters nor Restored variables, if the parameters are simply set private variables before the call to the code.