Can I include an .exe file in another, and then run it from the outer program?
For instance, can I make a wget GUI by including it inside my program, or are my only options either using the including the source or supplying the wget binary together with my wrapper?
I am working on Windows and am looking for a solution in c/c++/c#
Sure you can.
The idea is to 'insert' the exe as a resource to you main application.
There is a link which explains how to compile resources into delphi exe. Its similar to VC++ or what ever...
Related
I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.
I send a Racket executable(in a distribution package) to a few friends and they get the error:"Failure: can not load the DLL". On my computer it runs without problems. It's using the rsound package.
Yes, good point. Currently, rsound is hard-coded to look in the collection path for the DLL. That won't work for programs compiled into executables. I've just updated rsound to tell it to look in "standard locations" as well for Windows and Mac.
Try this: Using the DrRacket package manager, update your copy of portaudio. When you're done, it should be at version "b9403a6dfbfb5eadf824ed91731ec141bf363677".
After this, it should be possible to pass along the executable file and run it, as long as the two required dll's are in the same directory as the executable. These two dll's are:
portaudio.dll
callbacks.dll
For windows, you'll find both of these in a subdirectory of the portaudio package. Finding these is going to be a teensy bit of a hassle on Windows; I believe these get installed in your user directory\RoamingData\\portaudio\lib\win32\x86_84\3m\ . If the target computer is a 32-bit machine, you'd substitute 'i386' for 'x86_64' in that path.
I know that Windows can make it quite hard to find the files you're looking for; let me know if you have any trouble.
Whew!
I'm using CMake to generate my makefiles and VC solutions. I have my program running on linux just fine. I'm using a bunch of libraries, e.g. Lua. On my linux computer I just link to them and make sure in include the headers. All of the .so files are in some standard place. On Windows though I'm not sure what to do. Should I just include the entire Lua project into my own repository and link to that instead? Do I install Lua to some standard place like c:\program files\lua5.1 and link to that? Something else?
Your libraries can be in any place, you just need to say - where are they.
Before running cmake set up pathes of all your extern libs with some .bat file:
set LIBRARYPATH =path\to\your\library\
set include=%include%;%LIBRARYPATH%\include
set lib=%lib%;%LIBRARYPATH%\lib
Start cmd, run this .bat and then cmake should find all
I would provide a configuration field/variable for ccmake that the user can or must specify.
The mark_as_advanced can be used to make a custom variable only appear in the advanced mode. This would be suitable if you have a standard path (as you have mostly on windows). Yet, it still let's the user specify the value if needed.
Or you can simply set a variable the with the 'set' command if you don't want it in advanced.
Just make sure you check if the users entered a valid value.
I'm looking for a free open source tool-set that will compile various "classic" scripting languages, e.g. Korn Shell, ksh, csh, bash etc. as an executable -- and if the script calls other programs or executables, for them to be included in the single executable.
Reasons:
To obfuscate the code for delivery to a customer so as not to reveal our Intellectual Property - for delivery onto a customer's own machine/systems for which I have no control over what permissions I can set regarding access, so the program file has to be binary whereby the workings cannot be easily seen by viewing in a text editor or hexdump viewer.
To make a single, simply deployed program for the customer without/or a minimal amount of any external dependencies.
I would prefer something simple without the need for package manager since:
I can't rely on the customer's knowledge to carry out (un) packaging instructions and
I can't rely on the policies governing their machines regarding installing packages (and indeed from third parties).
The simplest preferred approach is to be able to compile to proper machine code a single executable that will run out of the box without any dependencies.
The solution that fully meets my needs would be SHC - a free tool, or CCsh a commercial tool. Both compile shell scripts to C, which then can be compiled using a C compiler.
Links about SHC:
https://github.com/neurobin/shc
http://www.datsi.fi.upm.es/~frosal/
http://www.downloadplex.com/Linux/System-Utilities/Shell-Tools/Download-shc_70414.html
Links about CCsh:
http://www.comeaucomputing.com/faqs/ccshlit.html
You could use this: http://megastep.org/makeself/
This generates a shell script that auto-extracts a bundled tar.gz archive into the temporary directory, and then can run an arbitrary command upon extraction.
Using this tool, you can provide only one shell script to the client.
This script will then extract your ofbsh obfuscated scripts and binaries into /tmp, and run them transparently.
You can obfuscate shell scripts with something like ofbsh. You won't easily bundle other programs into a single executable for unix, though. Normally the approach for installation would be to buld a package for your platform's package manager (e.g. rpm, deb, pkg) or to provide a tarball to unravel in the appropriate directory.
If you need an executable file that unpacks the contents you might be able to use a shell archive. Take a look at the docs for shar(1) and see if that will get what you want
If you really need a scripting capability to glue multiple C programs together, take a look at the Tcl language. It has an API that is designed to trivially wrap C programs that expect to see argv[] style parameters. You can even embed the chunks of C code into a custom Tcl interpreter and glue it together with various Tcl scripts.
If you really need to make it opaque, you could encrypt the tcl scripts and wrap the whole thing in something that unencrypts the tcl scripts to a buffer and then runs the Tcl interpreter on them. Tcl can accept scripts from a file or a char* buffer, so the unencrypted scripts never have to hit the file system.
shc
I have modified the original source and upgraded to a new version with some feature addition and bug fixes.
It's here.
Example Usage:
shc -f script.sh -o binary_name
script.sh will be compiled to a binary named binary_name
Note that, you still need the required shell to be installed in your system to run this executable.
arx is a great bundler, and you may be able to integrate a obfuscator in its workflow.
Options that are available to you:
Write a logic in your code that, when the code is run for the first time on a box, it'll check to see if all the required packages exist. And if they do not, the code will automatically go get the packages itself and will install them...without asking to the user to do anything. The only question the user needs to be asked is "Is it ok to proceed with the install of the aforementioned packages? (Y/N)". Anything outside of that is too much.
Once the above code is complete (yes, i'm aware it may not be all that simple for you to code this, or may be it is, i don't know your coding capabilities), copy and paste your completed code to a site like kinglazy.com and an actual executable file will be generated for you.
There are quite a few benefits of this particular option:
Yes, you will be able to run the encrypted version of your script without exposing any proprietary information.
No one can try to "view" your script, because if they do, they'll see nothing but indecipherable, encrypted jargon which wont make sense to them.
No one can attempt to modify your script because if they do, the script will immediately become inoperable.
No one can run a debugger on your script to see how it works. If they do, the script will abort.
Also, no one can create copies of your script on the same server. If they do, it will abort and won't work. It'll only allow users to create symlinks to the original location of wherever you want the script to be.
I may be missing some things in what you asked for, but i believe the above satisfies a good portion of what you wanted.
Not sure if this works on other scripts but it certainly does for shell scripts.
You can also use the free online version of CCsh to compile a shell script into a binary:
http://www.comeaucomputing.com/tryccsh/
I want to make a stand-alone exe with cygwin. I have two options:
Staticly link cygwin1.dll
If I can statically link cygwin1.dll, then I can get a stand-alone exe.
Merge cygwin1.dll with myprog.exe
If I can merge cygwin1.dll with my program, the I can get a stand-alone exe.
Do not suggest that I use IlMerge. This will not work because I didn't compile my program with .NET.
Are any of these options possible? If not, is there anything that is possible with this dilemma? Thanx!
Try passing -mno-cygwin as a compiler and linker flag. If your program's requirements are simple enough this will avoid depending on Cygwin libraries and create a standalone EXE.
I can see two possibilities that you might consider reasonable. One would be to build a stub executable with a different compiler (e.g., MinGW -- whatever, just so it doesn't need cygwin) to unpack the main executable and cygwin.dll into a temporary directory, and then spawn that executable. To distribute only a single executable, you'd want to add the main executable and cygwin.dll to the "stub" as binary resources. It's a bit ugly, but pretty straightforward.
The alternative would be to grab the source to cygwin, and build it as a static library. At least in theory, this should be cleaner -- but it's also undoubtedly more work. Getting it to build as purely static code instead of a DLL will almost certainly take some work, though it's hard to even guess how much. Just browsing a bit, it's seems pretty unlikely that it's going to be a quick job of a couple hours, or anything like that (unless there's something there that I missed that already supports building it statically, of course).
More precise answer of Jerry.
Procedure described below should be confronted with your rights and license law! I know it can work but rights to distribute the result (or even perform the procedure) may be (and I'm really feel that are) bounded by Cygwin license. That is because your application will still refer to Cygwin (even though it is useless - but is still in your app)
Assume hello.exe is the name of your great application compiled under Cygwin in great project directory C:\xxx\yyy\zzz\
In the cygwin console go to C:\xxx\yyy\zzz and type
objdump -p hello.exe | grep "DLL Name"
You obtain all DLLs your application uses. Then copy C:\xxx\yyy\zzz to all DLLs listed and specific for cygwin.
Note that your application may invoke other applications (using exec function for example) --- find libraries aplications use and copy this libraries as well as this applications themselves -- to C:\xxx\yyy\zzz.
Maybe you will have to recompile your project with option of kind -L C:\xxx\yyy\zzz or so. Watch all other paths in your sources.
Thus your application becomes independent of Cygwin installation and you can present its functionality to/ share it with ---- other Windows users without Cygwin. But - once more I point and ask you - be aware of proper license and law of Cygwin creators and observe them!