how to call from an exe file another exe file 3

[Ernesto_Paez]

Hi everyone,
excuse me for the question but better ask than fail
i need to put a shortcut on each computer, and that will call an exe vfp appl(located in the server) but of course the shortcut will show the path, i just don't want to show the path there.
so i was thinking , if i create a prg file, locate it in another network drive and the make this an exe file but allow this one to call my initial exe file application, then the path shown it is the for the exe file that is calling the other exe file which is the one i don't want then to see the path.
ok can i call from and exe file, another exe file ? if so can anyone shows here how ?
Thanks

 

[Olaf Doschke]

Why do you want to hide the location of the EXE? Any shortcut to applications within the Start menu "reveals" the location of executables.

Want to prevent users starting an EXE within the network location? Then simply go with the old solution of setup disks using changed file extensions, eg EX_ instead of EXE, combined with limiting user permissions to read/copy the file only - to allow them to copy to the local app installation folder, via this CMD batch file:

c:
cd apps\myapp
IF EXIST myapp.exe ren myapp.exe myapp.ex_
robocopy /MIR \\share\apps\myapp\ c:\apps\myapp
IF EXIST myapp.ex_ ren myapp.ex_ myapp.exe
start /b myapp.exe

So you put myapp.exe renamed to myapp.ex_ into a setup folder in a network share. You include this cmd file in there or anywhere else shared, too and give users a shortcut to the cmd. Permissions set to execute that cmd only, nothing else. You put all accompanying files besides that EX_ and so after the full directory is mirrored to a local installation folder and the EX_ is renamed to EXE, it is started.

I suggested that at the end of thread184-1762130

The general idea is not to hide file locations but limit permission to what users need. Security through obfuscation is no security. Instead, think about file permissions and restrictions to control what users are able to do with the files. Whatever permissions you give to the files in the setup share is inherited by the copy.

Bye, Olaf.

 

[Mike Lewis]

Olaf has given you a good answer.

However, to answer your basic question, there is no reason why an EXE can't call another EXE. It's not at all unusual.

The simplest way to do it is to use ShellExecute(). If you don't know how to do that, see:

http://www.ml-consult.co.uk/foxst-26.htm

And in case you don't have time to read that page, here is a summary:

At the start of the program, do this:

DECLARE INTEGER ShellExecute IN shell32.dll ; 
  INTEGER hndWin, ; 
  STRING cAction, ; 
  STRING cFileName, ; 
  STRING cParams, ;  
  STRING cDir, ; 
  INTEGER nShowWin

Then, to call the subsidiary EXE:

cFileName = "c:\Program Files\MyProgram.Exe" 
cAction = "open" 
ShellExecute(0,cAction,cFileName,"","",1)

Be aware that the first program (the one containing the above code) will continue to execute after calling the second one. You will probably just want to let it run off the end.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Ernesto_Paez]

Hi Olaf, Mike
Thanks for the advise.
Mike this solution is great, the only problem i have is when the first exe file execute, if ask for Run or Cancel, that is ok, then it calls the second exe file, then in the screen appears a second window asking to Run or Cancel again and this, is the window, that will run the actual application and still shows the path of the second exe file, is there anyway from the first exe file, to run the second exe file w/ showing the "run or cancel" pop window ?

Please see the picture, i need to hide that as well
Thanks

 

[Ernesto_Paez]

oh don't worry, i got it, what happened was that i ran this test on a win xp machine and that gave me that popup window.
Thanks to both of you

 

[Olaf Doschke]

OK, in regard of starting another EXE I'd use [tt]RUN /N E:\path\to\another.exe[/tt]

Bye, Olaf.

 

[Ernesto_Paez]

Hey Olaf,
Thanks so much but i thou that maybe "RUN /N E:\path\to\another.exe" this won't fine as both exe files were done using vfp 9.0, i do not mean is wrong, i meant that maybe that approach was not right, i new about it but i was not sure about it. thanks

 

[Olaf Doschke]

No, it does not matter at all what EXE you run, whether compiled in VFP or not. The OS will create a new process for it and that will start up whatever runtime is necessary, that's all simply self-contained. You can run as many VFP EXEs and C++, .NET, Pascal, Delphi or whatever EXEs, your limit are resources, but of course, any runtime, no matter what, can run multiple times.

