I want to make an application, but the application will be using icons (bitmaps) for some of the menu buttons and other stuff. I want to keep my application as one simple, single standalone exe file which means I will somehow have to embed all of the icons into the application (EXE on windows) so I can load the bitmaps without having any external files.
Does anyone know how I can do this?
Just some other info:
I'm using wxWidgets, currently with MSVC and I would prefer a method that works cross compiler/cross platform if possible.
Thanks in advance!
You could used the XPM format for your bitmaps, as it's easy to embed in your code (which of course is going to be in the exe, right where you want it;-). As the docs say,
All wxWidgets platforms support XPMs
for small bitmaps and icons. You may
include the XPM inline as below, since
it's C code, or you can load it at
run-time
(the "as below" being a #include directive) -- so, you would be perfectly cross-compiler and cross-platform by adopting this approach with the "include" option.
For more info about the XPM format, see here. It's easy to find converters to XPM from other popular formats, of course.
Windows does have resource files.You could use that. Alternatively you could write a small utility that will convert your binary icon into a C constant array
eg:
const unsigned int my_icon[] = {0x12345678, 0x87654321, .... };
This could easily be done in perl and you can then access the icon with the variable my_icon.
Cause Linux has no platform solution for this you will have to create your own system anyway. So i would recommand against platform specific ways to add resources on windows and macosx.
You can use reswrap which comes with the FOX GUI Toolkit is a simple tool to convert any binary file into c char literals. If you compile with msvc you will soon find that large files with lot of large strings are poison for the compiler. I added about 900 icons for my project and it killed the compiler.
I currently work with a solution where i simply copy a binary archive at the end of the executable. Every platform today can give you the executable path and neither ELF, EXE or Mach-O files care if additional data is added at the end of an executable file.
We use this technique in our projects:
Use optipng ./image.png to optimize your png file.
Convert your binary image data to a text using png2wx Perl script.
Embed your image into the source code this way:
{
wxMemoryInputStream sm("\211PNG\r\n\032\n\000\000....", 116);
m_bitmap = wxBitmap( wxImage(sm) );
}
Do not forget to add the support for the PNG format in your wxApp::OnInit() function:
wxImage::AddHandler(new wxPNGHandler);
Here is the link to original tutorial.
Hope this will help!
Related
Question concerns only Windows for now - other OS's are not so relevant right now.
Just by quick googling - it's possible to load native .dll from RAM, there are for example following libraries:
https://www.joachim-bauch.de/tutorials/loading-a-dll-from-memory/
=>
https://github.com/fancycode/MemoryModule
https://forum.nim-lang.org/t/7943
But all of them requires:
in-depth knowledge of PE file format
mostly those approaches are not debugger friendly.
What I have checked - windows's LoadLibraryA / LoadLibraryW are directed to ntdll.dll / LdrLoadDll - and best picture of how things works can be found from here: https://github.com/hlldz/RefleXXion
And even thus I don't have windows source code - I've checked same functionality from Wine:
LdrLoadDll: https://source.winehq.org/source/dlls/ntdll/loader.c#3169
load_dll: https://source.winehq.org/source/dlls/ntdll/loader.c#3083
load_native_dll:
https://source.winehq.org/source/dlls/ntdll/loader.c#2564
NtMapViewOfSection: https://source.winehq.org/source/dlls/ntdll/unix/virtual.c#4469
find_dll_file: https://source.winehq.org/source/dlls/ntdll/loader.c#3021
open_dll_file: https://source.winehq.org/source/dlls/ntdll/loader.c#2467
Suspect loading dll happens via following function calls:
NtOpenFile, NtQueryAttributesFile, NtCreateSection/NtOpenSection, NtMapViewOfSection (*)
(More information could be found in
https://github.com/Hagrid29/PELoader
https://gist.github.com/bats3c/59932dfa1f5bb23dd36071119b91af0f
https://www.octawian.ro/fisiere/situri/asor/build/html/_downloads/122f95f9a032396603a837c53b125bb8/Russinovich_M_WinInternals_part1_7th_ed.pdf
)
I was also thinking if I could just override NtOpenFile and just redirect file open (in
https://github.com/SegaraRai/PathRedirector manner)
to different path - but main question what is the alternative location where to store file?
I was thinking if NtOpenFile can open even device, then maybe just replace file
with some sort of named pipe (https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipe-client) - but then in maps on how well this will work with NtMapViewOfSection.
Since I was not able to find any working example of such hook or operation (E.g. LoadLibary("\\.\pipe\mynamedpipe_as_dll")) - there is always a risk that such combination is not simply supported.
Is it possible to load native .dll purely from RAM:
Without using file system (not to store .dll e.g. in temporary folder)
Without involving custom drivers (like Dokan) ?
So loaded .dll would be still debugger friendly ?
Not tightly bound to PE file format structures (or use PE structures as less as possible)
If you miss bit more information, check also my own experiments with native dll loading (maybe can give some hints on solving the issue):
https://github.com/tapika/test_native_dll_loading
https://github.com/tapika/test_native_dll_loading/discussions/2
Distinguish between debug and release use cases. In debug, save the DLL in a temp file and load with LoadLibrary, which will enable debugging. In release, run from memory with no capability for debugging.
Here's another idea, from considering the linked Guthub issue. If the purpose is to let the users provide their own compression/decompression logic while building a ReadyToRun executable, let them provide that as a static library (object) as opposed to a DLL. The larger project is already about packaging stuff into a single executable, might do some linking while at it.
Yet another idea would be to let the users provide the codec in some kind of interpreted language and optionally plug in the interpreter that supports debugging. Windows comes with a built-in JavaScript interpreter, look up Active Scripting, and debugging those is a free bonus. The performance probably won't be on par with a native code implementation, though.
I think you could probably do something similar with Frida. Hook the functions LoadLibraryA / LoadLibraryW and reimplement them in Frida. but I don't believe this is something that would be stable for production.
For some reference
By analyzing existing approaches (like PE Loader https://github.com/Hagrid29/PELoader) and using minhook library - I've managed to load .dll from RAM.
I've created git repository with example code on github:
https://github.com/tapika/dllloader
Could you create a ramdisk to put your DLL there? What exactly is the use-case for this? There are a couple ways to spin up a file in RAM, C#'s MemoryMappedFile for example. I'm not sure if this would be debugger friendly.
Im trying to make (what I thought was a simple) extension for Game maker studio 2.
I am restricted to making a DLL app.
I am wondering is there any was to have a dll app open the file explorer have the user locate a file and then return said directory?
I fell like this is a sumb question but one I really need to know the answer too before slaving away coding for hours only to find its not possible.
You do not want to launch the explorer but to open a file dialog that allows the user to select a file.
Depending on the framework you use in your program the solutions may differ.
If you are using Qt framework you may use a QFileDialog for a platform independent mechanism.
If you are okay that it will only works on Windows then you may directly use the WinAPI functions GetOpenFileName or GetSaveFileName (that is a lot easier than the Common Item Dialog that is suggested as replacement on their documentation pages)
On GameMaker terms, you want to use get_open_filename or get_open_filename_ext.
See Dialog Module (marketplace, github) for C++ implementation reference.
I am working on a project in C++ with Eclipse Helios, QT 4.6.1 integration plugin and boost 1.52 libraries. I'd like to extract some information to work with from a xml file and I'm currently doing so by calling boost function const read_xml(std::string &, Ptree &, int = 0, const std::locale & = std::locale()).
The point is that I'd like to avoid final users to access that xml resource from the release folder and I have no idea of how to do it. Is there any (easy) way I could possibly treat that xml content from inside the executable in order to load it into memory and carry on with the rest of the process as I'm already doing with the xml file being treated as a project resource? Any tips would me more than appreciated.
Thanks in advance.
If you want to prevent the users of your program from modifying the XML file, you should use resources, to compile the file inside the executable.
If you are already using Qt, then by all means have a look at qrc in Qt 4.6. Qt provides a nice system independent way of embedding resource files into the executable. If your project is not already using Qt, then you probably don't want to add it just for that.
If you want a Windows-specific resource file, you can have a look at .rc files documentation. To check what was inside compiled resource files, I used ResEdit in the past and found it really useful. You can even create resource files with it.
If you are targeting Mac OS, you probably want to have a look at bundles, which are sort of a directory where you can put your resources. If you sign your application you can prevent the user to modify any file in the bundle (I'm not sure signing it is required though, I don't have much experience on Mac OS development).
And if you are targeting Linux or similar, you can try doing this trick which seems to work quite well.
All these methods aim to only embed your XML file into your executable, so that your users cannot easily modify it (well, in theory it is still possible but Muggles won't be able to do so). Reading the file may depend on the solution you choose. I personally dislike the Windows resource system and use it only when I really have to, avoiding the Win32 API like plague. If you choose to use Qt, it is quite easy to read the file, and you can do it with boost if you want to. Instead of reading the file at "resources/config.xml", you point to the resource file using ":/config.xml". Here would be the resource file:
<!DOCTYPE RCC><RCC version="1.0">
<qresource>
<file>config.xml</file>
</qresource>
</RCC>
Then when you read it, I'm not sure if you have to use a Qt class to access it or not, but even if you do, you can open the file using QFile and call readAll, then use the result with boost:
QFile myConfigFile(":/config.xml");
if (!myConfigFile.open(QIODevice::ReadOnly | QIODevice::Text))
return;
read_xml(QString(myConfigFile.readAll()), [...]);
I haven't tested it but it should work with something like that.
The read_xml is overloaded. You are probably refering to this function:
read_xml(filename ... )
but there is also
read_xml(stream ...)
where stream is any std::istream object produced in any way. You could even have a hard-coded string in your source converted to a stream.
Thanks again for your tip Uflex. The point with my application was using QT but only for the GUI functionality, avoiding its use in the application controller underneath...
I've just checked your approach and it is mostly what I was looking for, except for the last line, since read_xml function accepts strings with the path to the xml file or stringstreams with the content of that xml. So, after combining your explanation with these two links:
How to feed Boost.PropertyTree with a string, not a file?
http://doc.qt.digia.com/4.6/resources.html
we are ready to go...
istringstream ss;
QFile file (QString::fromStdString(pathString));
if(file.open(QIODevice::ReadOnly | QIODevice::Text)){
ss.str(QString(file.readAll()).toStdString());
read_xml(ss, ...)
...
}
What I'm trying to do is to sign my compiled executable's first 32 bytes with a version signature, say "1.2.0" and I need to modify this signature in runtime, keeping in mind that:
this will be done by the executable itself
the executable resides on the client side, meaning no recompilation is possible
using an external file to track the version instead of encoding it in the binary itself is also not an option
the solution has to be platform-independent; I'm aware that Windows/VC allows you to version an executable using a .rc resource, but I'm unaware of an equivalent for Mac (maybe Info.plist?) and Linux
The solution in my head was to write the version signature in the first or last 32 bytes of the binary (which I didn't figure out how to do yet) and then I'll modify those bytes when I need to. Sadly it's not that simple as I'm trying to modify the same binary that I'm executing.
If you know of how I can do this, or of a cleaner/mainstream solution for this problem, I'd be very grateful. FWIW, the application is a patcher/launcher for a game; I chose to encode the version in the patcher itself instead of the game executable as I'd like it to be self-contained and target-independent.
Update: from your helpful answers and comments, I see that messing with the header/footer of the binary is not the way to go. But regarding the write permission for the running users, the game has to be patched one way or another and the game files need to be modified, there's no way to circumvent that: to update the game, you'll need admin privileges.
I would opt for using an external file to hold the signature, and modify that with every update, but I can't see how I can guard against the user spoofing with that file: if they mess up the version numbers, how can I detect which version I'm running?
Update2: Thanks for all your answers and comments, in truth there are 2 ways to do this: either use an external resource to track the version or embed it in the main application's binary itself. I could choose only 1 answer on SO so I did the one I'm going with, although it's not the only one. :-)
Modern Windows versions will not allow you to update an installed program file unless you're running with administrator privileges. I believe all versions of Windows block modifications to a running file altogether; this is why you're forced to reboot after an update. I think you're asking for the impossible.
This is going to be a bit of a challenge, for a number of reasons. First, writing to the first N bytes of the binary is likely to step on the binary file's header information, which is used by the program loader to determine where the code & data segments, etc. are located within the file. This will be different on different platforms (see the ELF format and executable format comparison)--there are a lot of different binary format standards.
Assuming you can overcome that one, you're likely to run afoul of security/antivirus systems if you start modifying a program's code at runtime. I don't believe most current operating systems will allow you to overwrite a currently-running executable. At the very least, they might allow you to do so with elevated permissions--not likely to be present while gaming.
If your application is meant to patch a game, why not embed the version in there while you're at it? You can use a string like #Juliano shows and modify that from the patcher while the game is not running - which should be the case if you're currently patching anyways. :P
Edit: If you're working with Visual Studio, it's really easy to embed such a string in the executable with a #pragma comment, according to this MSDN page:
#pragma comment(user, "Version: 1.4.1")
Since the second argument is a simple string literal, it can be concatenated, and I'd have the version in a simple #define:
// somehwere
#define MY_EXE_VERSION "1.4.1"
// somewhere else
#pragma comment(user, "Version: " MY_EXE_VERSION)
I'll give just some ideas on how to do this.
I think it's not possible to change some arbitrary bytes in the executable without side effects. To overcome this, I would create some string in your source code, like:
char *Version = "Version: AA.BB.CC";
I don't know if this is a rule, but you can look for this string in your binary code (open it in a text editor and you will see). So, you search and change this bytes for your version number in the binary file. Probably, their position will vary each time you compile the application, so this it is possible only if that location is not a problem for you.
Because the file is being used (it's running), you have to launch an external program that would do this. After modifying the file, this external program could relaunch the original application.
The version will be stored in your binary code in some part. Is that useful? How will you retrieve the version number?
So, how to do it?
How to pack files to self-extracting_archive. What is algorithm?
You can create self-extracting archives for windows with 7-zip, if you want to create them programmatically you can use the SDK.
If you're more interested in ways to implement this yourself: you could have a statically linked application which has the compressed data linked into the executable (as a resource, for instance - for smaller archives a plain static const char data[] array might be sufficient). At runtime, you feed the data to a decompression library which then actually extracts files.
To keep the overhead of the executable small, I'd try to use system API (e.g. plain WIndows controls on Windows) a possible so that you don't have to link in a toolkit. Also, for the decompression, I would use bzip2 since it provides a good compromise between compression size and decompression speed. You might also want to look at minilzo since it has a smaller code footprint than bzip2 (so the executable file is smaller) and a much higher decompression speed - it doesn't compress as well though.
A self extracting archive is just some extractor program, but instead of taking it's data from an archive file it takes it from constants defined in the program itself. That is really something very simple at conceptual/algorithmic level.
If you don't care about size you can have something as simple as below (exemple in python to keep it simple, an actual unarchiver will probably be a compiled program from C or C++ source):
hello_prog = """print "Hello, World"\n""";
f = file("./hello.py", "w");
f.write(hello_prog);
f.close();
when you run it it creates a file hello.py that is also a python executable.
But when actually creating an auto-extracting archive, you usually want the internal data to be compressed to make the whole archive as small as possible. You also want to keep the extractor program as small as possible and also as independant as possible of what is already available on the target system... and that's where the problems really begin.