At 02:10 AM 1/20/01 +0100, you wrote:
>In fact, the only situation I could understand GetFastQueue16 to fail
>would be if the application doesn't load the USER subsystem, so that
>the callout from KERNEL will not be present. Could you provide a
>trace with +relay and +loaddll to show whether and when USER is loaded?
With the following patch, the app starts to its usual (failed) state
--- task.c.orig Mon Jan 15 22:28:37 2001
+++ task.c Sat Jan 20 16:52:00 2001
@@ -1124,6 +1124,12 @@
TEB *teb = NtCurrentTeb();
if (!teb) return 0;
+ if (!Callout.InitThreadInput16)
+ {
+ ERR("Bad init for initthreadinput!\n");
+ THUNK_InitCallout();
+ }
+
if (!teb->queue && Callout.InitThreadInput16)
Callout.InitThreadInput16( 0, THREAD_IsWin16(teb)? 4 : 5 );
I did not include the trace as it's rather large (I can mail it to you
if you want...) but what happens is clear enough : the main exe loads
implicitely KERNEL32 but not USER - USER is loaded implicitely
by a DLL loaded by LoadLibrary.
So when the kernel initialisation is done, USER is not yet loaded.
It's unusual but seems perfectly valid IMO.
What about adding a specific Wine call from User to Kernel to trigger the
initialization when USER is loaded ? (maybe there is already an
undocumented one - you are the undisputed master here :-))
Gerard
