Assume you have a .DLL file, and you want to know some basic information regarding it,
for example:
Is it a Managed (.NET) or Non-Managed (e.g. COM, etc) DLL
If it's Managed, what minimal version of .NET it requires
(and if it's non-managed, then any other minimal version that it requires? for example minimal version of Windows, or of something else)
Any other kind of such metadata
Please note that I am less interested in seeing the Function Headers (or Classes) that are inside.
Visual Studio's Object Browser can show the Functions/Classes very well,
yet I did not find a way to make Object Browser show the metadata that I mentioned above..
So maybe another utility can do it?
Related
I have been unable to find any information how would one replace Processing IDE with Visual Studio 2015 Community.
Is it even possible to replace it, if yes then how?
Processing is a couple of things:
A set of tools that convert "Processing code" into Java code, or JavaScript code with Processing.js.
An IDE that lets you write Processing code and use those tools.
A Java library (and JavaScript, for Processing.js) that is called by that converted code.
That third thing is what you care about. You can use Processing as a Java library the same way you can use any Java library. Here is a tutorial on using it from eclipse.
The steps to use it with Visual Studio will be similar: find the Processing library jar (probably called core.jar), add it to your classpath, and then write Java code that uses the classes from that library jar.
However, I will say that you should know what you're doing with both Java and Processing before trying this. Processing's IDE is designed to make things as simple as possible, so it hides a lot of behind-the-scenes stuff from you. You have to be comfortable with the idea of using an API, OOP, and setting up the classpath.
Also note that Processing 3 has changed a bunch of things, so certain aspects of that tutorial are out of date. Most notably, PApplet no longer extends Applet, so you can't treat it as a component anymore. You have to go through its Surface instead. If you have no idea what I'm talking about, it might be a better idea to stick with Processing's included IDE.
I have a DLL used in a compliance scenario (the details of which are irrelevant). The important point is that the main executeable must display the DLL version number. My solution was that the DLL has a function to return it's own version - ie obtain it from the its own version resource and return it as a string.
My reviewer says that the main program should work out the DLL version number. He even gave me some code to get the DLL module handle and extract the version using that.
My question is, which is a better design and why? My feeling is that, using OO principles, I should ask the DLL for its version number. Doing it the other way means that the main program needs to know how the version information is stored and is hence more tightly coupled to the implementation.
Note that I know exactly how to extract the version information from a DLL. My question is about the best place for the code that does this.
Can you clarify the environment that you're working in? For now, since you've already mentioned getting the module handle, I'll assume you're using C++ and calling one of a handful of Win32 functions (GetModuleHandle, LoadLibrary etc).
First of all, I'd be careful about applying OO principles in too wide a context. The object oriented paradigm helps you structure your software in a more maintainable and understandable way, the problem you're describing sounds like it maybe stretches outside of the boundaries of your application. If you want to get information about a separate resource, such as a DLL, you should consider using a standard approach to achieving this to ensure that your code is decoupled from the items that it needs to inspect.
If you introduce a function into the DLL to return the version number to your main application, you have created a tight coupling between your main application and any DLL that needs to supply it's version information (by essentially defining a bespoke API or interface for this).
You should consider using standard, platform-wide functionality to retrieve the information instead This will allow your application to version any DLL for which it can obtain a handle.
Assuming you have an HMODULE for the dll (and you're using C++), call the following functions to get the version...
GetModuleFileNameEx (to get the full path and filename of the DLL if you don't already know this)
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683198(v=vs.85).aspx
using this filename, call
GetFileVersionInfoSize (look these up on MSDN)
This will tell you some crucial information about the file's version metadata (how much info, if any the file has). Assuming this function succeeds, call
GetFileVersionInfo
This will load all the file info metadata into a buffer, then call
VerQueryValue
Supply '\' as the lpSubBlock parameter to get the standard file info metadata (including the version number)
The above functions will allow you to write code to get the version number of any module that your code can get a handle to.
Of course, if you're using C# the solution is much simpler. Hope this helps...
This post and this post says that with Visual Studio, the run time library can be static/dynamic, and it shouldn't be mixed. Even one can have debugging version/release version for the library. And there are four possibilities (static/dynamic and debug/release).
So, with Visual Studio, the library provider has to provide four different versions of the same library?
ADDED
I tried to link CppUnit test (debug) with release build library, and I got an error. So, I wondered normally library provider might need to provide all the possible combination of libraries.
depends..
under normal cicrcumstances you only provide a realease version. Then you have the option for static/dynamic. In the case of static, you don't have to provide anything since it's static: your lib already contains all functions from the crt it needs. In case of dynamic, it also depends: if you expect your clients to build applications using your lib, they already should have the required lib on their build machine. Else, yes, you can provide them with a crt installer for the dynamic release version (or just ship the corresponding dlls but that's considered rather bad practice)
Also if I remember correctly, you cannot redistribute the debug versions of VS's debug libraries, so in the end this would mean the library provider should only provide one version.
This is really the case with ANY C++ library (we have the same 4 options in our Unix side builds).
Please note that you only have to provide the debug versions if you intend them to be used by other developers, who will need them to debug - otherwise, for end users, you can only provide optimized ones.
I have an application with a plug-in architecture that is using Boost.Threads as a DLL (specifically, a Mac OS X framework). I am trying to write a plug-in that uses Boost.Threads as well, and would like to link in the library statically. Everything builds fine but the application quickly crashes in my plug-in, deep within the Boost.Threads code. Linking to the DLL version of Boost.Threads seems to resolve the problem, but I'd like my plug-in to be self-contained.
Is it possible to have two instances of Boost.Threads with such a setup (one as a DLL, one statically linked in another DLL)? If so, what might I be missing to make the two instances get along?
Once my team faced a similar problem. For reasons I will not mention at this time, we had to develop a system that used 2 different versions of Boost (threads, system, filesystem).
The idea we came up with and executed was to grab the source code of both versions of Boost we needed, and then tweak one of them to change the symbols and function names to avoid name clashing.
In other words, we replaced all references to the name boost for bubbles inside the sources (or some other name) and also made changes to the compilation so it would build libbubbles instead of libboost.
This procedure gave us 2 sets of libraries, each with having their own binaries and header files.
If you looked at the source code of our application you would see something like:
#include <bubbles/thread.hpp>
#include <boost/thread.hpp>
bubbles::thread* thread_1;
boost::thread* thread_2;
I imagine some of the guys here already faced a similar situation. There are probably better alternatives to the one I suggested above.
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!