The RUN command help topic has the notice: Include /N to execute another Windows-based application. And VFP EXEs are Windows-based applications. The contrast would be DOS EXEs, but it doesn't make any restrictions on what EXE. Just notice: We have 2017 and almost all EXEs are now Windows applications EXEs. RUN without /N often is used to start Shell commands/ DOS commands, which makes RUN pass in whatever you run as a parameter of cmd.exe, and /N makes a difference to simply opening the specified file.

Bye, Olaf.

 

[Mike Lewis]

When it comes to launching EXEs, there's very little difference between RUN and ShellExecute(). They both offer similar features, and they both give the same results. The main difference is the ShellExecute() can "execute" lots of things other than EXEs. For example, it can open or print documents, play sound files or videos, launch web pages, or open a folder window.

The article I linked to will give you some ideas.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, you can also RUN a doc, for example. It's not wrong to know ShellEeceute, as its cAction parameter allows other actions than the default "open" and indeed the major purpose of RUN is to RUN something. The option with most possibilities is using the CreateProcess API function, as it also allows to Wait for the finish of the called new process, for example. If you ever would be interested in that level of control about the newly spawned process, including to get its exit code, take a look at

http://fox.wikis.com/wc.dll?Wiki~ProcessExitCode.

You can observe the rule, more capabilities mean more complex code concerned with more details hidden with simpler API calls or commmands.

Bye, Olaf.

 

[Tore Bleken]

If your want an exe created with VFP to start another exe created with VFP, the first exe can simply [pre]Do Exe2.exe[/pre]
No reason to use Run or ShellExecute in this case.

 

[Mike Lewis]

Well, ShellExecute() has a couple of advantages over DO Exe2.exe:

With ShellExecute(), you can control the initial state of the EXE's window (normal, maximised, hidden, etc).

Also, ShellExecute() will return a value that tells you if it succeeded, and if not, why not. That's more useful than simply error-trapping a DO command.

Admittedly, these points might not be relevant in this particular case, but they are worth keeping in mind.

Also, if you use DO, isn't the processing asynchronous? Does the calling program suspend until the called program finishes? I'm not sure about that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Thanks, Tore, I always forget that aspect of DO. If you don't specify a file extension, DO even looks for an EXE file first.

There is a small and a big difference, for the small difference just try [tt]DO notepad[/tt] and [tt]RUN /N notepad[/tt]

And now about the big difference. Make this PRG the main.prg of an executable:

LPARAMETERS tlStop

LOCAL lcThis, lcLogtext
lcThis = SYS(16,0)

lcLogtext = TEXTMERGE("Process <<_vfp.ProcessId>>, Thread <<_vfp.ThreadId>>")
STRTOFILE(lcLogText+CHR(13)+CHR(10),"log.txt",1)

IF NOT tlStop
   lcLogtext = "Starting Self with Stop Flag..."
   STRTOFILE(lcLogText+CHR(13)+CHR(10),"log.txt",1)
   DO (lcThis) WITH .T.
   lcLogtext "Coming back from DO")
   STRTOFILE(lcLogText+CHR(13)+CHR(10),"log.txt",1)
ELSE
   lcLogtext = TEXTMERGE("Stop here.")
   STRTOFILE(lcLogText+CHR(13)+CHR(10),"log.txt",1)
ENDIF

You will see that DO will not cause a new processid or threadid. That could be used, but normally is not what you want, after you DO an EXE your starter/launcher EXE you will want to either quit it or let it continue running its own business, which it can't, as it needs to wait for the EXE called with DO to exit.

The /N in RUN /N also stands for NOWAIT, it creates a new process and continues the calling EXE right away. You can double check by making a longer pause before logging the "Stop here" and log that with DateTime. You'll see it will be put into the log before "Coming back from Do".

That's why RUN is better than DO in that respect; you don't want a launcher/startup EXE to run instead of the final EXE.

Apart of that, landfla, the end users will find out which EXE you started by looking into task manager. When you add columns to the details tab/view of the task manager you can see the path and even command line parameters passed to any process. To hide that from users, you'd need the restrict users.Not sure if you really could. Perhaps in specific Windows versions for POS or embedded.

On the other side, this hides that EXE from the task manager, you should ensure you CD into the target EXE folder, though. I still stand by the recommendation to not use obfuscation for security or copy protection. In the end, the necessary start path is clear text within the launcher EXE file itself.

Bye, Olaf.

 

[Ernesto_Paez]

Thanks to all for the input