I have been using the Metrowerks Codewarrior IDE for many years. It's C/C++ compiler generates what Metrowerks calls 'browser info'. This browser info makes it possible to double click a typename/functioname and automatically the correct file is openend displaying the definition.
Now the mentioned IDE has the possibility to use external toolchains (compiler,linker etc.) by means of plugins. I have succesfully created compiler and linker plugins for both the Microsoft as the GNU toolchains. The only thing I don't know is how the generate the mentioned 'browser info'. Which command line do I have to execute to get the information I need?
Compiler flag /FR generates browser info files: /FR, /Fr (Create .Sbr File), and then you can use bscmake to compile these into a .bsc file.
However I've no idea how you'd consume these .sbr files or .bsc file in your plugin. I guess you'll need to find a DLL or COM interface from Visual Studio to give you something to work with. There are other options e.g. map files if they're easier to consume and have enough information for you.
Related
I have a DLL file for old game(age of empires)
I just want to edit that file or see the source code.
I tried reflector toll and some others, but without any result
so, 1- how can I edit or see that DLL file??
2- can I know In what language that file was written?
It's sort of difficult. I mean you can look at the file with a hex editor, but it's not going to look nice. However, you can use 3rd-party tools in order to get as much info you can about the .dll:
Dependency Walker - useful to get the .dlls that your .dll depends on (and the functions that it need from there), exported functions, .... The bad thing is that last version is from 2006. A more actual replacement (written in .NET): [GitHub]: lucasg/Dependencies - Dependencies - An open-source modern Dependency Walker
[HeavenTools]: PE.Explorer - a nice tool (I'm not saying it's the best) that lists lots of info about the dll (sections, resources, ...) and it also has a disassembler (this reverse engineers the .dll and displays it in the form of assembly code). If you understand the assembly code you can then modify it (by modifying the corresponding bytes in your .dll), but that's for experts only. The problem is that it only handles 32bit (x86) .dlls, and the latest version is from 2009 :(
[MS.Docs]: DUMPBIN Reference - part of VStudio. Displays (read only) various information
For .dlls written in .NET, check [SO]: How to decompile a .dll file created in VS.net
Most likely it was written in C. The tools I listed can tell you more. You can also look with a text viewer at the .dll, inside it there might be references to source files (among all those unreadable symbols)
If the .dll has dependencies in form of msvcr###(d).dll (# sign is a placeholder for a digit) or vcruntime###(d).dll, then it's C, if it also has msvcp###(d).dll, then it's C++ (created with VStudio).
Adding to this:
For .net dlls an incredible program has arisen, made by JetBrains, called DotPeek which greatly simplifies decompilation of .net dlls.
I am trying to build Quantlib using Boost Libraries.
I followed the instructions here: and also on the Quantlib website.
I downloaded and unzipped boost_1_57_0 into C:\program files
I then used the Visual Studio 2013 x64 Native prompt to go to the boost directory and ran
bootstrap.bat
and then
b2 --toolset=msvc --build-type=complete architecture=x86 address-model=64 stage
Then I opened Quantlib_vc12.sln in Visual Studio 2013.
Picked "Release" and "x64", opened "Quantlib" in Property Manager and set the VC++ Directories.
In the include directories I added C:\Programm Files\boost_1_57_0
In the Library Directories I added C:\Program Files\boost_1_57_0\stage\lib
Then I went to the Solution Explorer and right clicked and chose build.
I got one LNK1104 error.
LNK1104: cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
Please see attached screenshot:
I have no idea how to fix this and I would really appreciate some help. I had successfully installed this at work using an admin account but was not able to access Quantlib using my user account. I have since deleted and attempted installations atleast 15 times but it's not working. I am worried that all these attempts at installing may have messed something else up, like some registry (I have no idea how that works but I only know to be afraid). Please help! Thanks.
UPDATE: Still get the same error after adding BOOST_AUTO_LINK_NOMANGLE define to project.
UPDATE2: I am getting these messages on the screen while running b2 to build boost. Is this an error I need to fix?
This is exactly what I warned you about in another related question/answer. What's happening here is that the boost headers you are including in this quantlib are (through macros) detecting that you're using MSVC, detecting the version, then automatically linking the required DLL files to build quantlib using #pragma comment(lib....). So even though under Project Settings -> C/C++ -> Linker there are no external DLL's or Lib's specified, they're still being linked by these pragma statements.
So when these macros are detecting your compiler and so on, they're dynamically building a string name of what they think the required libraries would be named on your system. Remember when you built boost, you specified the -layout option. This the naming layout of your boost libraries. Well by default, that layout is something like this:
LIB_LIBRARY_NAME_COMPILER_VERSION_SingleOrMultiThreaded_BOOST_VERSION.LIB
Which in practice looks like this:
libboost_unit_test_framework-vc120-mt-1_57.lib
This is boost "mangling" the name of your library to be as descriptive as possible about how the libraries were build so that, just by glancing at the file name, you know. What we do with -layout=system is tell the boost build system NOT to mangle the names, but to name them according to what option we gave to "layout". Since we chose layout=system, boost is going to name our libraries like this:
LIB_LIBRARY_NAME.LIB
Which in practice will produce:
libboost_unit_test_framework.lib
So when we start using boost after doing this (with MSVC only does this happen), these dynamically generated linker statements don't give a rip about or know about what -layout option you built boost with. They will attempt to link in required libraries using the fully mangled naming format, which is why you get the error:
cannot open file 'libboost_unit_test_framework-vc120-mt-1_57.lib
.. because you don't have a file named that! That's the mangled name! You have a file named libboost_unit_test_framework.lib. See the difference! So, you need to tell these stupid macros to stop mangling the library names when auto-linking required libraries. You do that by adding the following preprocessor definition to your Quantlib project:
BOOST_AUTO_LINK_NOMANGLE
You add that in Project Settings -> C/C++ -> Preprocessor -> Preprocessor definitions.
If you'd rather avoid this headache and don't care about the long and (imo ugly) mangling that boost does to library names, you can build boost omitting the -layout option and it will default to this mangled naming convention, where you shouldn't get stuck on this error at all anymore. I personally put out the effort to keep nice short/clean library names but it's all about preference.
Edit
Since you have the same error after fixing the NO_MANGLE problem, then the only possible reason that you're getting this particular link error is that you do not have whatever file the linker is complaining about missing stored in any of the directories supplied to the linker.
Verify the folders/paths you provide to the linker and verify that the file the linker is looking for is in one of the directories that you're providing to the linker. You have to provide directories to the linker because you're telling the linker "you can look in all of these places for the libraries my project needs". If you specify none, it's got nowhere to look. :(
Example:
Is it possible to compile libexif with Visual Studio 2010? I have been trying to do so and have been running into a whole slew of problems. I cannot find any information about whether anybody has successfully done this before. I know I can use MinGW to compile the library, but I am in a situation where I need it to be compiled with Visual Studio and then need to link to it from a Visual C++ app. Is this possible?
To answer your question: Yes it is possible... but it is a bit of a hack. Libexif uses functions that MSVC has chosen not to implement. See my working example VS2010 project below (if you don't like downloading files then skip to my explanation of what needed changing to get it to work below):
https://www.dropbox.com/s/l6wowl8pouux01a/libexif-0.6.21_CompiledInVS2010%2BExample.7z?dl=0
To elaborate, the issues that needed a "hack" (as hinted in the LibExif readme-win32.txt documentation) are:
Libexif uses inline in several places which is not defined in VS for C, only C++ (see this)
Libexif uses snprintf extensively in the code which is not defined in VS (see here)
You need to create the config.h yourself without a ./configure command to help you. You could read through the script but most of it doesn't make sense for Windows VS2010.
You will need to define GETTEXT_PACKAGE because it's probably setup in the configure file. I just choose UTF-8, whether that is correct or not I'm not sure.
There was a random unsigned static * that needed to be moved from a .c file to the .h file as C in VS doesn't allow you to create new variables inside functions in the particular way they were trying to do.
Read the "readme-win32.txt" file. Advice is:
hack yourself a build system somehow. This seems to be the Windows way of doing things.
Don't get your hopes up. The *nix way of doing things is the configuration script that needs to be run first. It auto-generates source files to marry the library to the specific flavor of *nix. The configuration script is almost half a megabyte. Three times as much code as in the actual .c files :) You cannot reasonably get that working without MinGW so you can execute the script. Once you got that done, you've got a better shot at it with a VS solution. As long as it doesn't use too much C99 specific syntax.
I have a simple .exe written in C++ (built with Visual Studio 2005) that tests some hardware using a supplied API. It works fine on the Windows 7 machine I built it on, but when I copy it to another (Windows 7) machine and run it (from the command-line) I get:
The application has failed to start
because its side-by-side configuration
is incorrect. Please see the
application event log or use the
command-line sxstrace.exe tool for
more detail.
What is "side-by-side configuration"?
I ran sxstrace.exe and read the usage info. It appears I would need to instrument my exe to generate a log file for sxstrace.exe to be useful?
I imagine the problem is my exe requires DLLs that either don't exist on the other machine, or are the wrong version. How do I find out what DLLs my exe uses, and what versions it links to on my machine (where it works)? Any other advice on copying it to another machine and getting it running? Would more information help?
mfawzymkh's answer to the "application has failed to start because the side by side configauration is incorrect" question (linked to in the question spirulence linked to in his answer to this question) appears to apply to this question also. mfawzymkh writes:
You can resolve this issue by either
one of these 1- Install VC8 Debug CRT
2- Build you app as statically linked
And mfawzymkh's comment on that same answer explains how to build as statically linked:
when you build it in VS, go to
projects->settings->C/C++->Code
Generation and choose Runtime Lib
options to be /MTd instead of /MDd
I did that and the side-by-side configuration message is gone. (And after installing something else for the DLL I was using, my EXE works.)
For what it's worth, I encountered the same issue. In the Event Viewer I had an error message that read:
Activation context generation failed for "C:\\MyExe.exe".Error in manifest or policy file "C:\\MyExe.exe.Config" on line 12. Invalid Xml syntax.
Sure enough, I'd changed a connection string and left out the closing quote. Added that back in and it solved the issue.
"when you build it in VS, go to projects->settings->C/C++->Code Generation and choose Runtime Lib options to be /MTd instead of /MDd" worked for me, although I was interested in the Release version instead of the Debug version.
Microsofto says:
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
/MD
Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR100.DLL, which must be available at run time to applications linked with MSVCRT.lib.
Are you suffering from the same issue as this guy? Side-by-side assemblies, Windows 7, and Visual Studio 2005
I can't seem to understand how it works.
I see there is an option /assembly available to the Script# compiler which procuces a .dll file with the .js file as a resource. Here is an example from http://www.nikhilk.net/ScriptSharpIntro.aspx:
ssc /ref:sscorlib.dll /ref:Script.ScriptFX.Core.dll /debug /assembly:HelloWorld.dll /out:HelloWorld.js HelloWorld.cs
Can I get the same result using Script# Visual Studio templates? How do I enable this option for my Script# project?
There isn't a way to produce an assembly with script embedded in it.
I think the /assembly flag might be a remnant, or is there primarily for the script# compiler to know where the assembly produced from the same code as produced by the c# compiler exists.
If you want to embed the script in that assembly, you'll need to do a two pass c# build - in pass 1, there is a placeholder script, and then in pass 2, the real generated script.
Alternatively I can think of some approaches involving ildasm, add script resource reference, and then ilasm'ing to get back a new assembly.
What is your scenario? I am curious. I've debated whether to make the two pass build be supported out of the box... but never gotten around to it, since the embedding a script was a nice-to-have.