actually this is a pretty straightforward question (with possible tricky implementation maybe). I have a command-line application which executed within a binary file and has an update feature which rename the old file with the newest one.
How can I implement binary file renaming (let's say exe in Windows) during runtime of the prior binary using os package or other alternatives?
Example :
prior binary : version1.exe
latest binary : version2.exe
I want version1.exe "transform" into version2.exe by name, without creating any temporary file or such during runtime.
Related
I know I can call GetFileVersionInfo() windows API to retrieve file version information.
Is there an easier way to determine the version information, from within the program itself?
For example, suppose I am writing codes for Foo.dll, and inside Foo.dll, I want to support a version function, say GetFooVersion(), which reports the version number of Foo.dll.
If I have to use GetFileVersionInfo(), then I need to search which Foo.dll in the path that is been linked (dynamically), and apply GetFileVersionInfo(). It's tedious and error-prone.
The target visual studio version is VS2012.
There is no GetFileVersionInfoByHandle nor GetFileVersionInfoFromModule unfortunately.
You can use FindResource etc. on your own module but you then have to parse the version info yourself because GetFileVersionInfo does not always retrieve the raw resource data (it can translate to/from Unicode etc.).
Another option is to put version #defines in a .h file that your function and your resource.rc can use so you only have to update a single file when the version changes.
I would like to create an installer for a library (DLL) that can be use in multiple system including MATLAB.
For MATLAB, I have additional *.m and *.mex files to make the DLL functions easily accessible from it.
I also have an installer that modify the PATH environment variable to make my DLL visible to all potential calling system.
My problem is that MATLAB does not make use of the system PATH environment variable. Thus, I am looking for a fix that would allow users of my library to run the installer and have my library accessible from MATLAB "out of the box" (possibly after a restart or session reopen).
I currently see 2 ways to do it which I both do not like :
Write a MATLAB script that uses addpath()/savepath() functions. I don't like this because :
a. MATLAB may not always be installed.
b. This would mess with the user's MATLAB's own path variable.
c. Upon installing a new version of my library, I would have to mess even more with the MATLAB's path to delete the path to older library before adding the path to the newer library.
Look through the system PATH and search for ...\MATLAB\RXXXXn\bin path to use that to install my *.m and *.mex files in the appropriate folder inside MATLAB. I don't like this because :
a. It would mess with MATLAB's own installation.
b. Once again, installation of multiple successive versions of the library may cause some issues (currently multiple version may be installed in separate directory, and the PATH redirects to the last one installed, experts users can modify the PATH according to their needs).
Currently, I am leaning towards option 2, but I am looking for a better, cleaner solution to this installation procedure.
Can anyone give me some MATLAB's expert advice ?
Thanks in advance for your help!
I have a folder which contains an executable file (Exec.exe) and a lot of files that Exec.exe needs to run. Currently, it's pretty ugly having all of those files there when I only need to run the one executable. Is there any way to bundle them all into another executable that runs Exec.exe and also contains all of the files Exec.exe needs to run? Thanks for any help!
Yes, but I would recommend you only do it if you need to.
You can achieve this by adding your files as resources in your exe project, so they are added into the exe's binary at compile time. You can then access the files directly from your exe at runtime by using LoadResource and related functions. I'd recommend reading up on the Portable Executable (PE) file format if you're considering this route.
This is the way to do it if you, and again I stress, need to have only a single binary where you can still access your files. There are obvious downsides to doing this, such as it's much more coding to access the data as it's embedded in your application binary, and you can't easily update the files (check out resource hacker tool) without re-compiling your binary to include the new data.
If the only reason you want to do this is because it's "pretty ugly" seeing the additional files in the same directory as your exe, consider moving them into another directory, for example,
from:
MyExeDir
--myExe.exe
--myFile1.txt
--myFile2.dll
--myFile3.dat
to:
MyExeDir
--myExe.exe
--dat
----myFile1.txt
----myFile2.png
----myFile3.dat
or:
MyExeDir
--bin
----myExe.exe
--dat
----myFile1.txt
----myFile2.png
----myFile3.dat
So all the "ugly" looking files are out of the way.
Why don't you create a shortcut of "Exec.exe" and keep it somewhere handy ? If whats that you want ?
Or if you want to distribute your app, you can use Winrar/Winzip (winrar is the best) to create a compressed .exe of your entire folder, making "Exec.exe" as your startup app. Use the SFX option in winrar.
For an application I would like to store a collection of files together, and have them appear in the filesystem as a single file so its easy to manage. I am currently storing everything in a folder.
I would like to keep things accessible so you can manually edit the inside contents if neccesary.
One way to do this would be to create a zip archive and give it a custom extension other then .zip. Then it appears as a filetype and if needed you can unpack and access the content, but for normal use keep it hidden.
I can't seem to find a convenient way to do this. Boost and zlib can do the compression but don't work with archives. I found libzip but I have a hard time understanding how to use it and to me it seems that it only reads/writes zip archives without doing the actual compression.
Is there a more convenient way to tackle this?
Can you call system functions for creating an archive on OSX from c++ / Carbon?
Is there another way to make a folder appear as a single file?
In OSX, you can create Document Packages (similar to application bundles) which are treated as a single file in the Finder, but are really just directories with some internal structure.
Apple does not zip these packages, but they do provide the functionality you describe and they can be created and accessed through CoreFoundation by using CFBundleRef .
From the documentation:
... The important thing to remember about creating a document package is that it is just a directory. As long as the type of the document package is registered (as described in “Registering Your Document Type”), all you have to do is create a directory with the appropriate filename extension. (The Finder uses the filename extension as its cue to treat the directory as a package.) You can create the directory (and create any files you want to put inside that directory) using the standard BSD file system routines ...
As 1st step, simple rename the folder and add the extension .bundle, e.g. Myappdir.bundle
That's will show the whole folder as one file with a lego-like bundle icon.
The next step is you must create one Info.plist file inside.
I want to know what is the standard way of doing it.
currently I'm thinking in add a series of defines in a header file and inlcudie that file in the main resource file win win32 to update the version resource in win32 and in *nix make some global functions to return this information.
and in windows make the msi install file also reflect the same version.
That sounds like a reasonable way to do it. I don't think there IS a standard way of doing this; there aren't any real standards for version reporting that are cross-platform.
Since we wanted to avoid the overhead of changing a "version.cpp" or equivalent every time we hit build -- and thereby taking the time to do at least one compile and link -- we modify the binary after the build.
If you're outputting to e.g. ELF or PE format executables, you can use some basic knowledge of ELF or PE and a linker map to figure out what to replace, otherwise you can scan through the binary looking for a set pattern (we use something like static const char VERSION[] = "[VERSIONBLOCK xxxxxxxxxxxxx]";) and replace a portion (e.g. the xxxx part above) with relevant info:
build date and time
build machine
username
output of e.g. svnversion
Note that this won't work very well if your binaries are signed or compressed before this step, but usually you can engineer your build process so the signing/compressing happens after this step.
I'm sure a variant of this could be extended to hit the Win32 PE version metadata as well as any embedded version string.