On 4/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Thank you,> This is actually a "cross-platform" issue, between Win32 and WOW64 :-P > Could you test the attached file? XPSP2 x64 this process (PID, name): 2192, proc_info.exe parent process (PID, name): 3592, <unknown> Couldn't create Snapshot parent process by thunk (PID, name): 3592, <unknown> 2003SP1 x64 this process (PID, name): 420, proc_info.exe parent process (PID, name): 648, <unknown> Couldn't create Snapshot parent process by thunk (PID, name): 648, <unknown> mmm... I guess nothing is changed from the previous proc_info...
Guess it didn't... Third round, hope this time we get it right, expected output: *** CURRENT PROCESS *** EnumProcessModules (PID, name): 3128 proc_info.exe Module32First (PID, name): 3128 proc_info.exe GetProcessImageFileName (PID, name): 3128 \Device\HarddiskVolume5\Programming\So urces\_sandbox\proc_info.exe *** PARENT PROCESS *** EnumProcessModules (PID, name): 4084 cmd.exe Module32First (PID, name): 4084 cmd.exe GetProcessImageFileName (PID, name): 4084 \Device\HarddiskVolume2\WINDOWS\system 32\cmd.exe WinAPI documentation is too confusing about 32-bits process listing 64-bits modules or process... also there is a lot of functions that do the same from different approaches that aren't compatibles with previous version of windows. (i.e. QueryFullProcessImageName is only available in Vista and Windows Server "Longhorn")... Maybe I could code some dynamic loading (like psapi in proc_info) to workaround this case scenario. Please let me know the results. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
proc_info_3.7z
Description: Binary data
_______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
