CP is not MSDN. There topics need some explanation. The first resource to get informatio is MSDN. if it's not clear (rare chance) or something not included, that can be asked here. Most of the MSDN entries regarding Win32 and MFC contains sample snippet.
but they do often require linkage to either the static or the dynamic C/C++ runtime libs. that is, you can't use a lib built for use with the static CRT in an app built for use with the dynamic CRT - you'll get many link errors.
it's possible that's what the OP is asking about...
libs are not be classifed as static or dynamic, the dlls are classifed as static or dynamic.
That is only partially correct. *.lib files area always statically linked. That is, when you link with a lib file, the code from it becomes part of your executable (be it a dll or exe). *.dll files are always "dynamic", but they have 2 types of binding (early and late). Early binding to a Dll is when you link to it specifically (that is, include the header file and have its lib placed in the link path), the linker puts the location of the dll resource your executable is trying to access in place of copying the code for it. You can think if it kind of like a pointer to what you really want, which resides in the dll. Late binding is when you use LoadLibrary/GetProcAddress to open a dll and search for the resource you want to use. To compile an executable using early binding, you need to have access to the dll, its header files, and its lib. To compile an executable using late binding, you don't even need the dll on the machine (though, without it, your code won't run when you try to execute it).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Ah no -- you certainly don't need a .lib for both.
They're called "linking" in the MS docs. Early linking means you use a lib and your linker inserts thunks that are later fixed up either on exe start when the run time loads the dll or on first function call if you used a delay-load pragma.
Late linking, or a dynamically linked dll, you have no lib and not necessarily any .h file (though the latter helps, because you need to know the function signatures). You can simply call LoadLibrary then GetProcAddress with a function name to get a function pointer and that's it. There is no type checking on the function pointer so you better know the signature (here's where a h file is handy) but no h file is required.
I assume what you mean is: "by looking at a lib file, can I determine if the executables (or DLL's) that link with it will contain the code that the lib is representing, or will the executable need to load the code from an external DLL?".
You link to a lib file to be able to use code that you are not providing. For example, the "fopen" function needs the "libc.lib" library (or equivalent) to provide you with the code necessary to open a file. You will not provide this code, the "libc.lib" will. Let's call this the "additional code".
However, the way the lib provides the additional code to you can be in 2 diferent ways:
1) It can contain the additional code itself (the set of additional machine instructions that do the actual job that you are needing). In this example, the additional "fopen" code would be contained in the lib, accessing the disk, locking the directory, marking the file as open, etc...
2) It can request the OS to load a DLL from disk and get the additional code from it. In this situation, the lib loads the DLL from disk (usually when the executable loads into memory and before it begins to run) finds the address of the "fopen" function code within it, and provides you with a link to acess this additional code present in the DLL. So, when you call "fopen" you are accessing the lib's "fopen", which is a stub that just links to the location in the DLL where the actual "fopen" code resides and executes it for you.
So, the best indicator that a lib contains the code or not is the size. Small libs (50kb or so) typically contain only names of functions to link to the DLL. Larger libs (500kb or more) usually contain the code itself, and do not rely on external DLL's. These values, of course, are just general guidelines.
The most acurate way I now is for you to produce your executable and then use the dependency walker to determine if it depends on external new DLL's ("new" means "the exe did not need them until I linked with the libs").
Also note that the linker is very smart. If you are not using code from a lib then just linking with it does not mean a DLL will be needed, since the linker will find that out and end up not using its code. To be sure you use it call some of its functions in your program.
I need to get the width and height of the monitor.
i tried with GetWindowRect, I am able to get the width( .right) correctly but when it comes to height, the .bottom shows an integer which will be just more than half of the screen.
I am working in C++ and I need to run an executable , "Process#1", within the context of another executable, "Process#2". Process#1 is bound to throw exceptions and Process#2 must be able to handle the exceptions thrown by process#1. I am unable to handle using createprocess() or ShellExecute(). Please let me know if there is a way to accomplish this.
There is no easy way of doing this apart from Process#1 catching the exception and telling Process#2 what happened using some form of interprocess communication, you cannot throw exceptions across process boundaries which is a good thing.
This is an unusual scenario and, without knowing exactly what you’re up to, I feel safe saying it is probably a bad design decision. That said it is possible. When you use the CreateProcess API you can pass the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS flags (the second is probably what you’re after) in the ‘dwCreationFlags’ parameter. This flag is used by debuggers, as you probably guessed by the name, and results in exceptions thrown in the child process being reported to the parent. The information is passed to the parent process via the WaitForDebugEvent API. There is more to it that that obviously and, as I said, I don’t recommend using this technique. If you don't know exactly what you're doing you'll make a mess. Also throwing an exception becomes much more expensive for the child as it now results in a context switch to the parent and back to the child again. The child my also behave slight differently in some aspects; for example the ghost window[^] feature will not work in the process being debugged (the child). That said there are protection schemes, such as Armadillo, which use this technique and the software which uses it seems to work ok and when a developer is making an app it works in the debugger. Also note that as a process can only have one debugger attached to it you will probably not be able to use your debugger on it and even debuggers which can work under these conditions (such as WinDBG) will not be as powerful under this environment.
Steve, thank you for all that information. I wish to putforth a little more information that I need.
The child process handles most of the known exceptions, however, the parent process should handle the rest of the exceptions thats not handled by the child process itself. Exception handling by the parent process is a major part of the app that I need to develop.
Last Visit: 31-Dec-99 18:00 Last Update: 24-Sep-23 15:15