I can only get the Caption name of another app by using GetForegroundWindow and GetWindowTextA. But how do you get the full path name if this is all you got to go on. GetWindow don't work for me and i am trying not to use EnumWindow.
If it is not possible the by a standard way do someone know of a link where i can see how it is done PE style that works for 9x and up.

This is one of the many things i tried to do but nothing works.


invoke GetDesktopWindow ;;;GetForegroundWindow

; ............................... GetClassName
PUSH 128
PUSH offset Buffer
PUSH eax
PUSH GetClassNameA
; ............................... FindClass
PUSH 0
PUSH offset Buffer
CALL FindWindowA
mov temp, eax
; ............................... GetWindowText
PUSH 128
PUSH offset b_PATH
PUSH temp
CALL GetWindowTextA
; ............................... GETTEXTLENGTH tried also
;PUSH offset b_PATH
;PUSH WM_GETTEXTLENGTH
;PUSH WM_GETTEXT
;PUSH eax
;CALL SendMessageA


PS: Do Process32Next work for all 9x and up
Posted on 2003-07-30 01:44:04 by cmax
Yes, Process32Next works with all 32 bit versions of Windows (Except NT4), it is part of the ToolHelp API.
Posted on 2003-07-30 02:25:40 by donkey
OK,

thanks a lot donkey
Posted on 2003-07-30 03:53:14 by cmax
I already post this but under a different thread but when someone find this one it is where it shoud be.


I got the Process ID with this old code... seem simple but hard to find :)

aProcess DWORD ?

invoke GetForegroundWindow

push offset aProcess
push eax
call GetWindowThreadProcessId

It returns the scrible scrabble Thread ID for that window.

Do anyone know where i go from here to get the full path name
Posted on 2003-07-30 05:17:39 by cmax
How about GetModuleFileName?
Posted on 2003-07-30 11:14:25 by QvasiModo
oh a I see, you want to get the full path.
I do that like this, just change the classname



.386
.model flat, stdcall
option casemap:none

include WINDOWS.INC
include kernel32.inc
include user32.inc
include psapi.inc

includelib kernel32.lib
includelib user32.lib
includelib psapi.lib


.data
szMSNClass db "MSNMSBLClass", 0

.data?
szBuffer db 256 dup (?)
ProcessId dd ?
hProcess dd ?
hModule dd ?
numModules dd ?

.code
Start:
invoke FindWindow, offset szMSNClass, 0
invoke GetWindowThreadProcessId, eax, offset ProcessId
invoke OpenProcess, PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, 0, ProcessId
mov hProcess, eax
invoke EnumProcessModules, hProcess, offset hModule, sizeof hModule, offset numModules
.if eax != 0
invoke GetModuleFileNameEx, hProcess, hModule, offset szBuffer, sizeof szBuffer
invoke MessageBox, 0, offset szBuffer, offset szBuffer, 0
.endif
invoke CloseHandle, hProcess
invoke ExitProcess, 0
end Start
Posted on 2003-07-30 14:52:07 by Jnrz
The code at the beginning should work for SOMETHING. Here is a example that is SUPPOSE to get Class Name. Remember i don't know the class name of the top-level window.

I thought the only way to get the handle of un-known window was to use GetForegroundWindow or GetDesktopWindow. There must be something else or it don't work as stated in API help.

Anyway as you see it returns nothing but the handle.

I never get the chance to use FindWindow...

If i did, with your code above or maybe even some of my at the top IT would BE ALL OVER....Maybe my code is wrong but i douth it.

