CreateProcess - wine is not doing it right

[Vitaliy Margolen]

Saturday, September 10, 2005, 2:04:23 PM, Robert Shearman wrote:
> Vitaliy Margolen wrote:
>>Now I really need you help people.
>>
>>Ok, here is the problem:
>>LdrInitializeThunk is called from within start_process - the first thing to be
>>executed in the new process's context. But this is not right. All what I found
>>so far indicates, that LdrInitializeThunk should be queued as an APC, so it
>>executes first no matter what.
> That's because we run on top of other libraries and they need to be
> initialized first.
But can this be done _after_ main thread resumes? Or partially on process
creation, inside LdrInitializeThunk after thread resumes?

>>To complicate matters more, LdrInitializeThunk calling wineserver to stop the
>>process if it's created with CREATE_SUSPENDED flag set. This is wrong. New
>>process should never make it to it's main thread yet.
> Unfortunately, I don't believe there is a syscall that will allow use to
> create a process truly suspended.
It's not a major problem here. What is, is that on windows it is possible to
"inject" some code into newly created process and execute it _before_ call to
entry point. This code can do pretty much anything, as long as it handles
exceptions itself because default exception stack is not setup yet. For obvious
reasons you can't do whole lot before LdrInitializeThunk done initializing new
process. So windows queues it as an APC to the new process. This way it will be
called first when the process resumes.
What wine does, is not correct. A simple way to fix this, is to move call to
LdrInitializeThunk outside _TRY block and suspend thread not inside wineserver
but before _TRY block in start_process.

>>And even worse, none of this happens where it should be - in ntdll.
>>Functions such as NtCreateProcess and NtCreateThread are stubs. So when I'm
>>looking on-line for any information, they all refer to these ntdll functions.
> I believe these functions are too low level to be reasonably implemented
> in Wine. We defer to a threading library, which roughly corresponds to 
> the kernel32 API, whereas the ntdll API corresponds to us having to make 
> syscalls ourselves. Also, NT process objects don't map exactly to Unix 
> process objects. For example, in NT you can create a process without any 
> threads.
Yeah that's what I thought. But eventually all wineserver calls will need to go
into ntdll. I'm hopping that some day it will be possible to use native kernel32
to test how close our ntdll to native. So this is not as big of a problem ATM.

Vitaliy.