"Nerijus Baliunas" <nerijus(a)users.sourceforge.net> writes:
> why the following patch is not applied?
I don't think it was ever submitted; but anyway, it's quite ugly to
check the callouts on every module load/unload. The right fix is to
get rid of the Callout structure and do a GetProcAddress at the time
we need a specific function.
--
Alexandre Julliard
julliard(a)winehq.com
Hi all,
can't we just free the libraries for real now in FreeLibrary() ?
I just got a report from someone who had an InstallSh***** installer
say this:
Call kernel32.192: CreateFileA(40566cf4 "C:\\WINDOWS\\uninst.exe",c0000000,00000001,00000000,00000004,00000080,00000000) ret=0044364e fs=008f
trace:file:CreateFileA C:\WINDOWS\uninst.exe GENERIC_READ GENERIC_WRITE FILE_SHARE_READ OPEN_ALWAYS
trace:dosfs:DOSFS_GetFullName C:\WINDOWS\uninst.exe (last=0)
trace:string:lstrcpynA (0x40566148, "/home/jnu/.wine/fake_windows", 1024)
trace:dosfs:DOSFS_FindUnixName /home/jnu/.wine/fake_windows,WINDOWS\uninst.exe
trace:dosfs:DOSFS_FindUnixName (/home/jnu/.wine/fake_windows,WINDOWS\uninst.exe) -> Windows (WINDOWS)
trace:dosfs:DOSFS_FindUnixName /home/jnu/.wine/fake_windows/Windows,uninst.exe
warn:dosfs:DOSFS_FindUnixName 'uninst.exe' not found in '/home/jnu/.wine/fake_windows/Windows'
trace:dosfs:DOSFS_GetFullName returning /home/jnu/.wine/fake_windows/Windows/uninst.exe = C:\WINDOWS\uninst.exe
warn:file:FILE_CreateFile Unable to create file '/home/jnu/.wine/fake_windows/Windows/uninst.exe' (GLE 32)
Ret kernel32.192: CreateFileA() retval=ffffffff ret=0044364e fs=008f
.
.
.
Call kernel32.943: lstrcpyA(40566834,40380370 "Setup Initialization Error") ret=00403322 fs=008f
Ret kernel32.943: lstrcpyA() retval=40566834 ret=00403322 fs=008f
trace:string:wvsnprintfA 0x40566960 1024 "Setup is unable to find a hard disk location to store temporary files.\n\nMake at "...
trace:string:wvsnprintfA "Setup is unable to find a hard disk location to store
temporary files.\n\nMake at "...
Call user32.425: MessageBoxA(00000000,40566960 "Setup is unable to find a hard disk location to store temporary files.\n\nMake at "...,40566834 "Setup Initialization Error",00000010) ret=00403402 fs=008f
This happened because the program did some FileVersionGet*() calls before
on uninst.exe, which do LoadLibrary()/FreeLibrary() internally, but of
course the file handle didn't get freed any more.
I believe the potential problems that this can cause are way more important
than some claims that "there are some problems with library freeing".
I've had that FreeLibrary() #if hack removed for a long time,
and I haven't see any adverse effects (not that it's too easy to spot
and attribute to this problem probably, though).
Besides, Musicmatch Jukebox used zillions of MB (yes, that's a leak for you)
due to that Wine "feature".
I for one would truly like to see it fixed ASAP.
If FreeLibrary() has a problem, then we need to fix it.
Running away from the problem by implementing strange hacks does no good
to anybody.
Andreas Mohr
--
Microsoft Windows: Made for the Internet
The Internet: Made for Unix
Hello,
why the following patch is not applied?
-----Original Message-----
From: David.Goodenough(a)dga.co.uk [mailto:[email protected]]
Subject: RE: Notes and Java test on 20010216 drop
The Java problem I had with the last drop (the problem with Callout not
being initialised) is still there, so obviously the fix that was generated
and which fixes the problem has not made it into the CVS.
The good news is that now Java works (if the patch is applied). Now the
fonts display correctly. I am not sure what you have done guys, but it
works a treat. Now for some more testing with some of the things I wanted
to run but could not because of the Java support. Interestingly both the
Sun and the IBM JREs now work, where last month with the fix the Sun one
produced the wrong output but at least ran to completion, while the IBM one
locked up somewhere. Now both run to completion properly.
I was sent this (I think on wine-develop but it might have been directly).
It fixes the Callout problem. I forget who originally sent it to me, but I
could find out if that is necessary.
diff -ur wine-cvs/if1632/thunk.c wine-uw/if1632/thunk.c
--- wine-cvs/if1632/thunk.c Wed Jan 3 22:51:30 2001
+++ wine-uw/if1632/thunk.c Mon Jan 29 00:35:49 2001
@@ -166,7 +166,7 @@
NE_MODULE *pModule;
hModule = GetModuleHandleA( "user32.dll" );
- if ( hModule )
+ if ( hModule && !Callout.PeekMessageA )
{
#define GETADDR( name ) \
*(FARPROC *)&Callout.name = GetProcAddress( hModule, #name )
@@ -185,10 +185,24 @@
GETADDR( MessageBoxW );
#undef GETADDR
}
- else WARN("no 32-bit USER\n");
+ if ( !hModule && Callout.PeekMessageA )
+ {
+ Callout.PeekMessageA = NULL;
+ Callout.GetMessageA = NULL;
+ Callout.SendMessageA = NULL;
+ Callout.PostMessageA = NULL;
+ Callout.TranslateMessage = NULL;
+ Callout.DispatchMessageA = NULL;
+ Callout.RedrawWindow = NULL;
+ Callout.WaitForInputIdle = NULL;
+ Callout.MsgWaitForMultipleObjects = NULL;
+ Callout.WindowFromDC = NULL;
+ Callout.MessageBoxA = NULL;
+ Callout.MessageBoxW = NULL;
+ }
pModule = NE_GetPtr( GetModuleHandle16( "USER.EXE" ) );
- if ( pModule )
+ if ( pModule && !Callout.FinalUserInit16 )
{
#define GETADDR( var, name, thk ) \
*(FARPROC *)&Callout.var = THUNK_GetCalloutThunk( pModule, name, \
@@ -201,5 +215,12 @@
GETADDR( UserSignalProc, "SignalProc32", word_lllw );
#undef GETADDR
}
- else WARN("no 16-bit USER\n");
+ if ( !pModule && Callout.FinalUserInit16 )
+ {
+ Callout.FinalUserInit16 = NULL;
+ Callout.InitThreadInput16 = NULL;
+ Callout.UserYield16 = NULL;
+ Callout.DestroyIcon32 = NULL;
+ Callout.UserSignalProc = NULL;
+ }
}
diff -ur wine-cvs/loader/module.c wine-uw/loader/module.c
--- wine-cvs/loader/module.c Tue Jan 16 00:29:27 2001
+++ wine-uw/loader/module.c Mon Jan 29 00:30:20 2001
@@ -1432,6 +1432,9 @@
/* decrement the dependencies through the MODULE_FreeLibrary
call. */
pwm->refCount++;
+ /* Update the kernel Callout tables */
+ THUNK_InitCallout();
+
RtlReleasePebLock();
SetLastError( err ); /* restore last error */
HeapFree ( GetProcessHeap(), 0, filename );
@@ -1526,6 +1529,9 @@
HeapFree( GetProcessHeap(), 0, wm->short_filename );
HeapFree( GetProcessHeap(), 0, wm );
}
+
+ /* Update the kernel Callout tables */
+ THUNK_InitCallout();
}
/***********************************************************************
diff -ur wine-cvs/miscemu/main.c wine-uw/miscemu/main.c
--- wine-cvs/miscemu/main.c Wed Jan 10 02:42:49 2001
+++ wine-uw/miscemu/main.c Mon Jan 29 00:36:05 2001
@@ -34,7 +34,6 @@
MESSAGE( "Cannot load user32.dll\n" );
ExitProcess( GetLastError() );
}
- THUNK_InitCallout();
if ((instance = NE_StartMain( main_exe_name, main_exe_file )) < 32)
{
diff -ur wine-cvs/scheduler/process.c wine-uw/scheduler/process.c
--- wine-cvs/scheduler/process.c Sun Jan 28 18:58:09 2001
+++ wine-uw/scheduler/process.c Mon Jan 29 00:36:17 2001
@@ -346,9 +346,6 @@
MODULE_DllProcessAttach( NULL, (LPVOID)1 );
RtlReleasePebLock();
- /* Get pointers to USER routines called by KERNEL */
- THUNK_InitCallout();
-
/* Call FinalUserInit routine */
if (Callout.FinalUserInit16) Callout.FinalUserInit16();
> As for doing the 10k+ lines of coding myself, I have experience in
> (de)marshalling and network coding, spent many years doing it, it's more a
> matter of available time and learning the com wire protocols, neither of which
> are currently available to me. Here's to hoping someone is already working on
> it ;).
For local marshalling we could use our own protocol and even our own way of ipc if we don't try to mix processes with native and wine com-dll's. It com server is only interested in the result ;-). And isn't the com marshalling similar to the dce one?
For networking - the dcom protocoll is documented (IMHO).
juergen
After a long break, I'd like to figure out why quickbooks 5 can't print.
wineps works, ie I can print in notepad, but QB seems to implement its own
printing mechanism.
--debugmsg +psdrv,+print,+winspool
produces no output. Adding +font spits out a lot, but no errors that I
can see.
This all used to work until wineps was moved from graphics to a dll about
a year ago.
I can see from +dosfs that it's accessing some files (WPR.DAT/WPR.INI)
which contain information on printers. There is also a QBWPR.DLL file
that gets loaded.
Any hints on where to start would be appreciated.
Thanks,
Sean
--
Sean A. Walberg <sean(a)ertw.com> http://www.ertw.com *updated!*
Join the weekly brainbuzz.com Linux newsletter for news and resources!
Send a blank email to: join-linuxnews(a)list.brainbuzz.com
At 09:44 AM 28/04/2001 -0500, you wrote:
>Okay, here are the traces. Here
>(ftp://sourceharvest.com/pub/wine_qb4.log.gz) is the QB4 trace. QB4
>printing works.
>
>The other (ftp://sourceharvest.com/pub/wine_qb5.log.gz) is the QB5 trace.
>QB5 printing doesn't work.
The 2 traces are showing the same problem : the 2 versions of your app
are trying to loadlibrary on the Wineps driver. This is not working
in both cases.
The difference comes from the app itself : QB4 is proceding anyway to
a call to CreateDC (that's the usual way of printing after all) and this
call succeeds - because Wine has been coded for this case- , while QB5
don't want to continue.
My impression is that QB5 is a more sophisticate application that is actually
*testing* the errors returned by the system.
Unfortunately, that is also breaking its capability of printing
under Wine.
I am not sure why this LoadLibrary fails (it returns 2, file not found).
I have done a quick and dirty LoadLibrary("WINEPS.DRV") in a
winelib application : it fails. LoadLibrary("WINEPS.DLL") succeeds.
So this is the problem it seems. LoadLibrary should be tweaked.
I think that the code to patch is in library/loader.c, line 96
/* check for .dll or .exe extension to remove */
if (ext && (!strcmp( ext, ".dll" ) || !strcmp( ext, ".exe" ))) p = ext
After the name problem is solved, the following problem is probably
loading a 32 bits builtin library from 16 bits code. I don't remember
clearly now (it's past 2 am for me) but the problem has already occured
for other dlls.
I think it was you who asked about the difference between 16 and 32
bits code; while you got a correct answer, there is also a first glance
trick, useful when in one application you have transitions between
16 and 32 bits code : the 16 bits calls to the Api are shown in uppercase,
the 32 bits are in lowercase.
Gerard
