How does one set the "Description" property of an executable? By this I mean the value displayed when you right-click an executable in Windows Explorer and it shows "Description:" with what seems to be just the name of the executable without the file extension.
I'm running GCC 3.4.5 (mingw-vista special r3) on Windows XP.
I have googled the heck out of this to no avail, but I have a feeling I might have to use a resource file with windres... am I on the right track at least?
I actually have been setting a custom name with -o, but I actually want a different one altogether.
That information is taken from a Version Info resource. Windows executables can contain resource files embedded in them. Normally, with Microsoft Visual Studio, you create a resource script (.rc file), and the Visual Studio resource compiler will compile it into the executable for you. VS also contains a nice visual resource editor for editing the various types of resources (string tables, icons, bitmaps, cursors, menus, dialog boxes, version info, etc.).
With GCC, you'll have to create the resource script yourself. See MSDN for more info on the VERSIONINFO resource type. Once you've created a valid resource script, you can use windres to compile it into an object file (.o). This page has a good example of how to do that. Finally, once you have an object file, you just link it in with the rest of your object files as usual.
Yes, you need a resource file.
For info about writing your own .rc resource file (including your FileDescription field), see: MSDN: VERSIONINFO Resource
To link a resource file using gcc, see: "Setting icons [or any resource for Windows programs with gcc":
The Windows versions of gcc (MinGW, Cygwin) come with a tool called "windres". This will compile resource files into object files for you to include at the linking stage. As a simple example, to compile the file 'chocolate-doom-res.rc':
windres chocolate-doom-res.rc chocolate-doom-res.o
This gives you a '.o' that you can conveniently drop into your build, eg.
gcc other.o files.o etc.o chocolate-doom-res.o -o chocolate-doom.exe
Related
I'm using Visual Studio Code to manage a C project that contains a number of libraries and fully-linked executables. When the executables need to depend on headers from a library, rather that point at the library's source files directly, they point at a build directory containing the headers. That is, for a source layout like:
project/lib/src/lib.h
project/exe/src/exe.c
Rather than the build for project/exe including -I project/lib/src, it does -I project/lib/build, which will have a copy of lib.h in it from the last time the library was built. This is done for miscellaneous reasons that don't matter here, and mostly works fine, except when I use vscode's "Go to Definition" feature (F12, Ctrl+Click, etc.).
Because vscode is using the compiler's include path to know where to find headers, if I go to the definition of anything in lib.h, vscode will open project/lib/build/lib.h instead of project/lib/src/lib.h. Is there a way, either built-in or via a plugin, to hook vscode's belief that it should open project/lib/build/lib.h and change it to project/lib/src/lib.h? I'm even willing to write a plugin, but I couldn't find a way to either modify the language server's result to change the path, or intercept vscode attempting to open a particular path and change it on-demand.
I want to run a C project on Compiler Explorer (godbolt.org) which includes some external header files. What is the procedure to include these third-party header files on there?
Screenshot of the project
Suppose I want to run this code which includes snipmath.h file. Also, snipmath.h header includes other lib files. How can I include all of them in godbolt? like we usually do in a offline compiler.
Remarkably, only 1 week before you posted the question this feature was added to compiler explorer. As of Nov 2021 it is reported to still have some rough edges, and not every combination of controls work - but starting from the simple template Matt delivered and following his instructions work for me:
go to compiler explorer
click "Add..." at the very top left and choose "Tree (IDE mode)".
Move the files you have open into "Included files" with the plus (you will have to give them names)
(For C++) tick "CMake" and then create a CMakeLists.txt with appropriate info it in
Ensure it says -DCMAKE_BUILD_TYPE=Debug in the box under
In the box under that choose the name of your target, e.g. "test"
You can then "Add new..." and make a compiler that will run CMake
Note this does not include uploading the headers, but rather pasting them in new CE editors. Also, judging by your screenshot - when you write 'other lib files' I assume you mean other headers. Lib files aren't supported.
If your project was a CMake one, you might have been able to upload it directly (someone did).
You can use Compiler Explorer with Cmake and have multiple header and source files. You could even have some other files to read from (like *.ini). Try it here reading *.ini in Compiler Explorer
Note: the examples are with C++, but it must be straightforward to do it with C.
What is the minimal set of files after creating a project in Visual Studio (2010) that You have to send to somebody who uses a different compiler ? (for example the Debug folder isn't necessary, but what about .vcxproj.user file or other ?)
What are .obj files?
What kind of information is displayed in "watch" and "call stack" windows during debugging ?
The only files you absolutely need to send someone are the source files and the project file. The source files will usually be *.c or *.h files, but could include others, like resources.
As far as the other files go, each of them does something slightly different. The full list, as of VS2013, is found here. Most of them are generated by compiling and linking, or by opening the project in the IDE. A quick way to tell them apart is to do a Clean Solution, which should delete and intermediate files.
The obj files are intermediate files use during linking, and don't need to be packaged. In fact, nothing in the build or output folders needs to be included, as they'll all get rebuilt. The information that's used at debugging is mostly pulled from the obj and pdb files, which are both created each time you build.
I've got a Windows minidump (C code) and a corresponding exe file. Unfortunately, I don't have the exact matching .pdb files, but I do have .pdbs that contain the exact same code just built at a different time. In Windbg, I can use:
.symopt+0x40
To tell it to load anything, even mismatched symbol files. This works great in this particular instance, and I'm able to get a proper call stack. I'm just curious as to whether or not Visual Studio has any such feature. We use pretty much every different version of VS here, so it doesn't matter which version it might be in. Thanks.
Try this utility:
ChkMatch utility can be used to check whether an executable and debug information file match. It can also be used to enforce matching between an executable and debug information file, if they are compatible.
For more information about debug information matching and related issues, see this article.
Supported debug information formats: DBG, PDB 2.0, PDB 7.0...
There is no override, but the poster to this question found a way to modify the PDB files to make them match the EXE.
Thanks to one of the comments on the
first answer, I checked out a link to
the pdfs of the book "Undocumented
Windows 2000 Secrets: A Programmers
Cookbook". And the author goes into
great detail about the pdb file
format. As I said before, I had
already loaded the pdb into a hex
editor and flipped some bits around
appearing that I made the
age/signature match, but it didn't
work. Well, after using the utility
from the W2k secrets book to "explode"
the pdb into the included streams, I
found out that they hide another
reference to the age in stream
3!!!!!!! Once I flipped that one as
well, it matched up in windbg.
Not sure if you want to go to this much trouble, but it looks like it can be done. If this is for production support then it could be worth your while.
Visual Studio and Windbg match pdbs by comparing the timestamps in the Executable header with timestamps store in the pdb file. You can view the timestamp by running dumpin /headers .
I haven't used chkmatch but modifying either the exe or pdb to match each other should work fine.
Be aware that this technique may not be enough to debug your binary. John Robbins in his book 'Debugging Windows' (which I can recommend) mentions that he's seen different build results from the identical source tree built at almost identical times.
Always build pdb symbols with your builds (including release builds) and archive them alongside the build products and include the .map file for good measure.
According to this post its possible to use sos windbg commands as well in visual studio. But i am not sure if ".symopt" also falls into this category.
I'm told that in VS2019 (16.7 .. 16.8 ballpark) that they switched to a multi-threaded PDB file generator to speed that up.
A side effect is that sections of the file, being generated on different threads, may end up in a different order in the file.
Bottom line, it is even more important than before that you use the PDB that was built with the EXE and no other.
I can't find a way to use the source server tools from the Debugging Tools for Windows on a static library project,
which is built separately from the solutions actually using that library:
The output of "ssindex.cmd" always displays "zero source files found" for the PDB file generated for the library
(using compiler options /ZI and /Fd).
Running "srctool.exe -r" on this PDB displays nothing, which probably means that the PDB file does not contain any source file information.
Running the same command on the PDB file of a test application which is also build as part of the the same solution
yields a list of all expected source files.
Is there a way to use source indexing for a static library project when it should be built seperately from the solutions using it?
Thanks for any suggestions!
You can use the "/Save" and "/Load" options to store and load source information for a static library, respectively. Using these options allows you to store information for your library and then later import it when indexing a project that links against your library.
When indexing your library solution, you specify the "/Save" flag with a directory in which to store index information about the library's source files. For example (assuming you are using Subversion for source control),
ssindex.cmd /System=SVN /Save=c:\source\libproj\srcinfo /Source=c:\source\libproj /Symbols=c:\source\libproj\Release\*.pdb
When later indexing your project that includes your library, you specify the "/Load" flag with the directory containing the library's source file information. For example,
ssindex.cmd /System=SVN /Load=c:\source\libproj\srcinfo /Source=c:\source\binproj /Symbols=c:\source\binproj\Release\*.pdb
There are two potential issues that may affect your ability to use this technique. First, it appears that some source control providers may not support saving and loading source control information. I know that the Subversion provider does and it looks like the SourceSafe provider does, but I haven't checked any others.
Second, this technique appears to only work for one external static library out-of-the-box. There does not seem to be a way to load information from multiple directories and the scripts currently overwrite the contents of the directory each time you use the "/Save" option. You could probably edit the source control provider module to append to the files in the save directory rather than overwrite them, but I have not tried it.
Also, note as you mentioned above that you only need to do this if your library is being built as part of a separate solution. If the static library is part of the solution you are indexing, its source files will be included if they are in the path specified by the "/Source" option.
It probably means you haven't inputed the correct directories when running "ssindex" so for ssindex you need to have: /source=C:/SourceCode/ /symbols=C:/SourceCode/bin/Debug I'm not sure if the "source" has an upper case S or not but that should be it!
when run svnindex.cmd, it always tell you "zero source files found"
after a painful diggin into svn.pm (the perl module to deal with svn), i found that:
first, svn.pm invokes "svn info -R $SourceRoot" to get all version info of files in $SourceRoot (passed by /source option),
then svn.pm stores all files in a dictionary which using the local file path as key
svnindex.cmd call srctool -r to get all source files info in *.pdb, and use the source file name as a key to query info saved in step2
the problem is:
svn.pm uses relative path, but *.pdb uses absolute path, so you will never find a svn log info for any file, then "zero source files found"
fixup:
change svn.pm line 162:
$LocalFile = lc $1;
to
$LocalFile = $SourceRoot . "\" . lc $1; #make path absolute