I am trying to figure out what the browse information (.sbr files) is used for but find only references how to create it. So what is it for?
Thanks
Dima
Read here (Visual C++ Team Blog: IntelliSense History, Part 1)
Capturing information about a C or C++
program’s structure has been around
for a very long time in Microsoft’s
products. Preceding even Visual C++
1.0, the compiler supported generating program information through .SBR and
.BSC files. (Note: The compiler in
Visual C++ 1.0 was already version 8,
so the command line tools had been
around a while already.) The SBR
files contain reference and definition
information for a single translation
unit that the compiler generates as it
compiles. These SBR files are
combined in a later step using the
BSCMAKE tool to generate a BSC file.
This file can then be used to look at
many different aspects of a program:
reference, definitions, caller-callee
graphs, macros, etc.
.sbr is pretty much Visual Studio's ctags - an index of symbols with backreferences to the source. When available, it's used by "Find Symbol" and other similar tools. It's more accurate than the built-in VS parser, because C++ can be tricky, and the real compiler can do a better job (though that is not quite true in VS2010 anymore).
At one time browse info drove the "Go to definition" engine, but that has been reworked in later version of Visual C++. Some third-party tools still use browse info (can't remember for sure, but I think one of Rational's tools does) to cross-reference code.
I always disable it, to shorten build times.
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'm happily developing a language in ANTLR 4.4 / ANTLR4CS, and I'd like to start integrating my language into an IDE. The natural place for me feels like integrating it into Visual Studio. It occurs to me that someone might have figured out a general way to plug an ANTLR lexer into the Visual Studio syntax highlighting system, or ANTLR parsers into an MSBuild task such that errors appear in the Visual Studio error list.
Is there any kind of starting point, base package, plugin system, or similar which lets you integrate an ANTLR4CS language with Visual Studio's language support mechanisms?
Alternatively, has anyone had any success building, say, a Sublime Text build system / language def automatically from their grammar?
#Lucas Trzesniewski wrote:
I did this by reparsing the whole file every time, doing it on a line-by line basis was too much of a PITA for my needs (and our DSL files are small so it works fine).
I don't know if it'll be suitable for your needs, but you can implement a single file generator from a VS extension. The Generate method takes a IVsGeneratorProgress parameter which lets you report errors easily.
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.
Porting legacy PB code to the .NET era might require major refactoring, to get the work done properly. Our code, for instance, has some pre-userobject leftovers, as well as deprecated features such as MDI, PBNI etc. I'm wondering how much help will we get from the VS shell when it comes to refactoring capabilities - breaking long functions into separate ones, finding all callers of a certain function or event etc.
The classic IDE is horrible for such tasks. Has using VS now made them easier?
The answers to your questions are YES for the most part but not as cool as in Visual Studio. The PB IDE is night and day better than it was just not quite up to the full Visual Studio IDE.
PB does have some basic refactoring built in, for example something like a function rename across the entire project can be done easily. Here is the output generated when I renamed a function in one of my projects. And I had one of the files opened, the Visual Studio Shell detected it and asked me to reload the local file.
Replace all "ConnectDB", "DBConnect", Subfolders, Find Results 1, "Entire Solution"
H:\Dev\PBWS\pb_data.pbl\pb_data.sra(42,18):liRtn = gnv_data.DBConnect()
H:\Dev\PBWS\pb_data.pbl\n_data_factory.sru(29,25):public function integer DBConnect ()
H:\Dev\PBWS\pb_data.pbl\n_data_factory.sru(38,14):liRowCount = DBConnect()
H:\Dev\PBWS\pb_data.pbl\n_data_factory.sru(103,25):public function integer DBConnect ();
Total replaced: 4 Matching files: 2 Total files searched: 13
PowerBuilder 12.5.NET does have "Go To --> Definition" ability for jumping to function/class declarations. It isn't as cool as Visual Studio in that the PowerBuilder functions aren't as "open" as the .NET framework so you can't right click on GetItemString function and expect to see the internal declarations.
I haven't seen any impact analysis type features yet, like the ability to see where your functions are being called, but I haven't looked too hard yet.
On a positive note Sybase has incorporated the awesome intellisense / code completion of Visual Studio. It is responsive, accurate, and predictive much like when working in Visual Studio IDE doing C#. The PB.NET features along with nice stuff from Visual Studio Shell make PB development fun to work with again.
Whats the easiest way to find out what programming language an application was written in?
I would like to know if its vb or c++ or delphi or .net etc from the program exe file.
Try PEiD
of course if they used a packer, some unpacking will need to be done first :)
Start it up and check what run-time DLLs it uses with Process Explorer.
If that doesn't make it immediately obvious, search the web for references to those DLLs.
Most disassemblers (including Olly I think) can easily show you the text contained in an EXE or DLL, and that can also sometimes give a clue. Delphi types are often prefixed with T as in TMyClass.
If it's a small executable with no DLL references and no text you might be SOL. At that point you'd need to look for idioms of particular compilers, and it would be mostly guesswork.
There is an art to detecting what language a program was written in. It is possible but there are no hard and fast rules. It takes a lot of experience (and it also leads to the question "Why would you want to..." but here are a few ideas on how to go about it.
What you're looking for is a "signature". The signature could be a certain string that is included by the compiler, a reference to an API that is quite common in the programming tool being used, or even a style of programing that is common to the tools being used, visible in the strings contained in the application.
In addition, there are styles to how an application is deployed: various configuration files found in the deployment directory, dlls and assemblies and even images, directories or icons.
Java applications wrapped in a self-launching executable will contain references to java libs, and will likely have certain libraries or files included in the same directory that indicate that it's java.
As indicated in other answers a managed assembly will show certain signs as well: you can open it in Reflector etc. While it is correct that c# and VB are "interchangable" once compiled, it is not true that they are identical. If you use Reflector to disassemble VB code you will quite often see that the assembly references the Microsoft.VisualBasic.dll assembly. You'll be able to tell the difference between Mono applications because they will most likely contain references to the mono assemblies.
Many compilers assemble and link code in certain ways, and leave footprints behind. For example, examining a window executable using "strings: tab in Process Explorer, you'll see a lot of strings. Using these you may be able to determine programming styles, methods called, error or trace methods withint the exe.
An example is that compilers use different mechanisms for localization: Microsoft stores localized strings in XML files or resource files. Other compilers will use a different tactic.
Another example is c++ name mangling. The CodeWarrior compiler uses a different algorithm to mangle the names of the member variables and functions of a call than Visual Studio.
I suppose you could write a book on the subject of accurately determining the lineage of any executable. This subject would probably be called "programming archeology".
You could try using Depends to see what runtime dependancies it has, which might give some clues.
The easiest way is to ask the developer of the program. It does not require any knowledge and utility programs.
Determine Delphi Application
Use eda_preview270.exe (from here) or some other spy tool and check the window class names. If they read like TButton or TfrmBlubb, it's a VCL app. If there is an "Afx" in them, it's probably MFC.
Compiled languages (by this I mean no scripting languages, or Java, .NET, etc.) are compiled into CPU assembly instructions, which is essentially a one-way conversion. It is not usually possible to determine which language a program was written in. However, using a dependency walker, you could potentially determine which runtime library the program was loading (if any) and therefore determine which language it used (e.g. MS Visual C++ 9 uses msvcr90.dll).
you can check is that a .net assembly or not by trying to open with ildasm.exe tool
PE Detective works best for me.
In general, you can't.
If you can load it into Reflector, you know it is a managed assembly.
That's a good question. There isn't any general way to tell, but I bet most compilers and libraries leave a mark in the resulting EXE file. If you wanted to spend a lot of time on it, you could gather a bunch of EXEs written in known languages and scan for common strings. I would image you'd find some.
Dependancy Walker, which someone else mentioned would be a good way to look for telltale dependencies, like versions of MSVCRT, etc
i'd try running the .exe thru a 'strings' program to get assorted hints.
If I remember correctly PE Explorer Disassembler gives some information about compiler that creates given not .net and java binary, for .net use Reflector or ILDAsm tool
The easiest way that I found (at least in computer games) was to look in the "redist" folder nested within the game's main folder. It might be obvious to some of you that are more experienced in programming yourself, but the specific purpose of the MSI in this folder is to allow the setup.exe file to automatically install the prerequisites for the game itself.
For example:
In Empire Total War, there is an MSI called "vcredist_x86-sp1.exe". This indicates that the game/program was written in Microsoft's "Visual C 2005" in the .NET Framework (usually).
In fact, if you open the MSI/EXE, the installer should immediately indicate the language it's written in and which version.
The reason I'm familiar is because I code in C# and VB in the .NET Framework and we auto-install the prerequisites for our business app.
Hope this helps!