LoadLibraryEx32W16("KERNEL32")
I've got a 16-bit application here that is calling
LoadLibraryEx32W16("KERNEL32"). Its the installer for Mod4Win (official
homepage at http://www.mod4win.com/ is down, but its available from
ftp://ftp.cdrom.com/.1/imm/soft/m4w24ins.exe).
This call subsequently causes a crash within Wine. LoadLibraryEx32W16()
calls DIR_SearchPath() to convert "KERNEL32" into
"C:\\WINDOWS\\SYSTEM\\KERNEL32.DLL" (I've got Wine pointing at an
existing Win95OSR2 installation). Then we call LoadLibraryExA(), which
calls MODULE_FindModule(). However, this fails as the ModRef entry has
just "KERNEL32.dll" for modname, filename, short_modname, and
short_filename in the corresponding entry. We then dutifully go on to
BUILTIN32_LoadLibraryExA(), which strips off the "C:\\WINDOWS\\SYSTEM\\"
portion, finds the entry in builtin_dlls, and calls
BUILTIN32_DoLoadImage(). This crashes upon trying to call
fixup_rva_ptrs() to adjust the exports (because its already been
done??).
So, should the ModRef entry have "C:\\WINDOWS\\SYSTEM\\KERNEL32.DLL" as
the filename? If so, how is this to be accomplished? Simply prepending
the name of the system directory when allocating the ModRef for builtin
libraries might work here, but doesn't seem right. Using a SearchPath()
call to try to find the native .DLL that corresponds to the builtin one
won't work for people with Windows-free installations (unless we do
something like make fake .DLLs as part of tools/wineinstall).
Or should MODULE_FindModule() strip off the path before comparison? It
used to do this, but no longer. I assume that the new behavior is how
Windows behaves (ie, when loading two .DLLs with the same name, but from
different paths).
Or is BUILTIN32_LoadLibraryExA() supposed to work properly when called
for a library that's already been loaded? The wm->modref++ at the
bottom would seem to imply that this is the case, which would mean that
its broken.
Advice is appreciated.
--
James Abbatiello
Re: IsSingleWindow(): SYSLEVEL_CheckNotLevel
Hi again, I think we'll need to suspend window locks *always* when calling any USER_Driver function. I had to fix up several places where USER_Driver functions were called. Can we construct some kind of wnd lock suspend/resume wrapper around the USER_Driver functions in case x11drv is used ? Andreas Mohr
Re: relay debugging broken?
Peter Ganten <[EMAIL PROTECTED]> writes: > it appears, that level 2 is held by something else. Setting > the argument of the SYSLEVEL_CheckNotLevel calls in relay32/relay386.c > to 3 helps, but I guess, that is not the right solution. The problem is that x11drv entry points are now proper dll exports and thus subject to relay debugging; but they can (and must) be called with the window lock held. A solution is to simply not do the syslevel check for x11drv (and ttydrv) entry points; a simple strcmp() on the dll name should work, though it is a bit ugly. -- Alexandre Julliard [EMAIL PROTECTED]
IsSingleWindow(): SYSLEVEL_CheckNotLevel
Hi all, I just saw that I get an err:win32:SYSLEVEL_CheckNotLevel (2): Holding lock of level 2! error when I run a program with --debugmsg +relay and it crashes and winedbg should be launched: trace:relay:WINPROC_CallWndProc (wndproc=DesktopWndProc_locked,hwnd=008c,msg=WM_NCCREATE,wp=,lp=) Call x11drv.16: IsSingleWindow() ret=404a48a9 fs=008f err:win32:SYSLEVEL_CheckNotLevel (2): Holding lock of level 2! Hmm, and as IsSingleWindow() got called from DesktopWndProc_*locked*, relay tracing gives a lock error as wndptr is locked and we call a function in x11drv. I guess this problem appears now due to the recent DLL separation work done by Alexandre. This isn't easy to fix, AFAICS. Normally I think we would just suspend the wnd lock and resume after the call, but of course the USER_Driver.pIsSingleWindow is not only x11drv.IsSingleWindow, but often native USER.IsSingleWindow. And in the native case, we can't be sure whether the native code doesn't want to do some more window locking. So we can't suspend the lock easily. This problem will show up in several cases now, I think, as more and more *builtin* DLLs will be separated and thus relay trace capable and subject to the locking check. What to do here ?? (and in similar cases !) For a description of the relay trace lock checking feature, see e.g.: From: Ulrich Weigand <[EMAIL PROTECTED]> Subject: Re: event.c Date: Thu, 11 May 2000 23:21:53 +0200 (MET DST) Andreas Mohr
relay debugging broken?
Hello, todays CVS crashes for me, when relay debugging is turned on: Call x11drv.17: LoadOEMResource(7fdb,0001) ret=40070059 fs=008f Ret x11drv.17: LoadOEMResource() retval=0cfe ret=40070059 fs=008f trace:relay:WINPROC_CallWndProc (wndproc=0x40047d80,hwnd=008c,msg=WM_NCCREATE,wp=,lp=) Call x11drv.16: IsSingleWindow() ret=40071869 fs=008f err:win32:SYSLEVEL_CheckNotLevel (2): Holding lock of level 2! fixme:pthread_kill_other_threads_np (the debugger crashes than with the same symptom). In gdb the backtrace from the syslevel error message looks like this: #0 SYSLEVEL_CheckNotLevel (level=2) at syslevel.c:231 #1 0x400b4f48 in RELAY_CallFrom32 (ret_addr=1078581433) at relay386.c:187 #2 0x40a97edd in exports () from /home/peter/wine/dlls/libx11drv.so #3 0x4049db08 in GetDC (hwnd=0) at dce.c:904 #4 0x4047403e in SetDeskWallPaper ( filename=0x ) at desktop.c:248 #5 0x40473e5d in DesktopWndProc (hwnd=140, message=129, wParam=0, lParam=0) at desktop.c:158 #6 0x404cff33 in WINPROC_wrapper () at winproc.c:117 #7 0x404cffc4 in WINPROC_CallWndProc (proc=0x40473dd0 , hwnd=140, msg=129, wParam=0, lParam=0) at winproc.c:169 #8 0x404d5090 in CallWindowProcA (func=0x40ce02bc, hwnd=140, msg=129, wParam=0, lParam=0) at winproc.c:2476 #9 0x404b2439 in MSG_SendMessage (hwnd=140, msg=129, wParam=0, lParam=0, timeout=4294967295, flags=4096, pRes=0x406d6c0c) at message.c:1779 #10 0x404b251e in SendMessageA (hwnd=140, msg=129, wParam=0, lParam=0) at message.c:1817 #11 0x404c6ad5 in WIN_CreateDesktopWindow () at win.c:651 #12 0x4046e8fd in USER_Init (hinstDLL=1078329344, fdwReason=1, lpvReserved=0x0) at user_main.c:259 #13 0x40062882 in PE_InitDLL (module=1078329344, type=1, lpReserved=0x0) at pe_image.c:682 #14 0x4005e4cd in MODULE_InitDLL (wm=0x40322158, type=1, lpReserved=0x0) at module.c:115 #15 0x4005e5f4 in MODULE_DllProcessAttach (wm=0x40322158, lpReserved=0x0) at module.c:181 #16 0x400608a9 in LoadLibraryExA (libname=0x400ce5e9 "user32.dll", hfile=0, flags=0) at module.c:1281 #17 0x40060c9e in LoadLibraryA (libname=0x400ce5e9 "user32.dll") at module.c:1398 and so on. it appears, that level 2 is held by something else. Setting the argument of the SYSLEVEL_CheckNotLevel calls in relay32/relay386.c to 3 helps, but I guess, that is not the right solution. Greetings, Peter -- Peter Ganten [EMAIL PROTECTED]
fonts (fwd)
HanSon, I believe that Korean fonts are supported under both X and Windows. I'm not sure if all the pieces are in place in Wine so that things will just work, perhaps someone else can comment? doug. [EMAIL PROTECTED] -- Forwarded message -- Date: Thu, 10 Aug 2000 14:49:34 -0400 From: Hanson Tieu <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: fonts Does WINE support Korean fonts? Or more precisely, does X support Korean fonts to be displayed from a WINE window? HanSon Tieu Product Specialist AIT Northrop Grumman-Canada, Ltd. 777 Walker's Line Burlington, Ontario (905)333-6075 [EMAIL PROTECTED]
Can of worms: Re: RFC: New wine command line option nneded
Hallo, it seems the command argument handling is a Can of Worms. I will look again after my holidays. Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: RFC: New wine command line option nneded
Uwe Bonnes wrote: > > Hallo, > > my last message: > Re: Don't double quote in build_commandline (fwd) > was meant as a RFC and layed out how I think the command line should > be handled. > > In short, it means that I need a mean to know if wine was started by > Createprocess() with an argv Array created by the starting windows > executable or by the Unix user from the commandline where much more > checking and changing on the delivered arguments has to be done. > > Is this acceptable? > > Any idea for the name? -- argvchecked? --wine-called? > > Anyway: the user shouldn't need that option, only the processing after > Createprocess() should add it and the processing after main() should > act accordingly. > > Bye > > Uwe Bonnes[EMAIL PROTECTED] > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > - Tel. 06151 162516 Fax. 06151 164321 -- For WordPerfect Office 2000 and CorelDRAW we found that we had enough other preconditions to set up that we used a launching script to invoke wine instead of enhancing Wine much to handle these cases. However, I don't know how much Createprocess() stuff is happening in those applications. It seems to work however often it happens :) We have encountered this tension between allowing the user to specify Unix style paths vs. DOS drive mapped paths. I want to get away from it as soon as possible because it is a *mess*. Yes, most of our applications are crippled from birth into understanding only DOS names, but forcing users to figure out drive letters for their UNIX file structures is not a friendly thing to do. How far away are we from detecting and mapping SMB share names[1] from the command line? I am not looking forward to typing in those verbatim: 'Was it filesrv\\albertd or "\\filesrv\albertd" or "SMB://filesrv/albertd"?' That said, maybe "--mapped-to-dos-already" is what you want for the option name? Albert. [1] what is the name for the "\\*\*" notation again? -- Albert den Haan, Lead Developer @ Linux Port Team . Corel Corporation [EMAIL PROTECTED] x 5318 -- The address in the headers is not the poster's real email address. Do not send private mail to the poster using your mailer's "reply" feature. CC's of mail to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]". The poster's email address is "[EMAIL PROTECTED]".
Re: lstrlenA exception handling
On Wed, 9 Aug 2000, Marcus Meissner wrote: > > Does that mean you have to do exception-handling calls in every function > > that could throw an exception? Or could the exception handling for a > > higher-level stack frame catch the invalid pointers somehow? > > Well, we only have to do it in functions that do it in Win95/Win98... > Unfortunately its a whole lot of it. We currently only do it for the ones > where we encounter an unexpected crash. It might be useful to have options (either compile-time or runtime) to do it more universally, in case of errors that don't cause an unexpected crash, yet corrupt data... (Making it optional because for performance...) > Higher-level handlers could catch those bugs too, but if an application > would catch lstrlenA failing, but did not expect it, we would void > the expectations of that program. I see. Relying on higher-level handlers would be more efficient, but would not be correct because the wrong offending function would be reported. Someone mentioned zero-cost exception handling in the Linux kernel; could that be used if available? Deven
Re: RFC: New wine command line option nneded
Uwe Bonnes writes: > And so there are two (at least) problematic cases. > > The first is with the unix filename leaking in the dos process. > > unix> wine /dosc/program.exe > > will result in argv[0] = "/dosc/program.exe" for the windows process, > if no very clever mechanisme is used to decide when to change > (windows) argv[0]. Having a command line switch to tell "hands off the > argv array," will make things easier. As I see it, we have the following different cases: 1. A windows program, started from the unix commandline. Here unix argv[0] is wine. In this case, we could just do GetFullPathName() of argv[1] to obtain the executables name, which will then become windows argv[0]. 2. A winelib program, started from the unix commandline. Here unix argv[0] is the name of the winelib program. Now argv[0] has to be translated to a windows filename. This will fail, if the winelib application is not accessible from a DOS drive. But maybe, we should prohibit this case, because functions like GetModuleFileName can't work in this situation. So we need a different treatment of argv in PROCESS_InitWine and PROCESS_InitWineLib, this is allready in place, but perhaps there should be a check, if (unix) argv[0] is accessable from a dos drive in case of a winelib application and I am not sure, if the filename of winelib applications are currently translated to dos filenames. 3. A windows program started with CreateProcess. As you point out, in this case we must check, which parts of the commandline are the executable and which parts are arguments. Furthermore, there is the possibility, that (windows) argv[0] is different from the executables name. The check for the executables name can be done in the context of the parent wine process and an (unix) argv[1] can containing the executables name can be set up. After that, the situation for the child process is the same as in (1). I am not sure, how to best handle the (windows) argv[0] != executable name case. Maybe the simplest solution here is, to pass the array through the server, as Alexandre has suggested, or indeed use a special options, which shifts the arguments, so that (windows) argv[0] is becomes (unix) argv[2] and argv[1] is the executables filename. Maybe another possibility would be to launch the child wine process with a different argv[0], but I do not like this, because we would need to decide, if we should interpret it in PROCESS_InitWine() depending on wines own executable file name and this will lead to strange results, if someone renames the wine executable. 4. A unix program started with CreateProcess. Do we have a decission, if it should be possible to start unix programs, which are not accessible from dos drives? If this should be possible, we need an algorithm to decide, whether to use a windows or a unix application (it might be possible, that c:\bin\ls is a different file than /bin/ls). In any case, we have to find the executable name in CreateProcess, to start the right executable. argv can be set up according to lpCommandLine (with argv[0] maybe something different than the executables name). 5. A winelib application started with CreateProcess. In this case, we again have the problem, that argv[0] might be not equal to the executables name. Again, we could go through the server here or use a "shift" commandline option. > The second is > > unix> wine -- "some long exe.exe" arg1 > versus > CreateProcess(NULL,"some long exe.exe arg1",...) > (Note: Windows tries "some" "some long" and "some long exe.exe" if > they are executable and encloses the successfull string in quotes. > > In the unix case, windows argv[0] will be 'some long exe.exe' as > the unix shell strips the quotes and in the Createprocess case it will > be '"some long exe.exe"'. That is the case in wine now (the quotes are stripped later in build_argv() ) Under windows, the child process does not see any quotes in its argv[0], so there should be no reason, to transport the quotes to the child process. > Again without the switch "don't touch the > argvarray" it is very delicate to build the commandline for > GetCommandline, as in the first case we need additional quotes and in > the second case not. I do not see, where we need additional quotes. And I think, it should be possible to start a windows program with the same combination of strange parameters from the unix command line, as it is possible using CreateProcess(). So after, thinking about this, I find know, that a --argshift option would be best, to handle the argv[0] != executable file case. Just my thoughts... Greetings, Peter -- Peter Ganten [EMAIL PROTECTED]
Re: FindResource(Ex): New attempt
Dmitry Timoshkov writes: > Ah, of course! Made another test and found: FindResourceEx with lang = 0 > behaves exactly as FindResource! > > Please try attached patch then... Yes, that works! Now, I still have the question, why you don't just use the value 0 to tag situations, where PE_FindResourceW instead of PE_FindResourceExW should be called. But that, of couse, is cosmetic. Greetings, Peter -- Peter Ganten [EMAIL PROTECTED]
Re: FindResource(Ex): New attempt
Peter Ganten <[EMAIL PROTECTED]> wrote: >The application is Winword from Office 97, german version. It does, >what this short program illustrates: [...] > hRes = FindResourceEx ( hMod, (LPCTSTR )0x2, (LPCTSTR )0x1c85, 0 ); Ah, of course! Made another test and found: FindResourceEx with lang = 0 behaves exactly as FindResource! Please try attached patch then... Dmitry. module.h.diff pe_resource.c.diff resource.c.diff
Re: FindResource(Ex): New attempt
Dmitry Timoshkov writes:
> >Sure, I just wanted, that you do not break working applications, which
> >your patch did for me.
>
> Strange, my intention was do not break something either :-)...
Good, we have the same intention :-))
> >The problems seems to be, that the application loads trys to access
> >some resource like this:
> >
> > (FindResourceExA+0x37(hModule=0x3060, type=0x2, name=0x1c85,
> >lang=0x0) [resource.c:349]) (ebp=406d3a80)
> >
> >That is, it does explicitely request the default resource (the library
> >at 0x3060 just contains german resources and it would load a
> >different library with another locale). Now with your patch, in
> >RES_FindResource2() we would call PE_FindResourceExW, since lang is
> >not 0x, but 0. I do not understand the rest completely, but that
> >resource is only found, if GetResDirEntryW is called with the
> >allowdefault flag set to true, which does not happen with your patch.
>
> I'm sure, that above call will fail under Windows too. My test program
> illustrates it fine.
No, it does not fail.
[snip]
> Anyway, though I'm sure that my patch behaves exactly as Windows, could
> you please either point me to the application that exhibits wrong
> behaviour with my patch, or to send to me some traces.
The application is Winword from Office 97, german version. It does,
what this short program illustrates:
===
#include
#include
int main ( int argc, char * argv[] ) {
HMODULE hMod;
HRSRC hRes;
hMod = LoadLibraryEx ( "mso7deu.dll", NULL, LOAD_LIBRARY_AS_DATAFILE );
printf ( "lib handle: %08x\n", hMod );
hRes = FindResourceEx ( hMod, (LPCTSTR )0x2, (LPCTSTR )0x1c85, 0 );
printf ( "resource handle: %08x\n", hRes );
return 0;
}
===
This test program does work under win95 (it returns the resource) and
does not work with your patch. The library must be findable by the
program, of cause. Maybe you can check this with the
russian equivalent of mso7deu.dll, otherwhise I could borough you that
library.
Greetings,
Peter
--
Peter Ganten
[EMAIL PROTECTED]
