I am trying ti make my own packer, and my packer works fine with executable compiled VC++ 6, but when I try to pack executable compiled with VC++ 8, the executable will crash.
So I wanted to know if there is any change in the PE structure in the new versions of C++?
There has been no change to the PE File format, and as commenters above point out it is not related to your problem.
It sounds like your packer is dependent on the VC++6 runtime libraries and as such when it unpacks something that is expecting VC++8 libraries bad things happen. The solution would be to make your packer runtime library independent.
BigBoote's "How to write your own packer" addresses this and suggests implementing your own trivial runtime.
http://www.stonedcoder.org/~kd/lib/61-267-1-PB.pdf
Related
An error related to protobuf3
I have a project that have an c++ executable core, and several shared objects (.so, .dll) called plugins. When the core launches, it will load those plugins with dlopen. The core and plugins using protobuf as communication protocol, so they have to compile the generated .pb.cc and .ph.h files into their binaries to have the copy of the serializer/deserializer. And libprotobuf.so link to both the core and plugins. When I launch the core, it crushes with error: file already exists in database, same error in #863
I'm using protobuf-3 beta2, and Ubuntu 14.04. This error only happens on Linux. The program works fine on Windows and OS X.
I have also tried another way which compile all the generated protobuf files into a dynamic library (protocol.so), then the core and plugins were linked to protocol.so and libprotobuf.so. This works fine. Of course, because in #1062 the bug has been fixed. But when I changed the protocol.so into protocol.a, it failed again. I think it is same as compile generated .pb.cc separately.
I don't want to compile a protocol.so, because it is inconvenient for me to extend the communication protocol when I add more and more plugins. I think compile the generated .pb.cc into the plugin's binary is better (this work well on windows and OS X).
Any suggestions to fix this error are appreciated.
The problem happens when you have multiple compiled copies of the same .pb.cc file sharing a single copy of libprotobuf.so. There are two ways to avoid this:
The way you already found: factor out the .pb.cc files into a shared library.
Link a separate copy of libprotobuf into each plugin. You'll need to use static linking for this library, i.e. use libprotobuf.a rather than libprotobuf.so. Note that with this option, it is unsafe to pass a pointer to a protobuf class between the plugins and the base application, because they are using separate copies of the protobuf library, which can lead to crashes. You will have to pass serialized messages as byte blobs instead. Luckily, that's the whole point of protobuf.
I was able to get around this problem by adding RTLD_GLOBAL to dlopen which takes existing known symbols into account.
I solved this problem by adding RTLD_DEEPBIND to dlopen.
In my case, I was getting the "File already exists in database" error when trying to run a plugin in Gazebo with the tutorial project.
I was able to solve this by copying the .so file to my local directory where I was trying to launch the program instead of setting a GAZEBO_PLUGIN_PATH variable to the build directory.
I hope a similar solution will work for others when facing problems other than Gazebo plugins. (maybe the general solution is to copy your .so file to the local instead of build)
I have, after some effort, successfully built a little piece of example code and make it run. I am using C++ in CodeBlocks 13.12 on a Win 7 x64 machine. The program makes use of wxWidgets and OpenGL libraries.
The problem is, that in order to make the EXE run successfully, I had to copy these DLL files to the location of EXE :
wxbase30ud_gcc481TDM.dll
wxmsw30u_core_gcc481TDM.dll
wxmsw30u_gcc48.dll
wxmsw30ud_core_gcc481TDM.dll
wxmsw30ud_gl_gcc481TDM.dll
I would like to know how to build the program ( what settings to change in project) so that the EXE file will be able to run on its own ( and also on other machines ) - without "missing DLL" error messages ? It would be nice if answer could be general and useful as a reference in future, similar issues.
In the linker, you could add lines similar to this one:
-static wxbase30ud_gcc481TDM
However, this isn't terribly effective or good practice. Better would be to go ahead and include the dll's with your .exe, and simply supply a shortcut to your program that the user could move anywhere. This allows you to install and keep all your program files together, but still let the user only worry about one for the entire thing.
You could use something like Enigma Box, which packs the DLLs into an exe and if you call LoadLibrary it will function as expected:
http://enigmaprotector.com/en/about.html
Some others exist like ILMerge or XBundler I heard as well... haven't used them though. I heard DLLPack too.
I have read these two SO questions: Which runtime libraries to ship? and License of runtime libraries included in GCC? - both were very helpful but not quite what I was looking for.
I have always just written programs for use on my own machine, which has never caused me any problems, but now I want to start running software on other machines and I'm wary of the runtime requirements.
EDIT: See below example instead, this was misleading.
Specifically, if I write a C++ program on a Windows machine, compiled with gcc through MinGW, and want to run it on another machine:
Do I have to send the libstdc++.dll with my program?
Is this single file (I assume placed in the executable's directory) sufficient to allow the program to run?
Also, an identical example, except this time it is an Objective-C program. Is sending the libobjc.dll file to the other machine sufficient to allow the program to execute properly?
I am used to running programs on machines which have developer tools, etc, installed, but now I'm looking to run them on general purpose machines (friends', colleagues' etc), and I'm not quite sure what to do!
EDIT: In response to edifice's answer, I feel I should clarify what it is I'm looking for. I know how to identify the necessary DLL(s) (/dylibs, etc) that my programs use, (although I am accustomed to doing that work manually; I had not heard of any of the tools). My question was more "What do I do now?"
A more general example is probably needed:
Let's say I have written a program which has object files derived from C++, C and/or Objective-C(2) code. I have used some Windows API code which compiled successfully using MinGW's gcc. I also have a custom DLL I wrote in Visual Studio (C++).
I have identified which DLL's my program will use at runtime (one of which may be GCC's libobjc.dll, I'm not sure if this would/should make a difference on a Windows machine, but I want to make this as general as possible) - The "prerequisite DLLs".
I would like to run it on my colleagues' computers, most of which run Windows 7, but some now run Windows 8. Starting at the very start for the sake of completeness:
Do I need to transfer the prerequisite DLLs to my colleagues' computers?
What directory should I place them in? (exe directory / a system directory?)
Once in place, will the presence of these DLLs allow the program to execute correctly? (Assuming it knows where to find them)
Are there any other files that should be transferred with the DLLs?
Basically I'm trying to determine the entire thought-process for developing and running an application on another machine in terms of system runtime requirements.
When loading DLLs, the first place Windows looks is the directory that the exe is in. So it will probably work just fine to put the DLLs there.
For the Microsoft DLLs though, I think it makes more sense to ask your colleague to install the Visual C++ runtime, which is a redistributable package from Microsoft. Ideally you would make an installer using something like WiX and it would install that prerequisite for you, but it is OK to just tell your colleague to do it.
Be sure to include a license file with your software if you include DLLs from gcc, because the GPL requires it.
libstdc++ isn't necessarily sufficient. You almost certainly need libgcc too, but actual dependencies are liable to vary with your particular application.
The best way to determine what you need to ship with your application is to load your EXE into a program like Dependency Walker.
Just as an example, I've compiled a test C++ program which simply prints a std::string. As you can see, it depends directly on two modules other than those that come with Windows; libgcc_s_dw2-1.dll in addition to libstdc++-6.dll.
You should remember to expand the tree under each DLL to make sure that it itself doesn't have any other dependencies (if A depends on B, B might depend on C even if A doesn't directly depend on C).
If you're worried and want the strongest assurances, you could install Windows into a virtual machine (VirtualBox is free) and test your application inside it. If you use Microsoft APIs, you may wish to check the MSDN documentation to see with what version of Windows they were introduced and ensure that it aligns with your target minimum Windows version.
Update: As xtofl points out this won't cover libraries loaded dynamically using LoadLibrary. If you want to cover this base, use Process Monitor to examine what DLL files are touched when you run the application. (Add an 'Image Path' criterion with the path to your EXE in order not to get flooded.) This has the added advantage that it covers all files, registry entries, etc. that your application depends on, not just DLLs.
I am a Java programmer and have come across a very nasty situation. For POC purposes, I need to write down a small segment of my solution that will run as a standalone application doing something very specific.
I have 2 questions:-
I can write the code, but what I don't know is how do I create an installer and exe out of that C++ code.
Secondly, I need to parse a sqlite db file and show its data in the application. Is there a sqlite windows dll or some C++ library or something that I can use, instead of asking the user to install sqlite (or doing it myself through the installer)? So basically, I don't want an extra program to be pushed in, just a dll or some C++ library..
Please let me know if you have an answer to either or both the issues that I'm facing.
Thanks
Compiling your code will turn it in to an executable. For distribution, you'll want to build it in Release mode. I'm not sure what version of Visual Studio you are using, but you might have a "Setup and Deployment" Project type which will enable you to create an installer. Failing that, you may have to look at InstallShield or a tool like that to ensure that the installer has all necessary files (such as the runtime libraries).
SQLLite is called light for a reason! The source code for it can be incorporated directly in to your project and compiled alongside the rest of the files (see: http://www.sqlite.org/selfcontained.html ). This means no external libraries are necessary to link against, and no extra DLLs need to be redistributed alongside your executable.
I have written and tested a library in C++. The code even works in my Android application if I add the source files directly. While I do have experience compiling static and dynamic libraries for common operating systems, I have zero experience compiling for a mobile system like this. I've done some research, and I'm still a bit lost as to exactly how to approach this. For example, I am unsure of whether to build a makefile for use with ndk-build or to just invoke one of the Android's compilers directly.
I did see this question, but it does not quite match my situation. I just want to run build and have it spit out libfoo.a (I'd like to produce libfoo.so as well, but libfoo.a is of greater interest to me right now.) The example in that question's winning answer implied that it would build the library as one step/module for building the final application. I tried doing it that way just to see, but I had no luck.
Can anyone please guide me in this endeavor?
CLARIFICATION -- I do not want to build the library and immediately pipe it into an application. I want a .a or .so file that I can link against in multiple future Android applications.
Create a dummy java file with empty code and make sure there is a android_main function in your C++ code. Build using ndk-build. the resulting apk will make your library an application.
See the samples from the android-ndk-r5/samples directory, see the sample native-bitmap to get some idea.
If I understand it correctly that a shared library is not acceptable and you want to be static (but why is that so important?), probably the easiest way to do so is to simply supply source code that can be added to a project.
Ultimately there is nothing special about the ndk build system other than it knowing the right commands to issue to build the necessary files for the assortment of curent android architectures. If you really want to do something different, you can log the operation of the android build system in creating a shared library, and then write your own Makefile that performs the analogous steps to create a static library. HOWEVER, you will have to update your Makefile any time the underlying assumptions or target collections change in a new android version.