I often have the need to store a certain file version in a non-exe file, just the way I give a file version to an .exe, for example "1.0.392"
However, I have not found a way to do that for non-exe-files (such as .db files, etc.)
Is there are way to do that in a simple way?
Thank you!
Related
I need to add version info and retrieve it from the CHM file to make it possible to make an alert message to a user about a new CHM-file version available and downloaded.
It means, that I should compare versions of CHM on different machines (Server and clients).
The other way is date and time checking, but I should remember about time zones, so this is complicated, because also one should remember about different file systems, according to Windows SDK help about SetFileTime function and FILETIME structure.
If someone knows the trick - please share.
.chm files don't have version information. You will need to find some alternative way to mark the file version.
One way that occurs to me is to include a topic in the help file that contains the version. I imagine that this topic would be hidden, that is not linked by any other topic, not in the table of contents, etc.
All that remains is for your application to be able to read that topic from the help file. I'm sure that can be done with a .chm file parser, if you can obtain one. Perhaps more easily you can get the platform browser to read the topic for you. You can use IHTMLDocument2 to read a URI like this:
mk:#MSITStore:C:\somedir\somefile.chm::/html/SomeTopic.html
I am trying to develop an application which has to store the paths of different folders . I thought I will create a file that stores these paths.
My problem is I don't know a proper way to manage this file like where I should save this file. I looked for information on managing files our application creates but couldn't find it. Please help me
I think you can keep file paths in a txt file as absolute path of them.
You can pick create a folder under documents or some other folder then write into your txt file.
I don't get what is so complex about it.
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.
I know for dll files you can read an Assembly version, but I was wondering if there's some way to mark or read versions from ANY filetype (jpg for example). I'm making an update program that only updates what's necessary and it'd be better if all files were versioned instead of keeping track of versions in a separate file.
Oh and this is intended for winXP but if I there is a win7/windup solution that'd be awesome.
The version of an assembly is something that is specific to the assembly file format. A general "file" (such as a JPEG file) is just a bag of bits and the Windows filesystem doesn't have any "version" metadata associated with such a file.
One approach to solve your problem might be to compute a hash (such as using SHA1) over the content of the file. If you have two files and the SHA1 hashes match, then you can be pretty darn sure that the complete contents also match. (You can't be that sure with an embedded file version.)
My windows co-workers were asking me if I could modify my non-windows binary files such that when their "Properties" are examined under Windows, they could see a "Version" tab like that which would show for a Visual Studio compiled exe.
Specifically, I have some gzipped binary files and was wondering if I could modify them to satisfy this demand. If there's a better way, that would be fine, too.
Is there a way I could make my binaries appear to be exe files?
I tried simply appending the VS_VERSION_INFO block from notepad.exe to the end of one of my binaries in the hope that Windows scans for the block, but it didn't work.
I tried editing the other information regarding Author, Subject, Revision, etc. That doesn't modify the file, it just creates another data fork(what's the windows term?) for the file in NTFS.
It is not supported by windows, since each file type has their own file format. But that doesn't mean you can't accomplish it. The resources stored inside dlls and exes are part of the file format.
Display to the user:
If you wanted this information to be displayed to the user, this would probably be best accomplished with using a property page shell extension. You would create a similar looking page, but it wouldn't be using the exact same page. There is a really good multi part tutorial on shell extensions, including property pages starting with that link.
Where to actually store the resource:
Instead of appending a block to the file, you could store the resource into a separate alternate data stream on the same file. This would leave the original file stream non corrupted on disk and not cause its primary file size to change.
Alternate data streams allow more than one data stream to be associated with a filename. Each stream is identified by a colon : at the end of the filename and an identifier.
You can create them for example by doing:
notepad test.txt:adsname1
notepad test.txt:adsname2
notepad test.txt
Getting the normal Win32 APIs working:
If you wanted the normal API to work, you'd have to intercept the Win32 APIs: LoadLibraryEx, FindResource, LoadResource and LockResource. This is probably not worth the trouble though since you are already creating your own property page.
Can't think of any way to do this short of a shell extension. The approach I've taken in the past is a separate "census" program that knows how to read version information from any kind of file.
Zip files can be converted into exe files by using a program that turns a zip file into a self-extracting zip (I know that WinZip does this, there are most likely free utilities for this also; here's one that came up on a search but I haven't actually tried it). Once you've got an exe, you should be able to use a tool like Resource Hacker to change the version information.
It won't work. Either Windows would have to know every file format or no file format would be disturbed if version information were appended to it.
No, resource section is only expected inside PE (portable executable; exe, dll, sys).
It is more then just putting the data inside the file, you have a table that points to the data in the file header.
What you can do if you have NTFS drive, is to use NTFS stream to store custom properties this way the contact of the binary file will remain the same, but you will need to use a custom shell extension to show the content of the stream.