int GetClassName(

HWND hWnd, // handle of window
LPTSTR lpClassName, // address of buffer for class name
int nMaxCount // size of buffer, in characters


;.......................................................... Stranges
;..........................................................
; IT RETURN A HANDLE...

; BUT NOT CLASS NAME ...
;..........................................................

.386
.MODEL FLAT,STDCALL
option casemap:none

include \MASM32\INCLUDE\windows.inc
include \MASM32\INCLUDE\user32.inc
include \MASM32\INCLUDE\kernel32.inc

includelib \MASM32\LIB\user32.lib
includelib \MASM32\LIB\kernel32.lib


.DATA

;s_Where_CLASS db "Don't know Class Name",0

.data?

aHandle DWORD ?

aClassName BYTE 128 dup(?)

.CODE
start:

invoke GetForegroundWindow ; or GetDesktopWindow
mov aHandle, eax

PUSH 128
PUSH offset aClassName
PUSH aHandle
PUSH GetClassNameA


invoke MessageBoxA, 0, offset aHandle, 0, 0

invoke MessageBoxA, 0, offset aClassName, 0, 0


invoke ExitProcess, 0




end start
-------------------------
Posted on 2003-07-30 17:20:15 by cmax

PUSH 128
PUSH offset aClassName
PUSH aHandle
PUSH GetClassNameA


Should be


PUSH 128
PUSH offset aClassName
PUSH aHandle
CALL GetClassNameA


It works, btw.

RobotBob
Posted on 2003-07-30 17:28:37 by RobotBob
Originally posted by cmax
.data?
aHandle DWORD ?
aClassName BYTE 128 dup(?)

(...)
invoke MessageBoxA, 0, offset aHandle, 0, 0

I don't understand... why are you passing a DWORD number to MessageBox, where it expects a pointer to a string?

Besides, this should work:


invoke GetDesktopWindow
invoke GetClassName,eax,offset aClassName,sizeof aClassName
invoke MessageBox,0,offset aClassName,offset aClassName,MB_OK
Posted on 2003-07-30 17:31:31 by QvasiModo

IT RETURN A HANDLE... BUT NOT CLASS NAME ...


Are you getting something like this?

#123

That's not a handle... it's an atom. That is, a WORD number associated with a string. Class names work this way. Since you can also use a string beginning with a numeral sign, and the ASCII decimal representation of the atom value, instead of a different string, sometimes GetClassName will return the atom value converted to ASCII decimal string with a # prepended.
Posted on 2003-07-30 17:41:31 by QvasiModo
I been pushing a call for 3 days now.

SORRY...

So now i can get the full path even with my code at top as usual since i now GetClassName. How Blind can i be.

Jnrz, do EnumProcessModules work for 9x also. It's not in my API help file for even for NT?

QvasiModo, I get a real handle but as RobotBob pointed out i was pushing a call.

btw QvasiModo, since i saw it i plan to use it. I have been laying your code out in a readable format.. ( at lease this is what i do so i can understand things better ) I'm not finshed but i plan to correct your spelling and lay it out. I seen it all to you when i am finshed in a few day if you want it. I do this for all code that i use in my program just to remember.

Great work. It really teaches us about dlls even as we go. (I use WordPerfet for spelling not my brains.. )

Anyway case close ... my bad
Posted on 2003-07-30 19:06:14 by cmax
I think that GetModuleFileName is the way to go but this code only give the executionable own full FileName. I am trying to get the ForegroundWindow FileName . Getting my window out the way is not the problem because i ise SW_HIDE in a timer funtion and everything else that i was trying to do here now works
(GetClassName) and others but not this one.

I think i am making the wrong call at

"invoke GetModuleHandle, eax ;;;NULL" or it don't work with a plain handle.



;..........................................................

.386
.MODEL FLAT,STDCALL
option casemap:none

include \MASM32\INCLUDE\windows.inc
include \MASM32\INCLUDE\user32.inc
include \MASM32\INCLUDE\kernel32.inc

includelib \MASM32\LIB\user32.lib
includelib \MASM32\LIB\kernel32.lib

.data?

aHandle DWORD ?

FileName BYTE 128 dup(?)

.CODE
start:


invoke GetForegroundWindow


invoke GetModuleHandle, eax ;;;NULL

invoke GetModuleFileName, eax, addr FileName, sizeof FileName

invoke MessageBoxA, 0, offset FileName, 0, 0


invoke ExitProcess, 0




end start
-------------------------

it returns my own file name . I'm hope this don't piece of code s not a forground window.
Posted on 2003-07-30 23:08:47 by cmax
Its returning its own filename because GetModuleHandle is failing.
if the first param to GetModuleFileName is NULL, it assumes you mean it own module.

"If this parameter is NULL, GetModuleFileName returns the path for the file used to create the calling process. "

HMODULE GetModuleHandle(
LPCTSTR lpModuleName // address of module name to return handle for
);

Is looking for a 'string' and not the window handle returned by: GetForegroundWindow.

I'll look through it and see If I can generate the result you desire.

RobotBob
Posted on 2003-07-30 23:19:33 by RobotBob
One thing for sure GetModuleFileName would have been the best way because it works for all windows. That was where i accually started but i did not want to keep it in a dll, so i went gun-ho for vxd and kmd's to figure out why it did not work and make it work in an executionable.

Now i see why. A dll is not a real PE or don't have a MZ. Now that i know it looks for a string, it looks for itself regardless before the code ends. So SW_HIDE means nothing.

I think this one is a losing battle. So don't go any more out your way unless you know you can get around that. I hope you can but if not Thanks anyway Robot.

At lease their's enough info here to get things working the long way around with no driver need. ( But i am going to write one anyway some day soon )

"Process32Next works with all 32 bit versions of Windows (Except NT4)" and "EnumProcessModules" may take care of NT to boot. Thanks to donkey and Jnrz replies.

It's the only block of code that i may have to write for each OS. I been very lucky up until now.

I was telling this chick i know what i was trying to do and how hard it was to do it.

She said you want your cake and eat it too.

Where do females come up with these lines and keep them for thousands of years...

I asked her, what else is a cake good for.

She return no reply. hee hee ...

but i bet she use that line again.

Thanks everybody
Posted on 2003-07-31 01:58:33 by cmax
"Now i see why. A dll is not a real PE or don't have a MZ."

Not true, a dll is a PE.

Here is what the api needs for the intial call to GetModuleHandle:

lpModuleName

Points to a null-terminated string that names a Win32 module (either a .DLL or .EXE file). If the filename extension is omitted, the default library extension .DLL is appended. The filename string can include a trailing point character (.) to indicate that the module name has no extension. The string does not have to specify a path. The name is compared (case independently) to the names of modules currently mapped into the address space of the calling process.


There is always a method, never a losing battle.
I am not sure what your goal is? So are you trying to get the fullpath of a foreground window? and that it?
If I can fully understand what you need, then I can help you find the solution. Remember there is always a
solution. Is this for the hooking lib?

Never give up.

RobotBob
Posted on 2003-07-31 02:19:31 by RobotBob
I have a small window that will open up at the bottom of the user screen. It is TOP_MOST so it will not be in the way that much. When another app open it will hide itself. When the app close it will re-appear.

OK, When it hides itself it need to get the full pathname, time opend, time closed and other stuff of whatever program is running or in use. (now it's no suprise) :( Anything else is easy is guest... But i want to do it my way.

So since i am not useing a dll for this one i need to do it all in the app.

OK, this thread have proven though coding that i can get all of that other information such as WindowText, ClassName or anything else but the full path.

If i don't hide my window i get nothing but my own information about my window.

The Full Path is the last thing i need to get and i can't find a way to get it. If i get the right code it will work for all Windows not one for 9x and one for NT and one for XP etc.

This is the added hell i get. so GetModuleFileName seem to be the best way to go but it keeps returning information on my window not the other window as it should just like when i get classname.

I hope i you understand what i am saying,

It works for every call but GetModuleFileName ...

If i got to code for all OS i will

Anything it takes to get the FileName and it full path i be HAPPY...
but GetModuleFileName use less API to get the job done

PS: I am trying to deal with the app that the user is using, not all opened windows only the top level one that's why my gets out the way and has good reasons of doing so to boot... I hate to tell what i am doing until i did it. But anything for ________

Thanks
Posted on 2003-07-31 04:00:52 by cmax
GetModuleFileName will not retrieve the filename of a module in another process. The only way you can do this is to enumerate all the processes and find the one that you're looking for, you can then extract the module file name using GetModuleFileNameEx using the process handle or use a Module Snapshot to get it.
SearchForProcess proc

LOCAL pe32 :PROCESSENTRY32
LOCAL me32 :MODULEENTRY32
LOCAL hProcessSnap :HANDLE
LOCAL hModuleSnap :HANDLE

mov pe32.dwSize,SIZEOF PROCESSENTRY32
mov me32.dwSize,SIZEOF MODULEENTRY32

invoke CreateToolhelp32Snapshot,TH32CS_SNAPPROCESS,0
.IF eax == -1
ret
.ENDIF
mov hProcessSnap,eax
invoke Process32First,hProcessSnap,ADDR pe32
.IF eax==0
ret
.ENDIF

.WHILE eax
invoke SetLastError,0
invoke CreateToolhelp32Snapshot,TH32CS_SNAPMODULE,pe32.th32ProcessID
mov hModuleSnap,eax
invoke Module32First,hModuleSnap,ADDR me32
invoke CloseHandle,hModuleSnap

; [b]Module filename is in me32.szExePath[/b]

invoke Process32Next,hProcessSnap,ADDR pe32
.ENDW
invoke CloseHandle,hProcessSnap

ret
SearchForProcess endp
You will have to find a way to pick out your target process
Posted on 2003-07-31 04:23:41 by donkey
Yell, I really thought so. I spend more time trying every way possible receiving the same results.

So i was looking at Jnrz code for NT and had just set it up in my app while reading API as i went.

Than i was going to find this code for all else because i seen it in a post while searching. That's why I PS: "Do Process32Next work for all 9x and up"..... Ii was looking dead at it or something just like it posted by you.

So i was prepared to find it again...

Robot, you and i are kind of alike. It's hard to give up. Nine out of ten we usually find away even with the so-called impossible. But you the kind of guy that can and will beats the odds. It's a gift. I got a feeling.

Istine said something like this " Insanity is when you do the same thing over and over again only getting the same results"

I'm talking days here and Pushing Calls to boot...

But i learned a lot of new stuff behind it all and will never forget it.

Thanks again

PS: I had to tell about what i am doing. You're are not the only one who get confuss by what i say. Just read above or in my previous thread, for that matter up to two years ago. :)
Posted on 2003-07-31 06:25:10 by cmax
Process32Next works for all 9x, 2K and XP, it does not work for NT4, you have to use the psapi for that.
Posted on 2003-07-31 06:30:24 by donkey
(1)
Let me get this straight. Jnrz code use the psapi.inc so it's NT READY right. If so the two together is more than what one can ask for.

(2)
Can make the psapi.dll work for 9x if i steal some needed stuff out of NT XP. (This one just a thought)

(3)
I see the psapi.dll in a lot of examples. This is for NT only or all NT types.

I don't have NT or NT types but i am setting things up now but test it when i get it.

Done

Thanks
Posted on 2003-07-31 06:54:09 by cmax