How to Open an .Exe from Another C++ .Exe

Run exe from another exe

cd is a "shell" command, not a program that can be executed.

So to apply it run a shell (cmd.exe under windows) and pass the command(s) you want to execute.

Do to so m Make the content of winCommand look like this:

cmd.exe /C "cd/D N:\folder0\folder1\folder2\foldern && pdftotext.exe data.pdf -layout -nopgbrk"

Please note that changing the drive and directory only applies to the environment used by cmd.exe. The program's drive and directory stay as they were before the call to system().


Update:

Looking more closely at the error message one notices the "sh: ...". This clearly indicates system() does not call cmd.exe, because it most likley would not prefix an error message like this.

From this fact I dare to conclude the code shown is called in and runs under Cygwin.

The shell(s) provided and used by Cygwin do not know the windows specific option /D to the shell command cd, thus the error.

As however the shells used by Cygwin can call cmd.exe my orignally provide approach works, although the explaination I gave is wrong, as pointed out by pmg's comment below.

Run a Exe from another exe

Consider a third application, which you launch from your first app. The third one checks to be sure the first one has terminated, then launches the second app and terminates itself. I have had to do this in the past; it works fine.

How to execute another exe from a C++ program in Windows

you can use the system function

int result = system("C:\\Program Files\\Program.exe");

run external .exe via c++

rt.c_str() should be the first parameter in CreateProcess().

Moreover, you are mixing ANSI and Unicode. You are clearly compiling for Unicode, where CreateProcess() maps to CreateProcessW(). std::string contains char data, so c_str() returns a const char * pointer, but CreateProcessW() is expecting a wchar_t* pointer instead. Casting with (LPWSTR)rt.c_str() will simply hide the compiler error, but it doesn't fix the actual problem of you passing ANSI data where Unicode data is expected.

Use a wide string instead when declaring Unicode strings (Note the L prefix):

std::wstring rt = L"C:/IPSE_temp/CEA_schwing.exe";
if (CreateProcess(rt.c_str(), NULL, NULL, NULL, TRUE, 0, NULL, NULL, &info, &processInfo))
...

That works because rt.c_str() is now compatible with the first parameter of CreateProcess(), which is an LPCWSTR and will accept a const wchar_t * pointer from c_str() (the second parameter does not accept a const pointer).

Alternatively, you can declare wchar_t buf[MAX_PATH] and use it as the second parameter in CreateProcess(), which is of type LPWSTR (non-const):

wchar_t buf[MAX_PATH];
wcscpy_s(buf, L"C:/IPSE_temp/CEA_schwing.exe");
CreateProcess(0, buf, ...);

You can also set the working directory in the 8th parameter:

wchar_t buf[MAX_PATH];
wcscpy_s(buf, L"C:\\IPSE_temp\\CEA_schwing.exe");

std::wstring dir = L"C:\\IPSE_temp";
CreateProcess(0, buf, NULL, NULL, TRUE, NORMAL_PRIORITY_CLASS, NULL, dir.c_str(), &si, &pi);

How to embed an exe file into another exe file as a resource in C++?

If your #define is already in resource.h, there is no need to duplicate it in your source code. Just use #include "resource.h" in your code instead.

In any case, you should be using the pre-defined RCDATA resource type, instead of creating a custom BINARY type.

That being said, your use of ofstream and system() are both wrong. You are passing them the resource's raw binary data, but they are expecting a file path instead. You are using a file path in your .rc file to specify the file whose binary data is copied into the resource. The resource does not contain that file path, as you are clearly expecting.

Try this instead:

resource.h

...
#define IDB_EMBEDEXE 52
...

Resource.rc

#include "resource.h"
...
IDB_EMBEDEXE RCDATA "C:\\Users\\Almohandis\\source\\repos\\Project7\\sum2num.exe"
...

Source.cpp

#include <Windows.h>
#include <iostream>
#include <fstream>
#include <string>
#include <cstdio>
#include "resource.h"
using namespace std;

int main() {

HRSRC hResource = FindResource(NULL, MAKEINTRESOURCE(IDB_EMBEDEXE), RT_RCDATA);
if (!hResource)
return 1;

HGLOBAL hGlobal = LoadResource(NULL, hResource);
if (!hGlobal)
return 2;

DWORD exeSiz = SizeofResource(NULL, hResource);
if (!exeSiz)
return 3;

void* exeBuf = LockResource(hGlobal);
if (!exeBuf)
return 4;

char tempPath[MAX_PATH] = {};
if (!GetTempPathA(MAX_PATH, path))
return 5;

string fullPath = string(tempPath) + "sum2num.exe";

ofstream outfile(fullPath.c_str(), ios::binary);
if (!outfile.is_open())
return 6;

int res = (outfile.write((char*)exeBuf, exeSiz)) ? 0 : 7;
outfile.close();

if (res == 0) {
system(fullPath.c_str());
}

remove(fullPath.c_str());

return res;
}

Running C Built .exe On Another PC

If you pick the right CPU target (Project Configuration Properties -> C/C++: Enable Enhanced Instruction Set) such that the binary code doesn't include instructions understood by only a very narrow subset of CPUs, and the default for Visual Studio is to use instructions that are supported by the widest set of x86 or x64 CPUs, then your program will run on almost any Windows computer. You need to distribute any DLLs that aren't part of the base Windows installation though, which includes any additional dynamically linked language runtimes such as the Visual C++ runtime.

A good way to derive the list of DLLs that you have to package with your executable is to create a virtual machine with a fresh Windows installation without any development tools in it and then try to run your code there. If you get an error for a missing DLL, add it and repeat. When it comes to the Visual C++ runtime, Microsoft provides installable packages for the different versions that you are allowed to distribute as part of your installation (Visual C++ Whatever Redistributable Package).

Also, mind that programs compiled for 32-bit Windows will mostly run on 64-bit versions, but the opposite is not true.

How do I open an external EXE file inside of C?

Please try system("notepad"); which will open the notepad executable. Please note that the path to the executable should be part of PATH variable or the full path needs to be given to the system call.



Related Topics



Leave a reply



Submit