Visual Studio 2005 Runtime Dll's!

Started by
2 comments, last by maxpenguin 17 years, 6 months ago
First question is What's the difference between /MT and /MD that I need to know about when making a game. Currently I'm compiling /MT so I don't need the manifest files and don't need to include any of the runtime dll's. However, MD does decrease my exe file of course, but then i need to include those 2 dlls. MSVCP80.DLL and MSVCR80.DLL Is there any trick or method I can do so I don't need those runtime dlls, or just stay with /MT My other off subject question is when im in debug mode, and I do a Break All command, and in the stack im in NT.DLL.... which is totally useless for me. I changed the options to debug my code only, but it still shows up under nt.dll. http://msdn2.microsoft.com/en-us/library/h5e30exc.aspx "Programmatic break statements, such as Visual Basic Stop statements, are handled differently. The debugger always breaks on these statements, even when Just My Code is enabled. In this situation, non-user code is displayed rather than hidden, but stepping will still take you out of non-user code to the next line of My Code." If I understand that correctly, all I have to do is step out, and i should be back in my code, but it doesn't seem to work, im still in kernel or nt.dll...
Black Sky A Star Control 2/Elite like game
Advertisement
You may have mixed it up with "Step Over". Step over and step out are two different things. If one step out dosn't work, keep trying. You should eventually get to your own code. I'm afraid I can't help much with the /MT and /MD question as I really don't understand what it is you're asking.
______________________TradeMark Designs
My suggestion is that you find your call stack window (debug->windows I think - I am away from visual studio at the moment) in visual studio. This will give you a list of the functions called in the order they were called. Then you can (by double clicking on the line) jump down, or up to where the call was made.


This way - say if your code calls some Windows API function and you end up breaking deep in the Windows API, you can use the call stack to jump back "up" to where your code made the API call.

BTW - Step out, steps you one "step" up the call stack (ie - to where you called the current function).


HTH
Sorry, to answer your first question. When you create a Cpp program, it uses a library. There are two options with these libraries.

You can "link them in", meaning your compiler takes all the stuff and sticks it in your .exe. Which obviously makes it bigger. Or you can use a dynamic library. Meaning, dynamically at runtime - it goes looking for the stuff (now in .dll files) so it can do its basic stuff. So it doesn't make your .exe bigger, but those two .dll files need to be on your system.

Basically, the .dll approach exists, so that if properly installed (theoretically) those .dlls you would only need one copy of it on your system because it is able to dynamically find the library.

Generally this doesn't happen, and sometimes its easier to just include the .dlls in your program folder (which happens to be in the system's library search path).


HTH

This topic is closed to new replies.

Advertisement