sometimes I have to debug an application that was written with Borland C++ Builder. This application loads dlls compiled with Visual C++. Is there a debugger that can debug both parts of the application? Currently I have to decide - either I can easily set break points and see the source in Visual Studio or I have to start Borland C++, but I can't work with the source from the Visual-Studio compiled dll.
thank you for your help,
Tobias
You could try OllyDbg - version 1.x does not seem to support the latest Win version but there is also the 2.0 although it's still in alpha state(haven't tried myself that one yet).
EDIT - clarification:
Source debugging OllyDbg reads debugging information in Borland and
Microsoft formats. This information includes source code and names of
functions, labels, global and static variables. Support for dynamical
(stack) variables and structures is very limited.
The above is take from here.
UPDATE:
I'm not familiar with the Borland C++ Builder but at this link you can find some articles explaining how to deal with some interoperability issues between Borland and MS that might be of help.
if both parts built using ulink linker and have debug info you could try cdb32 debugger (from the ulink linker author)
cdb32 is still in its alpha stage though and I personally never tried such "mixed" debugging
Have you tried loading the DLL code in VS, loading the app code in BCB, and having both debuggers attached to the same running process at the same time? Not sure if Windows will allow that, but it might be worth a try.
I suspect there is no perfect answer to your question, you are going to have to compromise in some way, as I'm sure you are already doing.
I have a similar problem to yours at work. The applications that I work on are written in Python instead of Borland C++, but like your situation, these apps rely on a rather large Visual Studio compiled DLL for some functions.
My method of debugging these applications involves a combination of two debugging strategies: the use of an interactive debugger and the so called "printf" debugging technique.
What I basically do is pick one of the two areas as my main debug focus, and that determines my debugging approach:
If for a given situation I decide that I need to debug the DLL with greater detail, then I work with the VS debugger. I set the executable to run in the DLL project as my python script and that enables full debugging of the DLL code. If I need debugging support from the Python side, then I add print statements. If I need a breakpoint on the Python side to inspect some values, I just print all those values and immediately after call a C++ function that does nothing, but that has a breakpoint set in VS.
When I need to concentrate more on the Python side more I use a Python interactive debugger, but I have VS with the DLL project loaded on the side so that I can quickly add any necessary printfs on the DLL and recompile, so essentially the reverse of the above.
I know it's not the answer you expect, but it is a decent solution in my opinion.
It looks that it is possible to convert the debugging information generated by C++ Builder to a format understood by WinDbg (link to discussion). If so you could use it to debug both parts of your application (I haven't tried this though).
you can convert the .map files to Microsoft's debug file format
http://code.google.com/p/map2dbg/
now you can use Windebug; there is also a tool mentioned to convert to pdb format, so you could try the vc++ debugger
Related
It's my first time using Visual Studio 2017. I built a simple program in C++ on my PC. I was curious to see if my program works on another PC. I tried to execute the .exe on the other computer and it gave me this kind of error:
vs(some letters and numbers).dll is missing.
I assume that the .dll in question is part of Visual Studio.
I tried on a third PC, and this time the cmd stops working and becomes unresponsive after I execute my .exe.
I also have this problem when I compile with MinGW using the g++ compile feature in the cmd. When I execute the program compiled with MinGW on another PC, it gives me the same error, but this time it says something like
gw...dll is missing
Is there a way to avoid this error without installing the Visual Studio (or MinGW at this point) on any other PC I want my program to run on?
If you're interested in the code, I can put it here, but I don't think it's the problem here because I have the same issue for every other .exe compiled on my PC.
Here's a picture of the error:
In case of Visual Studio, you need to install Visual C++ Redistributable libraries or provide the libraries that are required by your application with .exe file (I am not sure if it violates license or not though).
In case of MinGW, you need to provide required DLL as well. I guess that you need libgcc_s_dw2-1.dll and libstdc++-6.dll, but you would better check it yourself. And remember about the license.
You may use Dependency Walker to analyse dependencies of your application.
UPDATE (2017-12-12):
I've missed the time you posted the screenshot. As far as I see from it the problem is that you are trying to run debug version of your executable: ucrtbased.dll is the debug version of the ucrtbase library and is only available (from what I know) from Visual Studio distribution. If you want to run your application on the computers that do not have installed Visual Studio, then you should use the Release version of your application.
In order to understand your problem you need to understand the concept of DLL.
Dynamic-link library(DLL) - As described by Microsoft:
A DLL is a library that contains code and data that can be used by
more than one program at the same time. For example, in Windows
operating systems, the Comdlg32 DLL performs common dialog box related
functions. Therefore, each program can use the functionality that is
contained in this DLL to implement an Open dialog box. This helps
promote code reuse and efficient memory usage.
So to put it simply, DLL is basically a bunch of compiled code, which is being linked to your code at load (or even run-time). Now, of course if your system is missing the DLL, your progrem will fail to work. To make things even worse, DLL are sensitive to the compiler that was used. So each DLL might have multiple version, so you will need to right DLL.
Now to the problem itself, the error message are the best way to start. They guide you what DLL are missing, and what is their name. For instance in your case "vs*.dll" is most likely related to Visual C++ runtime redistributable.
Finally, please note you have another consideration to make in addition to make your own system work: Every one that will use your code might face the exact same problem. So if you actually intend to share your .EXE with other people, you will need to understand how to guide them, or even automate their installation process.
I'm a hobbyist developer and have a background with Java (IDE of choice was Eclipse). I'm using Visual Studio Express 2010 and wanting to learn C++.
Few questions:
I create a "HelloWorld" in C++ and compiles/runs in VS/Windows. When I try to compile it under Linux/GCC, it obviously throws tons of errors. Default windows console project includes windows specific files; but if just create an "Empty Project" it throws tons of linker/build errors. What's the best practices here to keep my code portable?
Why is it creating 47 files for 8 lines of code?
How do you format code? You can do Edit->Format Selection, but the hotkeys don't work?
How do I output to VS's 'Output' Window? ( like eclipse does when you run a console java app )
It keeps reverting my "Project Location" to my "home directory" every time I restart. How do you change it? Is it a bug? Because it's Express edition?
Is there a way to keep it from switching to Debug view when it runs?
I create a "HelloWorld" in C++ and
compiles/runs in VS/Windows. When I
try to compile it under Linux/GCC, it
obviously throws tons of errors.
Default windows console project
includes windows specific files; but
if just create an "Empty Project" it
throws tons of linker/build errors.
What's the best practices here to keep
my code portable?
For portable code, avoid VS wizards entirely. Use Make/NMake if you're starting with rocks and sticks, or the portable build system of your preference (Ant, CMake, etc.) Some of these will spit out a VS solution/project file for you to use.
Why is it creating 47 files for 8
lines of code?
Wizards are magical like that.
How do you format code? You can do
Edit->Format Selection, but the
hotkeys don't work?
Ctrl-K Ctrl-F (under Edit, Advanced)
How do I output to VS's 'Output'
Window? ( like eclipse does when you
run a console java app )
Lookup OutputDebugString() for the debug window. Output window should get all cout/cerr output.
It keeps reverting my "Project
Location" to my "home directory" every
time I restart. How do you change it?
Is it a bug? Because it's Express
edition?
Probably hidden in options somewhere - don't know that one, sorry.
Is there a way to keep it from
switching to Debug view when it runs?
Launch using Ctrl+F5 to run without the debugger attached.
Have fun!
I create a "HelloWorld" in C++ and compiles/runs in VS/Windows. When I try to compile it under Linux/GCC, it obviously throws tons of errors. Default windows console project includes windows specific files; but if just create an "Empty Project" it throws tons of linker/build errors. What's the best practices here to keep my code portable?
It's fairly difficult to keep your code truly portable if you're writing Windows applications. Standard C++ will obviously work on either platform, but Linux can't run Windows applications, and vice versa. Remember that console applications are also considered Windows applications. They're not any more "pure" just because they are text-based, rather than graphical. Windows applications have their own entry point, different from the standard main function found in ANSI C++ (technically, main is still there, but it's hidden and called internally by the Windows libraries).
The best thing to do is not to link to any of the Windows headers. Unfortunately, you won't be very satisfied with the results. About all that you'll be able to generate is library code. You can't get a UI on the screen unless you use the Windows functions to do it.
An "Empty Project" is just what it says—empty. I assume the build errors are because you're trying to call functions that aren't defined anywhere. You'll find that you need to include windows.h to get off the ground, which instantly makes your code non-portable.
Why is it creating 47 files for 8 lines of code?
This is obviously an exaggeration; none of the wizards produce anywhere near that many code files. Especially not the "Empty Project", which doesn't create any at all.
A Win32 console application includes the following 5 files:
stdafx.h and stdafx.cpp — these files are used to enable "precompiled headers", meaning that Visual Studio will compile all of your headers once, and only recompile them when they change, rather than recompiling them each time you build the project. This used to provide enormous speed boosts, and still does on large projects. You probably don't need or care about this for small projects, but it's not a bad idea to get familiar with their usage if you're going to be developing in Visual Studio.
A targetver.h file, whose only purpose is to specify the earliest version of Windows that you want your application to run on. This is necessary because later versions of Windows add additional functionality that wasn't available in previous versions. Your app won't run if you link to functions or libraries that don't exist. Set this up once and then forget about it.
A <projectname>.cpp file, which is the implementation code for your application. This is pretty standard stuff—it includes the _tmain function, which is the entry point for a console app.
A ReadMe.txt file, which you can immediately delete. It contains some introductory information and describes the files that have been added to your project. (Yes, reading this yourself could have answered this question.)
A Win32 application would have a few more files, but most of the same ones as well. In particular, you'll see a resource file (with the extension .rc) that contains the icons, dialogs, bitmaps, cursors, etc. used in your program.
If you don't like this structure, you can either forgo the use of a wizard, or modify it yourself. There's nothing set in stone about it.
How do you format code? You can do Edit->Format Selection, but the hotkeys don't work?
Formatting code works fine. I'm not sure why people are telling you that Visual Studio doesn't support this, or that you'll need a third-party plug-in. There's no "Format Document" command as there is in C#, but the "Format Selection" command works just fine. The only difference is, you have to select something in order for it to be enabled.
The default keyboard extension for that command is CtrlK, Ctrl+F. It also works fine, right out of the box. My typical workflow is to hit Ctrl+A first to select all.
How do I output to VS's 'Output' Window? ( like eclipse does when you run a console java app )
I don't know what Eclipse does, nor do I know anything about Java. What do you want this to do? When and what things do you want to get written to the "Output" window? A console application will run in a console window, not in the "Output" window. That's not what it's for.
It's intended for debugging purposes. The OutputDebugString function is one way of utilizing it. The output of the standard cerr keyword should be automatically redirected to the "Output" window.
It keeps reverting my "Project Location" to my "home directory" every time I restart. How do you change it? Is it a bug? Because it's Express edition?
This isn't a bug, it's a feature. Visual Studio is designed for working with projects and solutions, not one-off code files. So by default, it prompts you to specify a project folder, a location to store your files. And what better place for the default location than your home folder?
If you don't like that location, you can change it. Under the "Tools" menu, select "Options". Expand the "Projects and Solutions" category, and click the "General" item. Then, change the path of the "Projects location" (the top textbox). Couldn't get much simpler than that.
Is there a way to keep it from switching to Debug view when it runs?
I frankly don't understand how this question makes any sense at all. When you run an application with the debugger attached, Visual Studio switches to a different window layout specifically optimized for debugging. I just answered a similar question. The upshot is that there's no way of telling Visual Studio to use the same window layout for both design and debug view, but I also can't imagine why you'd want to, either. Different things are useful, depending on what you're currently doing.
The two window layouts are customizable, and your changes are remembered. I've customized mine heavily from the defaults; it's very likely that your tastes vary as well. There are lots of great features, like the "Locals" window, which shows a listing of all the values of the local variables in scope at the point where you break into your program's execution.
Also remember that the default "Debug" and "Release" build configurations have nothing to do with whether or not Visual Studio automatically attaches the debugger to your application's process. If you want to start your app without the debugger attached, select "Start without Debugging" from the Debug menu, or press Ctrl+F5. There are lots of side effects to this though, and it's probably not what you wanted. Without the debugger attached, you lose most of what Visual Studio provides to you as an IDE. You might as well just run the app from Windows Explorer without even launching VS.
Finally, if you prefer Eclipse (or at least are already accustomed to its nuances and prefer not to learn Visual Studio's), you can still use it for C++ development. Download it here.
If you're just wanting to learn C++ and you don't necessarily care about the platform, I would probably avoid using Visual Studio to start with. Visual Studio provides some functionality for managing projects and builds, but honestly, I think you're better off learning how to manage code files and use the compiler on the command line first, then working up from there.
If you're on Windows, I'd recommend installing Cygwin and getting the GNU compiler tools through the Cygwin setup utility (gcc or g++).
This is a bit of an opinionated answer, but my experience with C++ on Windows leads me to believe that you'd be better served trying to learn C++ from more of a unix-like angle. Windows C++ adds a whole layer of crap that will just confuse you when you're getting started.
I know that VS 2008 Team Edition has a profiler, but I'm also aware of the recent trend they have at Microsoft of completely ignoring unmanaged languages (what's the last time unmanaged C++ got something cool in the IDE?!).. For example I know for a fact that the IDE "Unit Tests" and "Code Metrics" features don't work with unmanaged code.
I tried to google but didn't find any info; so, does anyone know if it works or not?
Yes, it works with native code.
Well I tried it and it does not produce any useful info. For example, in the "Functions" view the source file name is shown as for everything. And yes I am building the release version and have turned on debug info (tried both /Z7 and /Zi). I also tried both Instrumentation and Sampling methods with the same (non) results.
My previous comment last something as stuff in < > was lost. Source files are shown as "Unknown" and I can only see the relative time in each module. This is not a lot of use. How do I get decent output? (Give me TrueTime for VS2008!!)
I know the title makes little sense, mostly because it's hard to explain in just one line. So here's the situation:
I have a program who's binary is targeted at Windows 2000 and newer. Now, I went ahead and added some code to check if the user is running under Vista/7, and if so then check if Aero/DWM is enabled. Based on this I'll disable some stuff that isn't relevant to that particular platform, and enable some other features. My main problem is that in order to call DwmIsCompositionEnabled from Visual C++ 2008 I have to add the dwmapi.lib file and compile against it. Running the binary in anything other than Vista or 7 gives the "Unable to locate component. The application failed to start because dwmapi.dll was not found" error. This, of course, is expected to happen since DWM is new and not available for older platforms.
My question is then: will it be possible for me to somehow manage to pull this off? One binary for all OS versions AND include that DWM check code? This program was written under Visual Studio 2008, Visual C++ using MFC.
Turns out I can just tell the linker to delayload the dwmapi.dll.
I'd like to thank ewanm89 because something he said sort of resonated and led me down the path to finding the actual answer.
The normal solution is to use LoadLibrary() and GetProcAddress(). Both can be done after your program started. But still +1 for the DelayLoad solution, which does the same for you behind the scenes.
I have a native C Dll that calls 'LoadLibrary' to load another Dll that has the /clr flag turned on. I then use 'GetProcAddress' to get a function and call it on dynamically loaded dll. I would like to step into the dynamic library in the debugger, but the symbols never load. Any idea?
And I should have said I'm using Visual Studio 2008.
Update: Thanks to some tips below, I changed the project debugging to Mixed. It didn't work, but I think I know why. I am developing an addin to an existing application. The app I'm connecting to starts one exe then it starts another. So I have to use "Attach to process" to fire up the debugger. My guess is launching the debugger that way will default to "Auto". Is there a way to change the default behavior of VS to use "Mixed" debugging?
This is from VS2008, but if I remember correctly VS2005 was similar. In the native project's properties, under "Configuration Properties->Debugging" there is a "Debugger Type" which is set to "Auto" by default. You'll need to change it to "Mixed", because VS isn't smart enough to realize you need managed debugging
I've had mixed experiences with doing similar things like this in VisualStudio. You might consider using ProcMon to see where VisualStudio is looking for the PDB file. Alternatively, you might try using WinDbg. It seems to do better at loading symbols and if it doesn't, you can explicitly load them yourself. Using WinDbg involves riding a steep learning curve, but if you're burning time right now, isn't it worth it?
You can also run the exe on its own and from the source of the managed dll, attach to the process to debug it.
Modify the mixed-mode dll to throw a CLR exception where it enters the first code you're interested in debugging. This should give you an opportunity to launch the managed debugger.
In VS2005, there are per-project options to enable native and CLR debuggers separately. You might need to enable the CLR debugger for the native dll project from which you start the debugger.