What I want to do is to programmatically update resources of an executable file.
I have a binary resource (.res) file containg bitmaps, icons, version info and a manifest, created with a resource editor, and a PE file compiled with AutoHotkey to which I want to copy the resources from the .res file.
Until now I used to do this with ResourceHacker in command prompt, but ResourceHacker can't be redistributed and besides I want to do this more elegantly.
So I was looking in the WinAPI functions and there seems to be a way to do this: http://msdn.microsoft.com/en-us/library/windows/desktop/ms648008%28v=vs.85%29.aspx
But the problem is that the article describes how to copy resources from an executable file to another, and you can't import non-executable files (the .res file) with LoadLibrary/LoadLibraryEx.
There also seems to be a way to do this with tools from Visual Studio, particularly LINK.exe. But I'm not sure if it can be used outside of the VS enviroment. I have no idea how it works.
You can programmatically update resources with the UpdateResource function
RES files are not involved. RES files are used by the project makefile system to enable minimal rebuild of resources... they don't have to be recompiled every time the application is relinked, just embedded. But you aren't relinking the application and losing the existing resources, so updating just the resources you want to change is the way to go.
If your source assets are already encoded in RES files, then this page describing "Resource File Formats" can help you extract them. It also describes use of LINK.exe for resource embedding. LINK.exe is installed as part of Visual Studio, but it is also available in many versions of the Platform SDK and Windows DDK.
Related
I'm running into an issue where after building an application with Powerbuilder, some users have no issue with viewing icons within the application while others can't see the icons. Also, the main icon for the application doesn't display on the Windows Task bar. I'm going to play with the icon size but if anyone else has any recommendations, that would be great!
I don't like to re-compile the executable every time there's a small graphic change or a customization that applies to only one library, and I don't like to compile graphics into the executable... it makes the exe file very large. No reason to rebuild the exe unless the library list changes. So I use .pbr files, and just rebuild the pbl with a pbr file.
My graphics.pbr file resides in the same directory as my graphics so I don't have to mess with environment variables or worry about file paths. I created an empty graphics.pbl in the AppCore directory, and a graphics.pbr in the graphics directory. The graphics.pbl is in the application's library list. When I have to add or edit graphics, I simply rebuild the graphics.pbl with the graphics.pbr.
I have multiple customers using the same application, with their own graphics (logos) so I do the same thing there. Here's what my directory structure looks like:
MyApp
MyApp.pbw
AppCore
graphics.pbl
bunch more libraries
AppGraphics
single resource file, graphics.pbr
bunch of icons and graphics
Customer1
Customer1.pbl
Customer1.pbr
a few libraries for customization and container for application object
a few custom graphics
Customer2
etc.
The key is to make sure when you add graphics or images to your application from the AppGraphics directory (or the customer directory), make sure there is no directory path.
This solution has made it easier for me to continue developing the next upgrades and versions by moving the code and renaming some directories without having to edit my code because my directory path has changed.
This is lengthy, but I hope it helps!
~~~Tracy
Within the IDE where you insert the icon file name, make sure you don't have a path (like "C:\graphics\myicon.ico") - only the name of the icon file. Then make sure the icon files are somewhere in a folder within the PATH variable on your system. When you build your application you can use a PBR file (a resource file) in the project for the application. If you list all the graphic files used in the application in this resource file they will be included in the exe (and you won't have to distribute them separately).
Matt is right on point with not using path names in your image references in the app. Also correct that it is best to compile them into the app.
However, during development I like to separate my resources and DLLs into separate directories. To do this without changing global env variables, you can include your directories in the PB "App Paths" registry section.
Depending on your PB Version...
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\pb125.exe"
There you will find a "PATH" value. Just append your dev, resource, dll, directories to that path separated by ";" and PB will find them (requires restart).
I actually create reg files in the root of each app I'm working on to quickly register my paths.
NOTE: The same thing works with your final compiled application; but instead of using the PB section, there will be section created with the name of your executable. Just do the same thing there - add paths where resources are separated from the EXE directory.
This question might seem to be duplicated with this and this that are similar. But it is not! First- I am getting this error from the setup file and not from the program that I am distributing Second -the version is different, the directories in Installshield 2009 an 10.5 differ. .
I'm trying to fix an error caused by Windows compatibility mode in my setup, which is built with Installshield 10.5. So far my research led me to a conclusion that i need to add [this][3] to my manifest file. I saw that Microsoft's tool mt.exe could extract a manifest file from a dll, however I did not see anywhere that it can extract it from an executable file.
So my questions are the following:
Is there any way to view the manifest file of a Setup.exe built with Installshield?
Is there any way to configure this manifest file for the certain project in Installshield?
[3]Can one edit an InstallShield setup.exe's manifest file?
As far as I know, mt.exe will work fine on EXE files; both EXE and DLL files are Portable Executable (PE) files, and PE files use the exact same structure for resources such as the manifest. Visual Studio, CFF explorer, and countless other tools (including raw resource APIs) will also work to view and possibly update manifests in general.
However for a built InstallShield setup.exe, there is a twist. InstallShield uses areas in the file to store information that are not described in the PE format. Tools that update the resources on an EXE can inadvertently destroy this data as they do not expect it to be there, nor do they know how to detect or adjust it.
InstallShield 12 or so and later allow you to specify a manifest, and it selects the manifest from files it ships that you can update before it adds them to the setup.exe. In addition, there is a tool called ISReMan that is aware of the extra information and can update the manifest correctly when that data is present.
By the way, it's generally helpful to mention the actual problem you're trying to solve, in case the method you've chosen (in this case updating the manifest) is not the correct solution. Note as well that InstallShield 10.5 is over 10 years old, and knows nothing about UAC, PCA, and other Vista and later technologies; adjusting the manifest may not help fix, say, an elevation-related problem.
Note as well that I am paid to work on InstallShield, so I may be biased when I recommend things like upgrading. :)
I have an app that I am moving to another server. It is complaining that it is missing TABCTL32.OCX. I have located this file on another server and I want to copy and paste it across.
I have discovered that there is also a file called TABCTL32.DEP on the server I am moving from. Do I have to copy both files across or is the dependency file optional?
I have tried it with an without the DEP. The app works in both cases. It is a production server so I want to be sure.
Those .DEP (depdendency) files are instructions about a library meant to be used by packaging tools. These files have no run-time significance, containing only development metadata. They are text files.
They contain the preferred ("designed") location to install the library, sub-dependencies of the library including optional localization "satellite" resource DLLs, version information, etc.
See articles such as INFO: How Setup Wizard and PDW Use Dependency Files.
This is information a packager should use along with other "rules databases" such as VB6DEP.ini. Programmers are also supposed to create them if they expect other developers to use their libraries.
If you are using an "impaired" 3rd party packaging technology that is ignorant of .DEP files it is up to you to read them and incorporate the information they contain in your build process. You are also responsible as a developer to keep your dev machine's .DEP files and VB6DEP.ini file up to date, since they often are not updated by Microsoft anymore.
You can't just copy files willy-nilly from one machine to another. Go find this program's installer and run it on the new machine.
A .dep file is a file used by the Visual Basic Setup Wizard to determine what dependencies your ocx file have. You can open the file with Windows Notepad to view the contents.
Unless you are using the Visual Basic Package and Deploy Wizard, you can ignore this file.
For more info, see INFO: How Setup Wizard and PDW Use Dependency Files
I would lik to make 1 exe-file (win32) with all obj, idp, pdb... files embeded to make it easier to copy the program and use it on other computers, can anyone help me?
You don't need obj, idp, pdb... files to run on another computer.
Start by selecting the Release configuration and see what ends up in the output folder. Most likely it's just 1 file.
You can embed Text, Xml and in principal even DLL files but it is not always worth it.
If you want to simply run the generated program on another computer, just copy the .exe and any associated dll files. The pdb file is a debug information database that is not actually needed to run the program - only to load it in the debugger with specific information. The other files are intermediate files created during the build process.
If you don't want to have to install the Visual C++ Runtime on the target machine, or rely on it being there, you will want to go into the Project Settings -> C/C++ Settings -> Code Generation and select that you want the "Multithreaded" library instead of the "Multithreaded DLL" library (or equivalent). This will embed the C++ runtime into your program.
Of course if you're trying to copy the project over to perhaps do more debugging or development on another computer, just pack it all into a zip file.
I have a manifest embedded as a Windows resource. But what's the right way to apply it?
More specifically:
I have my .manifest file. It's the standard one to make an app use controls in the Windows XP/Vista visual style. When applied by being in the same directory as the .exe and suitably named, it works.
However, this approach is rather cumbersome. I'd like my .exe to be self-contained. Clearly it can be done, given that many of the apps on my computer manage to use the modern style without a separate manifest file.
So I had a look around, and finally found embedding the manifest as a resource. So I've added this line to my .rc file:
1 RT_MANIFEST "mdiedit.exe.manifest"
But what do I do next?
Edit: If it helps you to know, my program is written in D and built using the Digital Mars D and resource compilers. No IDE. But I'd expect any solution that works in C(++), when built using command-line tools, to work in D as well.
RT_MANIFEST is a define, so make sure your resource file includes the correct header, or just replace RT_MANIFEST with 24
Did you add the .rc file to your project yet? Alternatively, use your development environment's resource compiler, such as brcc32.exe or rc.exe, to compile the .rc file into a .res file, and then add that file to your project.