Re: Question about contents of STARTUPINFO structure and non WinMain entry points
you likely have to fix dlls/ntdll/thread.c (in thread_init) so that the RTL_USER_PROCESS_PARAMETERS has the correct flag set (or alternatively, in dlls/kernel/process.c, in for example build_initial_environment) Note that winecrt0 is only used for winelib apps, so it's not used in case of windows native pgm A+
Message du 08/11/05 07:11 De : "James Liggett" A : "Wine Mailing List" Copie à : Objet : Question about contents of STARTUPINFO structure and non WinMain entry points
Hi, First, apologies for the length. It's quite a complex issue:
A few days ago someone sent to the list asking why a program he'd written on WinXP runs under WineDbg but not under plain wine. Over the weekend I debugged the program and found out that his program doesn't use the standard WinMain entrypoint function. As such, he was using GetStartupInfo to get startup flags. He uses the wShowWindow flag to control the showing of the program's main window. Trouble is, this value is zero unless the program is started as a child process using CreateProcess, given a STARTUPINFO with wShowWindow set to something other than 0 (usually SW_SHOWNORMAL or SW_SHOW.) So my question is, how does the information in STARTUPINFO get set initially? I looked through the code for winecrt0 and found that before WinMain is called, the wShowWindow flag is set to SW_SHOWNORMAL. But because this program does not use WinMain, this value doesn't get set. However, the program works fine on native Windows XP. I looked at ntdll and kernel32 dll code, but I'm not sure I'm looking in the right place. Can someone give me some hints as to how to attack this problem?
Thanks a lot, James
On Tue, 2005-11-08 at 09:43 +0100, Eric POUECH wrote:
you likely have to fix dlls/ntdll/thread.c (in thread_init) so that the RTL_USER_PROCESS_PARAMETERS has the correct flag set (or alternatively, in dlls/kernel/process.c, in for example build_initial_environment) I tried modifying the RTL_USER_PROCESS_PARAMATERS settings after creation in dlls/ntdll/thread.c (in thread_init, right after the structure is allocated,) but that didn't work. So I put the change in dlls/kernel/process.c, at the end of build_initial_environment, and that worked. But it seems a little out of place there. Do you think such a change stands a chance of getting into CVS?
Note that winecrt0 is only used for winelib apps, so it's not used in case of windows native pgm Thanks for clearing that one up for me.
Thanks for you help. :) James
I tried modifying the RTL_USER_PROCESS_PARAMATERS settings after creation in dlls/ntdll/thread.c (in thread_init, right after the structure is allocated,) but that didn't work. So I put the change in dlls/kernel/process.c, at the end of build_initial_environment, and that worked. But it seems a little out of place there. Do you think such a change stands a chance of getting into CVS?
does the attached patch work ? (warning: lines may be wrapped) diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c index cb07fe9..caa3f5a 100644 --- a/dlls/ntdll/thread.c +++ b/dlls/ntdll/thread.c @@ -122,6 +122,7 @@ void thread_init(void) peb.LdrData = &ldr; params.CurrentDirectory.DosPath.Buffer = current_dir; params.CurrentDirectory.DosPath.MaximumLength = sizeof(current_dir); + params.wShowWindow = 1; /* SW_SHOWNORMAL */ RtlInitializeBitMap( &tls_bitmap, peb.TlsBitmapBits, sizeof(peb.TlsBitmapBits) * 8 ); RtlInitializeBitMap( &tls_expansion_bitmap, peb.TlsExpansionBitmapBits, sizeof(peb.TlsExpansionBitmapBits) * 8 ); -- Eric Pouech
Yeah, it works. :) Thanks! James On Fri, 2005-11-11 at 21:17 +0100, Eric Pouech wrote:
I tried modifying the RTL_USER_PROCESS_PARAMATERS settings after creation in dlls/ntdll/thread.c (in thread_init, right after the structure is allocated,) but that didn't work. So I put the change in dlls/kernel/process.c, at the end of build_initial_environment, and that worked. But it seems a little out of place there. Do you think such a change stands a chance of getting into CVS?
does the attached patch work ? (warning: lines may be wrapped) diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c index cb07fe9..caa3f5a 100644 --- a/dlls/ntdll/thread.c +++ b/dlls/ntdll/thread.c @@ -122,6 +122,7 @@ void thread_init(void) peb.LdrData = &ldr; params.CurrentDirectory.DosPath.Buffer = current_dir; params.CurrentDirectory.DosPath.MaximumLength = sizeof(current_dir); + params.wShowWindow = 1; /* SW_SHOWNORMAL */ RtlInitializeBitMap( &tls_bitmap, peb.TlsBitmapBits, sizeof(peb.TlsBitmapBits) * 8 ); RtlInitializeBitMap( &tls_expansion_bitmap, peb.TlsExpansionBitmapBits, sizeof(peb.TlsExpansionBitmapBits) * 8 );
On 11/11/05, James Liggett <jrliggett(a)cox.net> wrote:
Yeah, it works. :) Thanks!
James
On Fri, 2005-11-11 at 21:17 +0100, Eric Pouech wrote:
I tried modifying the RTL_USER_PROCESS_PARAMATERS settings after creation in dlls/ntdll/thread.c (in thread_init, right after the structure is allocated,) but that didn't work. So I put the change in dlls/kernel/process.c, at the end of build_initial_environment, and that worked. But it seems a little out of place there. Do you think such a change stands a chance of getting into CVS?
does the attached patch work ? (warning: lines may be wrapped) diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c index cb07fe9..caa3f5a 100644 --- a/dlls/ntdll/thread.c +++ b/dlls/ntdll/thread.c @@ -122,6 +122,7 @@ void thread_init(void) peb.LdrData = &ldr; params.CurrentDirectory.DosPath.Buffer = current_dir; params.CurrentDirectory.DosPath.MaximumLength = sizeof(current_dir); + params.wShowWindow = 1; /* SW_SHOWNORMAL */ RtlInitializeBitMap( &tls_bitmap, peb.TlsBitmapBits, sizeof(peb.TlsBitmapBits) * 8 ); RtlInitializeBitMap( &tls_expansion_bitmap, peb.TlsExpansionBitmapBits, sizeof(peb.TlsExpansionBitmapBits) * 8 );
Yeah, that works for me too, thanks!
participants (3)
-
Eric POUECH -
James Liggett -
Matheus Izvekov