Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Include non-foxpro EXE within Foxpro EXE

ajenat

Programmer
Nov 28, 2007
13
IN
Can i include an non-foxpro executable file in my foxpro project and run (with parameters) in program without saving it to disk location.
 
You can include an executable within your vfp app and write it to disk - then run it. I do that all the time, but I am not sure you can run it from within vfp
without writing it to disk, your os will not see it within the vfp exe
 
As Griff says, I think you can embed anything inside a compiled VFP exe. The project has the "Other" tab and the "Other Files" section for anything that doesn't fit in any other sections. I think you can probably put absolutely anything (within reason) into that section. I only say "within reason" because you've got file size limit and file size considerations to consider, you might also need to consider file names - just to ensure there is no confusion between files of the same name, best to be avoided.

Regardless of whether your embedded file is an exe or not, I think pretty much any file which is embedded inside the exe can be "exported", that is, written out to disk, and from that point you can do whatever you want with the file. Internal to your application or externally.

There are lots of ways of running an exe where the command originates from VFP, thinks like doing a RUN or a ShellExecute, but I believe in all instances VFP is essentially delegating that task to the Operating System to do the running and for that reason, I agree with Griff, if the OS cannot see the exe (because it is only embedded inside your exe/app) how is it going to execute it?

I don't think you can run an embedded exe from inside a VFP exe without first writing it to disk. Depending on what the execution plan of the exe is, i.e. does it run very quickly and automatically end/quit, you could in theory write the exe out to disk in some temp folder, the user's OS temp folder for example, then run it and when it is finished, delete it, if you don't want the exe to persist. That would be a problem if you can't make your VFP app wait for the external exe and in that case you'd have to schedule a clean up task to run periodically.

If you don't want the exe to persist on disk but your only option is to write it out to disk, then it is always a risk that something stops it being deleted and unless you are routinely cleaning up then it might get left on the disk for a long time or even forever when you don't want it there, but I don't know if you have any other options. I'd be interested, mainly out of curiosity, if anyone does have an alternative solution.

One last consideration I thought of is that Anti Virus (AV) applications scan files like exes to determine if they might be malicious, they look for patterns inside things like exes. I'm not going to state anything categorically but I wonder if embedding an exe inside an exe makes it more likely your exe could be false-flagged as potentially malicious or makes no difference at all. Definitely not a statement, more a pondering. Others, who have more experience of embedding exes inside their VFP exes would have more knowledge of whether it makes any difference in that regard.
 
I would just consider this: Runnable selfextracting archives are... Well, the name already suggests it: self extracting. IIRC it extracts into TEMP and runs one of the files of the archive from there, so it's also not working based on something storing executable bytes into allocated RAM and jump into that.

One thing that's obviously possible in that nature is putting assembly into memory and run it, unless DEP (data execution protection) hinders to do that, which is an anti malware protection mechanism.

I'd also doubt as you say you need to run it with parameters, which come in as arguments (args) into a new process, that this mecahnism can even work without an EXE file. Which means even if you'd work out loading this secondary EXE into your EXEs process, the args it would see are the parameters with which your EXE were started. In short I think the prameterization functionality via args are a per process thing and you'd need to create a new process, you can't run that inside your own process.

Well, and the main Windows API function to create a process - CreateProcess - requires a file. While its major parameter lpApplicationName (name of EXE/CMD/BAT/SYS file) name can be null, the executable then has to be specified in the commandline parameter which also is optional, but becomes mandatory in that case. So one wqay or the other you specify an executable file. CreateProcess does not foresee to create processes from some memory block just refernced by some RAM address.
 
Over on stackoverflow it's suggested to be possible albeit quite complicated.


Before you go into that, it's quite challenging and all in all I'd describe it as hijacking a suspended process, overwriting it with your internal EXE and then resuming. Which means it still won't cover the aspect of starting it with parameters.

I bet you expect a RUN some.exe would also find some.exe when it's embedded inside your exe. I don't think so. There are quite a few things that work along that line, like a picture file embedded being seen by a report or image control or a DBF that can be USEd, but I doubt this mechanism is that general as starting an EXE involves the OS, not just the VFP runtime.
 
Last edited:
I bet you expect a RUN some.exe would also find some.exe when it's embedded inside your exe. I don't think so.
To finally find out or rule out that desirable simple way of embedding an EXE I made a set of two projects to test this hypothesis and indeed the embedded exe is not found by RUN.

A call of RUN inside.exe WITH parameters results in the error "Run|! command failed. The system cannot find the file specified." Which tells that "The system" (Windows) is involved to run the inside.exe and has to find the file. I also tried two start mechanisms based on the VFP command DO. That won't work with non-foxpro EXEs anyway, I only added these tests for sake of seeing if any embedding would work.

I tried DO inside.exe WITH parameters, that leads to a fatal error C5.
I also tried DO main IN inside.exe WITH parameters, which again leads to fatal error C5.

The latter requires a main.prg inside a VFP built exe, obviously, but also the former and more generic DO inside.exe only could work with a VFP built EXE. If you try for sake of testing DO C:\Windows\SysWow64\notepad.exe throws the error "... is not a Visual FoxPro .EXE file."

I don't even try to use a cmd/bat file to start inside.exe, as that also clearly will run from outside and not find the inside file. So there is nothing remaining but the complicated way explained on stackoverflow.

The simple answer is: No. It surely also is the reason why the subbranch of "Applications" in the Code branch of the project manager allows to add EXE or APPs, but you can't unset their "excluded" flag. You may ask why that exists at all, then? Including an APP means the build process is able to find functions in the external APP file and doesn't report errors. Likewise for finding stored procedures in a DBC you add the DBC to the project buit don't embed it. That's the major reason to have these project manager tree branches, besides that this documents what belongs into a project also when it's not embedded.
 

Part and Inventory Search

Sponsor

Back
Top