I wrote a c++ program and I want to execute my second program inside it, which is a exe file. The problem is I want to share my program to others as one single file.
When I search on the internet, I found this solution.
Just store the second .exe file as a binary resource inside the main
.exe using an .rc file at compile-time. At run-time, you can access it
using FindResource(), LoadResource(), and LockResource(), and then
write it out to a temp file on disk before passing it to system().
But I don't understand how to "store the .exe file as a binary resource"
I am currently using CreateProcess() to start my second program which working greatly.
Can anyone write some example for me?
In your project's resource script (the .rc file in which icons, dialogs, etc. are defined), you can add a binary resource with a line like the following:
IDB_EMBEDEXE BINARY "<path>\\EmbedProgram.exe"
Where the IDB_EMBEDEXE token/macro should be defined in a header file that is included by both that resource script and any C++ source(s) that use(s) it; this will be the lpName argument given to the FindResource() call, which you can form using MAKEINTRESOURCE(IDB_EMBEDEXE). Specify "BINARY" (or L"BINARY" for Unicode builds) for the lpType argument.
Like this:
#define IDB_EMBEDEXE 13232 // Or whatever suitable value you need
//...
// In the C++ code:
HRSRC hResource = FindResource(NULL, MAKEINTRESOURCE(IDB_EMBEDEXE), _TEXT("BINARY"));
HGLOBAL hGlobal = LoadResource(NULL, hResource);
size_t exeSiz = SizeofResource(NULL, hResource); // Size of the embedded data
void* exeBuf = LockResource(hGlobal); // usable pointer to that data
// You can now write the buffer to disk using "exeBuf" and "exeSiz"
The specified executable file will then be completely embedded (as a binary) resource in your built executable, and can be extracted, written to disk and executed as described in the article you quote.
Related
I'm trying to compile some png's into a RES file, which then will be compressed with zlib. In my main program, I want to decompress the RES file, store it in memory, and start using resources compiled within it. Normally I would use
FindResource(NULL, ...);
to find a resource embedded in my .exe file. But now the resource file resides in a memory buffer, to which the pointer I have. Is it possible to use FindResource with such a pointer, or does it work only with files?
Is it possible to do this: (for educational purpose).
suppose I have a image file "image.jpg"
I want to create a program when it executes it should create this image. That means the data of the image is stored in the exe. Is this possible to do?
Something like this: link the image file from resource.rc then tell the compiler to get the data and store it (something like this unsigned char data_buffer[]="binary data of the image" then when the program is executed I can write this data to a file)
(I'm using C++ with mingw compiler)
Any help is highly appreciated.
There are several options:
1) Add it as a byte array in a source file. It is trivial to write an auxiliary program that reads the bytes from the files and writes the C source. E.g.:
data_jpg.c:
unsigned char data_jpg[] = {1,2,3... };
data_jpg.h:
extern char data_jpg[];
const size_t data_jpg_size = 1000;
2) Add it as a binary resource to the executable. You said "exe", did you? So you are likely on Windows. Window EXE files can have binary resources, that can be located using the resource API. See the FindResource, LoadResource and GlobalLock, functions.
resource.rc
ID_DATA_JPG FILE "data.jpg"
3) Convert the binary file directly into a OBJ file and link it into the executable. In the old good days of turbo-c used to be a BINOBJ tool for that. And GNU tools can do it, AFAIk, but with MS tools, I really cannot tell.
With a PE file, you can add data(include bin data) to the PE file's tail as your resource. You just remember the PE file's size. But I'm not sure of that whether you need change the PE's checksum. And use VC++ Compiler to embed resources would be pretty much easy.
I have two problems, the first has been solved.
Current problem
If I embed a file that requires a library to load it, such as a jpeg image or a mp3 music, I will need to use the file as input to the library. However, each library is different and uses a way to get a file as input, the input may be the file name or a FILE* pointer (from libc's file interface).
I would like to know how to access an embedded file with a name. It will be inefficient if I create a temporary file, is there another way? Can I map a file name to memory? My platforms are Windows and Linux.
If show_file(const char* name) is a function from a library, I will need a string to open the file.
I have seen these questions:
How to get file descriptor of buffer in memory?
Getting Filename from file descriptor in C
and the following code is my solution. Is it a good solution? Is it inefficient?
# include <stdio.h>
# include <unistd.h>
extern char _binary_data_txt_start;
extern const void* _binary_data_txt_size;
const size_t len = (size_t)&_binary_data_txt_size;
void show_file(const char* name){
FILE* file = fopen(name, "r");
if (file == NULL){
printf("Error (show_file): %s\n", name);
return;
}
while (true){
char ch = fgetc(file);
if (feof(file) )
break;
putchar( ch );
}
printf("\n");
fclose(file);
}
int main(){
int fpipe[2];
pipe(fpipe);
if( !fork() ){
for( int buffsize = len, done = 0; buffsize>done; ){
done += write( fpipe[1], &_binary_data_txt_start + done, buffsize-done );
}
_exit(0);
}
close(fpipe[1]);
char name[200];
sprintf(name, "/proc/self/fd/%d", fpipe[0] );
show_file(name);
close(fpipe[0]);
}
The other problem (solved)
I tried to embed a file on Linux, with GCC, and it worked. However, I tried to do the same thing on Windows, with Mingw, and it did not compile.
The code is:
# include <stdio.h>
extern char _binary_data_txt_start;
extern char _binary_data_txt_end;
int main(){
for (char* my_file = &_binary_data_txt_start; my_file <= &_binary_data_txt_end; my_file++)
putchar(*my_file);
printf("\n");
}
The compilation commands are:
objcopy --input-target binary --output-target elf32-i386 --binary-architecture i386 data.txt data.o
g++ main.cpp data.o -o test.exe
On Windows, I get the following compiler error:
undefined reference to `_binary_data_txt_start'
undefined reference to `_binary_data_txt_end'
I tried to replace elf32-i386 with i386-pc-mingw32, but I still get the same error.
I think that for this to work with MinGW you'll need to remove the leading underscore from the names in the .c file. See Embedding binary blobs using gcc mingw for some details.
See if using the following helps:
extern char binary_data_txt_start;
extern char binary_data_txt_end;
If you need the same source to work for Linux or MinGW builds, you might need to use the preprocessor to have the right name used in the different environments.
If you're using a library that requires a FILE* for reading data, then you can use fmemopen(3) to create a pseudofile out of a memory blob. This will avoid creating a temporary file on disk. Unfortunately, it's a GNU extension, so I don't know if it's available with MinGW (likely not).
However, most well-written libraries (such as libpng and the IJG's JPEG library) provide routines for opening a file from memory as opposed to from disk. libpng, in particular, even offers a streaming interface, where you can incrementally decode a PNG file before it's been completely read into memory. This is useful if, say, you're streaming an interlaced PNG from the network and you want to display the interlaced data as it loads for a better user experience.
On Windows, you can embed custom resource into executable file. You would need a .RC file and a resource compiler. With Visual Studio IDE you can do it without hassle.
In your code, you would use FindResource, LoadResource and LockResource functions to load the contents into memory at runtime. A sample code that reads the resource as long string:
void GetResourceAsString(int nResourceID, CStringA &strResourceString)
{
HRSRC hResource = FindResource(NULL, MAKEINTRESOURCE(nResourceID), L"DATA");
HGLOBAL hResHandle = LoadResource(NULL, hResource);
const char* lpData = static_cast<char*> ( LockResource(hResHandle) );
strResourceString.SetString(lpData, SizeofResource(NULL, hResource));
FreeResource(hResource);
}
Where nResourceID is the ID of resource under custom resource type DATA. DATA is just a name, you may choose another name. Other in-built resources are cursors, dialogs, string-tables etc.
I've created a small library called elfdataembed which provides a simple interface for extracting/referencing sections embedded using objcopy. This allows you to pass the offset/size to another tool, or reference it directly from the runtime using file descriptors. Hopefully this will help someone in the future.
It's worth mentioning this approach is more efficient than compiling to a symbol, as it allows external tools to reference the data without needing to be extracted, and it also doesn't require the entire binary to be loaded into memory in order to extract/reference it.
Use nm data.o to see what it named the symbols. It may be something as simple as the filesystem differences causing the filename-derived symbols to be different (eg filename capitalized).
Edit: Just saw your second question. If you are using threads you can make a pipe and pass that to the library (first using fdopen() if it wants a FILE *). If you are more specific about the API you need to talk to I can add more specific advice.
Am working in VC++ 2008 (express) and I would like to write something in C that creates an "empty" exe that I can later call LoadLibrary on and use BeginUpdateResource, UpdateResource, EndUpdateResource to modify the contents.
Just writing a 0-byte file doesn't allow me to open it with LoadLibrary because it isn't a resource.
You can compile an empty .exe file with, for example,
int main() { return 0; }
and use it as a template. (Or an empty .dll, whatever)
The .EXE format is a complicated file format. It has a bunch of required headers just to describe its basic execution properties (16 bit, 32 bit or 64 bit, and DOS/Win16/Win32/Win64 mode and EXE versus DLL). After that, it has to have a correct table for address relocations. Its not trivial, and you have do some amount of research into the .EXE file format to do this properly.
"Creating" an exe is something the compiler is very good at. So why not have the compiler create the executable you want, and use that file (or a binary representation of it's contents) to copy around?
I've been working on testing a few things out using SFML 1.4 (Simple and Fast Multimedia Library) with C++ and Visual C++ 2008 Express Edition. To avoid having external images with my graphical programs, I was testing out the sf::Image::LoadFromMemory(const char * Data, std::size_t SizeInBytes) function with Bitmap resources loaded using a simple resource script:
IDB_SPRITE BITMAP "sprite1.bmp"
In my code to load the image to create an sf::Image using this bitmap resource, I use the following procedure, consisting of Win32 API functions (I've excluded the code that checks to make sure the Win32 functions don't return NULL to shorten this a bit):
HRSRC hResInfo = FindResource(NULL, MAKEINTRESOURCE(IDB_SPRITE), RT_BITMAP);
HGLOBAL hResData = LoadResource(NULL, hResInfo);
char * resourceData = reinterpret_cast<char *>(LockResource(hResData));
After that, I use the sf::Image::LoadFromMemory function:
MyImage.LoadFromMemory(resourceData, SizeofResource(NULL, hResInfo));
However, this doesn't work (I get an unknown file type error). After some testing, I discovered that the bitmap data I pass to the LoadFromMemory function does not include the BITMAPFILEHEADER (the first 14 bytes), and I believe this is the cause of the unknown file type error.
I can restore the BITMAPFILEHEADER manually and get the LoadFromMemory function to work fine. However, I'm wondering if there is some way to preserve the BITMAPFILEHEADER in the resource data to avoid doing this?
Using a custom resource type will preserve the entire file. Change the resource script to utilize the RCDATA type as opposed to the BITMAP type:
IDB_SPRITE RCDATA "sprite1.bmp"
In the FindResource function call, use RT_RCDATA instead of RT_BITMAP:
HRSRC hResInfo = FindResource(NULL, MAKEINTRESOURCE(IDB_SPRITE), RT_RCDATA);
For more information:
RCDATA Resource
Resource Types
You can add file to resources as a custom resource instead of RT_BITMAP -- this will add file exactly as it is. Unless you also need to ::LoadImage() it.