Where can I find msvcrtd.dll (the debug CRT), corresponding to \WinDDK\7600.16385.1\lib\Crt\i386\msvcrtd.lib in the Windows Driver Kit?
Having the same DDK on my system, I cannot find the file , however, you can do it with some tools or programatically:
if you are using a program thats loading that dll, you can use windbg to display the module info (which should include the path), else you can use one of the psapi functions.
After some poking around, it would seem from this article that there is no longer a public msvcrtd.dll to use with the WDK, it does however give some advice on using alternatives. MSDN also supports the fact that there is no longer a debug CRT, as there only methods for debugging involve the debug API and/or WinDBG. However I suspect that the dll might be available from a checked build of windows.
Seems like it's not distributed.
Related
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.
This may be the wrong place...but since it's actually regarding a GUI toolkit I figured it might be appropriate here.
Anyways theres a Program (For anyones reference it's actually an automated modding thing for a game called Morrowind). Anyways it has a nice clean GUI layout, it's for Windows. And basically im trying to find out just what toolkit was used.
I've tried contacting the author, and I haven't seen anything about what was used mentioned anywhere. Is there any chance I could find out someway which toolkit was used in making this Program?
Or is that technically private information?
If the program runs on MS-Windows, Dependency Walker allows you to find out which libraries the program requires. The required libraries might give you a hint about which GUI toolkit was used.
On other platforms, ldd is often available and gives you similar information.
This only works if the GUI toolkit is dynamically linked.
How to debug mingw built binaries to detect heap errors? I see there are several questions on the topic, but they are general and it's hard to find the tool that would work well with MinGW. I spent much time on finding the solution, I hope the combined topic will be helpful.
Such a tool becomes necessary when for example someone reports a bug in your library while running it under Visual Studio debugger, which stops with a "Heap Error".
There is a tool provided by Microsoft called Application Verifier. It is a gui tool that changes system settings to run selected applications in a controlled environment. This makes it possible to crash your program if it causes detectable memory errors. This is a controlled crash that can be debugged.
Fortunately it is obtainable from Microsoft as a separate download. Another way to get it is to have Windows SDK installed with checked Application Verifier checkbox. SDK offers also an option Application Verifier redistributable.
After you configure Application Verifier to have an eye for your app, you need to debug it. Debugging under MinGW is a more common subject, already explained on stackoverflow. [mingw] [debugging] query on stackoverflow gives interesting articles. One of them is How do I use the MinGW gdb debugger to debug a C++ program in Windows?. Gdb is the one I used.
The general questions How to debug heap corruption errors? and Heap corruption detection tool for C++ were helpful to find this tool, but I wasn't sure if it is compatible with MinGW. It is.
I've got a working proprietary application (windows exe) and would like to know which particular toolkit was used to make it. The reason is that I like the widgets it uses and seek to use same library in my project (to buy it if it's proprietary as well).
Just use Process Explorer to see what DLLs the application has loaded. That will be your widget set. Sort the results by folder to roughly group them by manufacturer. You may need to examine the properties of the DLLs for more detailed info as well.
If the library is statically linked you may have to do some deep looking around, maybe you'll get lucky and find a string saying the name of the library or a class/function in it. You can use OllyDbg for this to view strings loaded at runtime, or something like the linux command strings to look through statically, although that wont work if the program decodes itself at startup. If that doesn't work, you'd have to come up with a list of libraries that do what the one you are looking at does, and find some artifacts in the binary that are common between the two. Anyways, better to check the dlls first like Paul Sasik said.
You can use PEiD to identify the compiler, which can be a hint aswel. PEiD also has a nice process explorer.
For instance, Google Chrome uses C:\WINDOWS\SYSTEM32\IEFRAME.DLL :-) Nice isn't it?
(Don't trust it 100%. For instance, my own compiler has the "Morphine 1.2 - 1.3 -> rootkit" description, which I find quite awkward: that's a packer/compiler trace obfuscator.)
I've scoured Google and found to large a variety of tools and answers. I want to disassemble a DLL into something at least readable, e.g. recognise Win32 API calls by their names etc. How do I go about this?
Check out THIS. Any of them can work for you but IDA rocks...
I think what you're looking for are the Windows Symbol Packages. When you install these, you're basically getting symbol information (debugging info) for the majority of the Windows API, including Kernel32 and advapi (which I find to be the two biggies in my programming).
You might need to tell your debugger and/or compiler where the symbols live though - just make sure you remember where they install to, then you can use a debugger option (sometimes called "sympath") to tell the debugger where to find them.