I have an application which consist's of these files:
start.exe <-- main executable
libssh2.dll
libcurl.dll
libeay32.dll
zlib1.dll
ssleay32.dll
inf2.cl
ffd.co
.... and other files with different extensions. Application read these files during work.
How can i merge all these files into one start.exe without changing code (i can't, i do not have a source code). I know that themida can do the trick but when i use demo i have a crash...
Thanks!
Related
I'm trying to update an old app that uses Lua and IUP, but I'm not very experienced, so I'm wondering if I have too many files. I originally downloaded Lua 5.4.3 and followed a tutorial on how to turn those .c and .h files into Lua.dll, Lua.exe, Lua.lib, and Luac.exe.
Then I downloaded iup-3.30-Lua54_Win64_bin.zip and extracted to it's own folder. That folder contains a bunch of .DLLs and a few .EXEs. Since those files have their own interpreter (iuplua54.exe), are the files in Lua 5.4.3 unnecessary? Why do these downloads have different file types? Did I install them wrong or did I get the wrong files?
I'm having issues with different Lua .exe files giving me different errors when I try to open a particular .lua script.
I can't make a Stand alone exe file in VFP9. I have tried the following codes.
BUILD PROJECT XX FROM MAIN
BUILD EXE MAINEXE FROM XX
It will make an executable file. But its not a Stand alone. Any solution?
You cannot make an executable with VFP that would run without any runtime files. All you need is to add those few DLLs (listed below) to your executable's folder (if you don't have any other dependencies like FLLs, activex):
Vfp9r.dll
Vfp9t.dll
Vfp9Renu.dll
Note: If you think about it, that is the case with many languages out there. There are not so many languages where you can build native all-in-one executables (C, Go as examples).
I installed Go 1.6.2 on Windows but in my bin directory I now have only 3 files:
go.exe
godoc.exe
gofmt.exe
I wonder if that's normal or my installation didn't go quite well.
That's normal. If you're looking for all the other executables (like linker, compiler etc.), check the:
%GOROOT%/pkg/tool/windows_amd64
(or similar) folders. These are not placed in the bin folder because you don't need to call these (they are called by the go.exe tool). bin contains only the tools you interact with, and is recommended to add %GOROOT%/bin to your PATH.
For example in my pkg/tool/windows_amd64 folder I have the following additional binaries:
addr2line.exe
api.exe
asm.exe
compile.exe
cover.exe
dist.exe
doc.exe
fix.exe
link.exe
nm.exe
objdump.exe
pack.exe
pprof.exe
tour.exe
trace.exe
vet.exe
yacc.exe
I want to use Qt in my new project. An installer for my target compiler (VS2010 64bit), does not exist.
I am using Windows 7 64-bit with Qt 5.1.1.
A colleague of mine is also planning on using Qt and has managed to compile it for my target compiler (which he uses as well). He has built it in some directory, say DirA. He graciously gives me a copy of his entire Qt SDK build (binaries, examples, headers, and all), and I copy it to DirB on my machine.
I need it in DirB, because that is where all my 3rd party libraries are installed, and my CMake scripts know how to find them. I also added the Qt bin folder to my path.
Problems ensue. Qt binaries for some reason have the install path (in this case the build path) hard coded within them. So even though the Qt bin folder is in my path (so DLLs are found), Qt's DLL(s) are looking in the wrong place for the windows "plugin". They are looking in DirA, which does not exist on my machine.
So from what I found researching, using a qt.conf file specifying the install path root, is supposed to be the way to go. I add one to my Qt bin dir, and now Qt binaries (assistant, qmake, etc) can run.
But now I build one of the examples. Builds fine. Run the exe, Qt DLLs load, and then it crashes because it can't find plugin directory.
A work-around my colleague and I found that seems to work, is to copy my qt.conf file to the directory my exe resides in. After doing that the exe runs.
But this does not seem right. My exe can find the Qt DLLs, but the Qt DLLs it loads can't find qt.conf. They don't know to look in their own containing folder. I must have qt.conf in my working directory (my exe dir) for it to be found and used.
Does anyone know why this might be happening, and know of a way for me not to be forced to have a qt.conf file in my exe's dir? I can't accept this requires a rebuild of Qt. There must be some other way.
You can put qt.conf into your binary. Using the resource system.
From the Qt docs:
Without qt.conf, the Qt libraries will use the hard-coded paths to
look for plugins, translations, and so on. These paths may not exist
on the target system, or they may not be accesssible. Because of this,
you need qt.conf to make the Qt libraries look elsewhere.
QLibraryInfo will load qt.conf from one of the following locations:
:/qt/etc/qt.conf using the resource system
Or:
Using QApplication::addLibraryPath() or
QApplication::setLibraryPaths(). This approach is recommended if you
only have one executable that will use the plugin.
If you add a custom path using QApplication::addLibraryPath it could look like this:
qApp->addLibraryPath("C:/customPath/plugins");
I've successfully built a demo app using opencv on windows with the MSYS shell environment.
I did NOT use the prebuilt opencv installer, I downloaded and compiled the source locally (this is the recommended method).
After building opencv and running make install, all the files are happily in:
/e/deps/libopencv/build/install/
I can successfully build a sample application against this using cmake directives along the lines of:
find_package(OPENCV REQUIRED)
link_directory(${OpenCV_LIB_DIR})
include_directories(${OpenCV_INCLUDE_DIRS})
target_link_libraries(target ${OpenCV_LIBS})
To be completely clear here: building the binary is successful.
Now, when I run it from the shell I get the message:
The program can't start because libopencv_core231.dll is missing from your computer.
Try reinstalling the program to fix this problem.
So... I know where the libraries are:
$ ls /e/deps/libopencv/build/install/lib/
libopencv_calib3d231.dll.a libopencv_features2d231.dll.a libopencv_highgui231.dll.a libopencv_ml231.dll.a libopencv_video231.dll.a
libopencv_contrib231.dll.a libopencv_flann231.dll.a libopencv_imgproc231.dll.a libopencv_objdetect231.dll.a
libopencv_core231.dll.a libopencv_gpu231.dll.a libopencv_legacy231.dll.a libopencv_ts231.a
What now?
I guess I could try to make cmake build a static binary, but that seems pretty extreme.
How can I somehow make either 1) windows, or 2) the MSYS environment happy. Something like LD_LIBRARY_PATH on windows?
Or is this not the problem, and I've actually (despite appearances) somehow messed up the way the binary was compiled?
Edit:
NB. For whatever reason it seems that my libraries are .dll.a files, not .dlls (see the ls result) if that's remotely relevant.
windows searches the same directory as the exe, any directory in the %PATH% (Windows) or $PATH (msys) directories, as well as a few special ones in the windows folder
You could add /e/deps/libopencv/build/install/lib to your $PATH. I am not sure if this will work for msys, you may need to add E:\deps\libopencv\build\install\lib to %PATH% in windows instead.
The typical solution for this if you are giving the program to others is to include a copy of the DLL in the same directory as the EXE. you can get this same effect by making a symbolic link to it with the command
ln -s /e/deps/libopencv/build/install/lib/libopencv_core231.dll libopencv_core231.dll
while in the /e/deps/libopencv/build/install/ directory