TPU ChatChat on IRC
Internet Relay Chat?
Java Applet client
Who's on IRC?
SetWindowsLong API call
Posted by eXorcus [send private reply] at July 05, 2002, 07:56:21 AM Hey guys,
Just wondering if any of you know anything about the SetWindowsLong function in the Windows API.
I have used this call before to subclass a window's wndProc, but in this case I'm using it to subclass a window from a different executable. When I try to do so, it gives me an error but the error code returned is 0 - No error/successful. Right now I'm thinking that maybe it isn't possible to subclass the window from a different exe file, but I couldn't find an answer anywhere on the web. My question to you then is, have any of you subclassed a window from a different EXE file and if so was it with the SetWindowsLong call?
Posted by CViper [send private reply] at July 05, 2002, 08:22:13 AM Hmm.. directly copied from the Platform SDK Docs:
Windows 95/98: The SetWindowLong function fails if the window specified by the hWnd parameter does not belong to the same process as the calling thread.
And for Win2k you can't cange the Window Proc if the hWnd dosent belong to the same process (GWL_WNDPROC)
Posted by eXorcus [send private reply] at July 05, 2002, 08:59:39 AM Ah, just as I thought. Do you know if there is a way to somehow associate a different EXE with the first EXE's process ID, maybe in a parent/child relationship or something?
Posted by CViper [send private reply] at July 06, 2002, 05:25:03 AM No idea really (never tried that).
But i think the problem is more that each process has it's own address space, eg. you can't share memory addesses between different processes (the address of the window proc in the first process dosent exist/is something else in the second).
I don't know if it's possible to load a .exe into the calling process' address space.
Posted by taubz [send private reply] at July 06, 2002, 05:52:33 PM I think EXEs must run in their own process, unless you can find out a way of loading it like a DLL (but then the EXE would have to have exported the right functions).
Posted by CViper [send private reply] at July 07, 2002, 02:32:00 PM You can load .exe's with LoadLibrary - I just don't know what happens if you do that :) (the docs say only that you can do it to load resources from the exe)
Posted by eXorcus [send private reply] at July 09, 2002, 08:31:52 AM Is it possible to load a DLL dynamically, like instead of:
DECLARE LIB "stringconstant" ...
could you do the equivalent of:
DECLARE LIB stringvariable$ ...
Posted by CViper [send private reply] at July 10, 2002, 05:47:32 AM Instead of directly (staticly) linking to a .dll trough a library (.lib), you can load it during runtime using LoadLibrary().
But if you do it that way, you have to load each function you use from that .dll manually with GetProcAddress().
Posted by eXorcus [send private reply] at July 10, 2002, 07:37:11 AM Ahh...that helps. Thanks. I'll fool around with that and see if I can get it to work.
Posted by Mike_L [send private reply] at July 13, 2002, 01:03:06 AM There are several ways to load your DLL into another program's address space. A common way (used by AOL IM) is to declare a windows keyboard hook. The address of the hook callback function must exist in a dynamically loadable file (an EXE or DLL). The DLL's DLLMain function gets called when it's loaded, so then it can do whatever it likes in the program's address space. Note that the DLL will then be loaded into *every* Win32 app that accepts a WM_KEY* message from GetMessage(). There are other kinds of hooks, and there are other ways of loading your DLL. Note that Windows Explorer is just a very basic window frame application that loads the OLE2 Explorer View DLLs and interacts with the C++ classes they create. Windows becomes unstable because many programs register their own OLE2 objects and subsequently the buggy third party DLLs get loaded into every process that uses explorer views (any program that uses common dialogs like Open/Save).
Windows is like one giant orgy. The STDs just get passed around to everyone. There are no boundaries and no condoms. It's fun for a while, but then one misses out on the support and emotional stability that is found in a more structured relationship, like marriage.
Unix : Windows :: marriage : nightly orgies
LOL that's a rather nasty analogue. I'll shut up now. =)
Posted by Bahwx [send private reply] at July 18, 2002, 11:10:13 PM Well for EXEs, they can be loaded as DLLs but the base address won't be 0x00400000 and relocation is not likely performable(or can an EXE has .reloc section? never heard of it). This means the EXE can't load at all, let alone calling an exported function from it.
Posted by buzgub [send private reply] at July 19, 2002, 01:26:13 AM If you want to dynamically load an exe file, you might like to search the mingw mailing list archives; it gets discussed every so often on the mingw-users list.
Posted by Zandalf [send private reply] at July 19, 2002, 01:32:19 AM I have the impression that loading .exe files as .dlls would get ugly in a hurry. My guess would be to be careful unless you know exactly what functions are in the .exe, and you need to use most of them.
also, do remember that if that .exe isn't being used as a .dll somewhere else, there is no benefit memory-wise to using it in such a difficult (seemingly to me) manner. I think that you would do just as well to write the functions yourself.
Posted by buzgub [send private reply] at July 19, 2002, 01:40:33 AM My understanding is that only the functions that the executable exports are available when it is dynamically loaded. I don't see that this trick has much to reccomend it either, though.
Register as a new user