C / C++ / MFC

Re: IPC (Inter Process Comunication)

13-Jul-06 0:01

sockets (almost) every time, DCOM is not very fast (obviously DCOM can use sockets as it's transmission layer)

but like anything else, it depends on the implementaion, a badly written sockets layer could run slower than DCOM

Darka [Xanya]

earl13-Jul-06 7:50

earl

13-Jul-06 7:50

sockets make you write most of the protocol stack yourself, giving you more chances to screw it up. With a good implementation they can be faster.

earl

Difference between Static lib and Dynamic lib

NiceNaidu12-Jul-06 23:22

NiceNaidu

12-Jul-06 23:22

Hi friends,

Given a lib file, Is there any way to identify whether the lib is Static or Dynamic one ??

Thanks in advance.

Appu..
"If you judge people, you have no time to love them."

Prakash Nadar13-Jul-06 0:58

Prakash Nadar

13-Jul-06 0:58

libs are not be classifed as static or dynamic, the dlls are classifed as static or dynamic.

a dll can be used dynamically as well as statically, it depends on how the host exe file has been compiled and linked.

if you use depends.exe to view the dependency of the host exe file and if you see the dll under question in the dependency list then it means that that dll was statically linked to the host exe file.

And if you dont see it then the dll is dynamically used.

ofcource you should be sure that the host exe file is using the dll in the first place.

-Prakash

C^hris L^osinger13-Jul-06 3:29

C^hris L^osinger

13-Jul-06 3:29

Mr.Prakash wrote:
libs are not be classifed as static or dynamic

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...

Cleek | Image Toolkits | Thumbnail maker

Prakash Nadar14-Jul-06 4:48

Prakash Nadar

14-Jul-06 4:48

to clarify, when i said libs i was refering to .lib files.
.lib files are always linked to get either .exe file or .dll file or any other type of executable binary ouput.

-Prakash

Zac Howland13-Jul-06 4:11

Zac Howland

13-Jul-06 4:11

Mr.Prakash wrote:
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

Zac

Prakash Nadar14-Jul-06 4:53

Prakash Nadar

14-Jul-06 4:53

Zac Howland wrote:
but they have 2 types of binding (early and late)

you are confused, both late and early "binding" (as you call it) needs both .lib and .h file to get the necessary binary.

Early binding means the OS loads the dll whenever the host exe is loaded. while late binding is that the os loads the dll when it is required to be loaded i.e some method call in that dll.

actually its not called binding, there is something better word for that, cant remember what it is Smile | :)

what you are saying is statically linked dll, and dynamically linked dll.

-Prakash

earl14-Jul-06 5:03

earl

14-Jul-06 5:03

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.
See: MSDN[^]

earl

get the desktop(monitor) width and height using win32

Rilhas17-Jul-06 13:16

Rilhas

17-Jul-06 13:16

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 hope this helps,
Rilhas

kk_mfc12-Jul-06 23:19

kk_mfc

12-Jul-06 23:19

Hi,

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.

some one please suggest me.

thanks,

kk_mfc

Re: get the desktop(monitor) width and height using win32

Jonathan [Darka]12-Jul-06 23:23

Re: get the desktop(monitor) width and height using win32

12-Jul-06 23:23

I guess you REALLY need this as you have posted it 3 times.

Darka [Xanya]

Jonathan [Darka]12-Jul-06 23:29

Re: get the desktop(monitor) width and height using win32

12-Jul-06 23:29

try this,

RECT rcWorkspace;
SystemParametersInfo(SPI_GETWORKAREA,0,(LPVOID) &rcWorkspace,0);

regards,

Darka [Xanya]

Naveen12-Jul-06 23:24

Naveen

12-Jul-06 23:24

Either take the window rect of desktop window or use

GetSystemMetrics() funtion with the following parameters

SM_CXSCREEN - for width
SM_CYSCREEN - for height

nave

Re: get the desktop(monitor) width and height using win32

NiceNaidu12-Jul-06 23:26

NiceNaidu

12-Jul-06 23:26

Use GetMonitorInfo()

Appu..
"If you judge people, you have no time to love them."

Re: get the desktop(monitor) width and height using win32

Hamid_RT13-Jul-06 0:08

Hamid_RT

13-Jul-06 0:08

GetSystemMetrics retrieves width and height (in pixels) use this function with SM_CXSCREEN and

SM_CXSCREEN<code><br />
and see <code>ScreenToClient

maybe it is some helpful to you

whitesky

Re: get the desktop(monitor) width and height using win32

kk_mfc13-Jul-06 0:31

kk_mfc

13-Jul-06 0:31

Thanks to all.
Smile | :)

kk_mfc

Catching Exceptions thrown by a process

Pavan Rao12-Jul-06 22:54

Pavan Rao

12-Jul-06 22:54

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.

Cheers
Pavan

Jonathan [Darka]12-Jul-06 23:04

12-Jul-06 23:04

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.

Darka [Xanya]

Stephen Hewitt13-Jul-06 1:20

Stephen Hewitt

13-Jul-06 1:20

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

Pavan Rao13-Jul-06 18:57

Pavan Rao

13-Jul-06 18:57

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.