Short and concise:
What are the actual differences between DIA (Debug Interface Access) and the DBGHELP libraries? I know that DIA is COM based and seems to be extremely powerful (as well as able to be used with managed and unmanaged processes), whereas the DBGHELP seems to be very convenient to use but offers less possibilites.
Can any one explain where these two have their differences and what can be done with the one but not with the other? I am really struggling with finding some full conclusive information on the internet :(
Sorry if this seems to be a dull question, and thanks to any answers you have for me! :)
Regards
PuerNoctis
DIA has consistent COM based interface.
DbgHelp consist of a set of standard C functions.
Here two aricles I have written about DIA (with C++ Samples), that shows the power of DIA:
Symbols File Locator
How to Inspect the Content of a Program Database (PDB) File
When possible, use DIA and not DbgHelp, since DIA can be used by any COM-aware program.
It is the same thing. DbgHelp is the core api, it is usable from C. DIA is a COM object model on top of it that just makes it easier to use and makes it accessible from most any language. It is an acronym for Debug Interface Access, emphasis on "Access". The MSDN documentation for it starts here.
Related
I am trying to re-learn directx after a decade of doing other things. I read a tutorial on the github wiki on how to render some sprites:
https://github.com/Microsoft/DirectXTK/wiki/Sprites-and-textures
In the Draw method it uses 'DirectX::SpriteBatch::Draw' and one of the overloads seems to have a parameters for an 'FXMVECTOR' and 'GXMVECTOR'. I managed to find some documentation for the former, but can't find any for the latter.
Can anyone tell me where to look?
Is it part of DirectXMath or something else?
When you see FXMVECTOR, CXMVECTOR, GXMVECTOR, or HXMVECTOR just read XMVECTOR. Same for FXMMATRIX and CXMMATRIX vs. XMMATRIX. It's just some typedef magic stuff I had to do to support the various calling conventions for x86 __fastcall, x64 __fastcall, x86/x64 __vectorcall, and Windows on ARM which are all subtlety different.
For documentation details on these types, see Microsoft Docs.
If you are new to DirectXMath, you probably want to take a look at the Simple Math wrapper in the DirectX Tool Kit.
I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.
There are many functions available in Windows API for usage,
is there any book which would act as a comprehensive reference for the APIs available in windows?
I mean the books i have been reading give a basic idea of there usage.
I would need something comprehensive,
like we have The Standard C library by Plauger. I need something like a manual (appropriately) or a book (preferably) which would divide the Windows APIs on basis of its features,etc and give the names of available functions.
Altough a bit old, Programming Windows by Charles Petzold is the bible of the Windows API. The last edition covers up to Windows 98 and NT 4.0. However it's C only.
To program in C++ with the API, you can build up your own framework, use MFC or, as I would recommend, use Qt, where you can mix API and Qt programming freely, depending on what portability to other platforms you want to achieve.
The online reference of the WinAPI is in MSDN, here: http://msdn.microsoft.com/en-us/library/ee663300(v=VS.85).aspx
That would be one hell of a big book - the Windows API is huge, and the C Standard library is tiny in comparison. Is there some reason that MSDN does not work for you?
I have a desktop program I downloaded and installed. It runs from an .exe file.
Is there some way from the .exe file to tell what programming language was used to write the program?
Are there any tools are available to help with this?
What languages can be determined and which ones cannot?
Okay here are two of the sort of things I'm looking for:
Tips to Determine Whether an App is Written in Delphi or Not
This "IsDelphi" program by Bruce McGee will find all applications built with Delphi, Delphi for .Net or C++ Builder that are on your hard drive.
I use WinDowse (a small freeware utility written in Delphi) to spy the windows of the program.. for example if you look at the "Class" TabSheet you can discover the "Class" Name of the control..
For example:
TFormXX, TEditYY, TPanelZZZ for delphi apps
WindowsForms10.XXXX.yyy, for .NET apps
wxWindowsXXX for wxWindows apps
AfxWndXX for MFC/VC++ apps (I think)
I think this is the fastest way (although not the most accurate) to find information about apps..
I understand your curiosity.
You can identify Delphi and C++ Builder apps and their SKU by looking for a couple of specific resources that the linker adds. Specifically RC Data\DVCLAL and RC DATA\PACKAGEINFO. The XN Resource Editor makes this a lot easier, but it might choke on compressed EXEs.
EXE compressors complicate things a little. They can hide or scramble the contents of the resources. Programs compressed with UPX are easy to identify with a HEX editor because the first 2 sections in the PE header are named UPX0 and UPX1. You can use the app to decompress these.
Applications compiled with .Net aren't difficult to detect. Recent versions of Delphi even include an IsAssembly function, or you could do a little spelunking in the PE header. Check out the IsManaged function in IsDelphi.
Telling which .Net language was used is trickier. By default, VB.Net includes a reference to Microsoft.VisualBasic, and VCL.Net apps included Borland specific references. However, VCL.Net is defunct in favour of Delphi Prism, and you can add a reference to the VB assembly to any managed language.
I haven't looked at some of the apps that use signatures to identify the the compiler, so I don't know how well they work.
I hope this helps.
First, look to see what run time libraries it loads. A C program won't normally load Visual Basic's library.
Also, examine the executable for telltale strings. In most executables, this is near the end. If the program uses string constants, there might be a clue in how they are stored.
A good disassembler, plus of course an excellent understanding of the underlying CPU architecture, can often help you identify the runtime libraries that are in play. Unless the exe has been carefully "stripped" of symbols and/or otherwise masked, the names of symbols seen in runtime libraries will often provide you with programming-language hints, because different languages' standards specify different names, and vendors of compilers and accompanying runtime libraries usually respect those standards pretty closely.
Of course, you won't get there without knowledge of the various possible languages and their library standards -- and if the code's author was intent to mask the information, that's not too hard for them to do, either.
If you have available a large set of samples from known compilers, I should think this would be an excellent application for machine learning. I believe so-called "supervised learning" is relevant here. Unfortunately I know next to nothing about the topic—only that I have heard some impressive results presented at conferences.
You might dig through the proceedings of the Working Conference on Reverse Engineering to see if anyone else is interested in this problem.
Assuming this is an application for Windows...
Does Reflector recognize it as a .NET assembly? Then it's MSIL, 99% either VB or C#, but you'll likely never know which, nor does it matter.
Does it need an intrepreter (like Java?)? Then it's Java (or whatever the interpreter is.)
Check what runtime DLLs it requires.
Does it require the VB runtime dlls? Congratulations, VB from VisualStudio 6.0 or earlier.
Does it require the Delphi dlls? Congratulations, Delphi.
Did you make it this far? C/C++. Assume C++ unless it requires msys or cygwin dlls, in which case C has maybe a 25% chance.
Congratulations, this should come out correct for the vast majority of Windows software. This probably doesn't actually help you though, as a lot of the same things can be done in all of these languages.
IDA Pro Free (http://www.hex-rays.com/idapro/idadownfreeware.htm) may be helpful. Even if you don't understand assembly language, if you load the EXE into IDA Pro then its initial progress output might (if there are any telltale signs) include its best guess as to which compiler was used.
Start with various options to dumpbin. The symbol names, if not carefully erased, will give you all kinds of hints as to whether it is C, C++, CLR, or something else.
Other tools use signatures to identify the compiler used to create the executable, like PEiD, CFF Explorer and others.
They normally scan the entry point of the executable vs the signature.
Signature Explorer from CFF Explorer can give you an understanding of how one signature is constructed.
It looks like the VC++ linker from V6 up adds a signature to the PE header which youcan parse.
i suggest PEiD (freeware, closed source). Has all of Delphi for Win32 signatures, also can tell you which was packer used (if any).
I was curious as to how does one go about finding undocumented APIs in Windows.
I know the risks involved in using them but this question is focused towards finding them and not whether to use them or not.
Use a tool to dump the export table from a shared library (for example, a .dll such as kernel32.dll). You'll see the named entry points and/or the ordinal entry points. Generally for windows the named entry points are unmangled (extern "C"). You will most likely need to do some peeking at the assembly code and derive the parameters (types, number, order, calling convention, etc) from the stack frame (if there is one) and register usage. If there is no stack frame it is a bit more difficult, but still doable. See the following links for references:
http://www.sf.org.cn/symbian/Tools/symbian_18245.html
http://msdn.microsoft.com/en-us/library/31d242h4.aspx
Check out tools such as dumpbin for investigating export sections.
There are also sites and books out there that try to keep an updated list of undocumented windows APIs:
The Undocumented Functions
A Primer of the Windows Architecture
How To Find Undocumented Constants Used by Windows API Functions
Undocumented Windows
Windows API
Edit:
These same principles work on a multitude of operating systems however, you will need to replace the tool you're using to dump the export table. For example, on Linux you could use nm to dump an object file and list its exports section (among other things). You could also use gdb to set breakpoints and step through the assembly code of an entry point to determine what the arguments should be.
IDA Pro is your best bet here, but please please double please don't actually use them for anything ever.
They're internal because they change; they can (and do) even change as a result of a Hotfix, so you're not even guaranteed your undocumented API will work for the specific OS version and Service Pack level you wrote it for. If you ship a product like that, you're living on borrowed time.
Everybody here so far is missing some substantial functionality that comprises hugely un-documented portions of the Windows OS RPC . RPC (think rpcrt4.dll, lsass.exe, csrss.exe, etc...) operations occur very frequently across all subsystems, via LPC ports or other interfaces, their functionality is buried in the mysticism incantations of various type/sub-type/struct-typedef's etc... which are substantially more difficult to debug, due to the asynchronous nature or the fact that they are destine for process's which if you were to debug via single stepping or what have you, you would find the entire system lockup due to blocking keyboard or other I/O from being passed ;)
ReactOS is probably the most expedient way to investigate undocumented API. They have a fairly mature kernel and other executive's built up. IDA is fairly time-intensive and it's unlikely you will find anything the ReactOS people have not already.
Here's a blurb from the linked page;
ReactOS® is a free, modern operating
system based on the design of Windows®
XP/2003. Written completely from
scratch, it aims to follow the
Windows® architecture designed by
Microsoft from the hardware level
right through to the application
level. This is not a Linux based
system, and shares none of the unix
architecture.
The main goal of the
ReactOS project is to provide an
operating system which is binary
compatible with Windows. This will
allow your Windows applications and
drivers to run as they would on your
Windows system. Additionally, the look
and feel of the Windows operating
system is used, such that people
accustomed to the familiar user
interface of Windows® would find using
ReactOS straightforward. The ultimate
goal of ReactOS is to allow you to
remove Windows® and install ReactOS
without the end user noticing the
change.
When I am investigating some rarely seen Windows construct, ReactOS is often the only credible reference.
Look at the system dlls and what functions they export. Every API function, whether documented or not, is exported in one of them (user, kernel, ...).
For user mode APIs you can open Kernel32.dll User32.dll Gdi32.dll, specially ntdll.dll in dependancy walker and find all the exported APIs. But you will not have the documentation offcourse.
Just found a good article on Native APIS by Mark Russinovich