April 2002 - Wine-Devel - list.winehq.org

NT Status vs. Dos Error code in async operations

by Martin Wilck

Hi, If my understanding of the MS docs is correct, the status of overlapped requests is stored as an NT status in lpOverlapped->Internal (As Mike implemented it). The error code returned by GetOverlappedResult() or passed to the completion routine, though, is a DOS error code. Thus in priciple we'd need to convert the status with RtlNtStatusToDosError(), right ? Moreover, if our async read()/write() operations fail, we simply set the status to STATUS_UNSUCCESSFUL which translates to ERROR_GEN_FAILURE - not very meaningful to our users. What we'd need would consequently be a errno->NT status converter to set the overlapped status correctly from the error reported by read or write. I can't seem to find one in the wine code (??). There only seem to be local errno -> DOS error converters, and no DOS error->Nt status converter. What should we do? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 10, 2002

Re: winebuild broken?

by Michael Cardenas

Michael Cardenas wrote: > It seems that with the new dll separation changes, winebuild is > broken. I've been trying to build an app with winebuild, and it tries > to open kernel32.dll.so instead of libkernel32.dll.so when trying to > resolve the "import kernel32.dll" line of the spec file. This works > for compiling wine, but not for compiling external apps that use the > installed lib directory. > Nevermind, Jeremy solved the problem by just passing the wine src dir to configure as an include dir. -- michael cardenas lead windows compatibility engineer www.lindows.com "Be the change you want to see in the world." -Mahatma Gandhi

April 9, 2002

winebuild broken?

by Michael Cardenas

It seems that with the new dll separation changes, winebuild is broken. I've been trying to build an app with winebuild, and it tries to open kernel32.dll.so instead of libkernel32.dll.so when trying to resolve the "import kernel32.dll" line of the spec file. This works for compiling wine, but not for compiling external apps that use the installed lib directory. I'm not sure if I should fix winebuild to look for lib(name).dll.so or if I should change the dll makefiles to create the correct symlinks so that wine can compile or if we should make winebuild check for both lib(name).dll.so and (name).dll.so. For now, I'm doing the last case, which works fine, so I can submit that patch if you want it. There is also the problem of dlls in the wine directory which are not found either, which I'm still working on. -- michael cardenas lead windows compatibility engineer www.lindows.com "Be the change you want to see in the world." -Mahatma Gandhi

April 9, 2002

Re: Failing MODULE_DllProcessAttach causes other module left uninitialized

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > I think the original error was obscured to much here. Either we judge a > failing InitDLL as error and abort there, or in MODULE_DllProcessAttach we > should recurse without looking at the result. A failed InitDLL is an error, we can't simply ignore it and continue. We have to unload the dll and its dependencies in that case; but that's not entirely trivial to do. -- Alexandre Julliard julliard(a)winehq.com

April 9, 2002

Re: Starting application from a directory with some kernel32.dll

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > But loading native kernel32 and friends will lead to a crash. Would you > abject an explicit check for those? As long as it is configurable that would be acceptable. But you cannot simply hard-code kernel32 as builtin all the time, there may be cases where you want to load the native. And note that you can already specify a full path in the load order config so you could use that to solve the problem in your case. -- Alexandre Julliard julliard(a)winehq.com

April 9, 2002

Re: Return To Castle Wolfenstein

by Andreas Mohr

On Tue, Apr 09, 2002 at 09:01:34AM +0200, Michal Seliga wrote: > Greetings > > I use wine from 10.3.2002 > > I tried to run Return To castle Wolfenstain in it. Works almost great! I found few problems I would like to tell you, maybe they are solved already > > 1) installation: font is wider then expected (I think) so it looks like not all texts are fully visible or they collide with buttons (screenshot on request) > 2) installation: in part where i should write an installation code, there are places for 4 characters in all textfields, but when I type in 2 characters it > will > jump to the next one. It looks like if editfield is xx chars long, then after writing xx/2 characters it thinks it is already all filled 3) game: works in Probably yet another unicode bug: sizeof(WCHAR) == 2 != sizeof(CHAR) == 1 Use --debugmsg +relay,+edit to try to find out more. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

April 9, 2002

Failing MODULE_DllProcessAttach causes other module left uninitialized

by Uwe Bonnes

Hallo, in loader/module.c:MODULE_DllProcessAttach the recursion to attach ends as soon as _one_ initialization fails. This leaves other modules uninitialized. I had this problem with xnview and native shell (without native shfolder). The missing SHGetFolderPathA caused COMDLG32_DllEntryPoint to return FALSE and in cause WSVFW32_LibMain wasn't called. Later this caused MULTIMEDIA_GetIData to not find it's IData and cause a crash. The missing HGetFolderPathA wasn't the culprit. I think the original error was obscured to much here. Either we judge a failing InitDLL as error and abort there, or in MODULE_DllProcessAttach we should recurse without looking at the result. What about appended patch? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/loader/module.c =================================================================== RCS file: /home/wine/wine/loader/module.c,v retrieving revision 1.150 diff -u -r1.150 module.c --- wine/loader/module.c 2 Apr 2002 19:47:30 -0000 1.150 +++ wine/loader/module.c 9 Apr 2002 14:06:26 -0000 @@ -212,17 +212,14 @@ wm->flags |= WINE_MODREF_MARKER; /* Recursively attach all DLLs this one depends on */ - for ( i = 0; retv && i < wm->nDeps; i++ ) + for ( i = 0; i < wm->nDeps; i++ ) if ( wm->deps[i] ) - retv = MODULE_DllProcessAttach( wm->deps[i], lpReserved ); + MODULE_DllProcessAttach( wm->deps[i], lpReserved ); /* Call DLL entry point */ + retv = MODULE_InitDLL( wm, DLL_PROCESS_ATTACH, lpReserved ); if ( retv ) - { - retv = MODULE_InitDLL( wm, DLL_PROCESS_ATTACH, lpReserved ); - if ( retv ) - wm->flags |= WINE_MODREF_PROCESS_ATTACHED; - } + wm->flags |= WINE_MODREF_PROCESS_ATTACHED; /* Re-insert MODREF at head of list */ if ( retv && wm->prev )

April 9, 2002

Re: CVS won't compile with wine/dlls/winsock socket.c ws2_32.spec patch applied

by Martin Wilck

Please try the following mini-patch: --- dlls/winsock/socket.c.ORIG Tue Apr 9 10:50:50 2002 +++ dlls/winsock/socket.c Tue Apr 9 10:51:03 2002 @@ -57,6 +57,7 @@ #ifdef HAVE_SYS_SOCKET_H #include <sys/socket.h> #endif +#include <sys/uio.h> #ifdef HAVE_NETINET_IN_H # include <netinet/in.h> #endif -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 9, 2002

Re: Bitblt::Maskblt code ready for CVS

by Uwe Bonnes

>>>>> "Lonnie" == Lonnie Cumberland <lonnie(a)outstep.com> writes: Lonnie> Hello All, I have worked out the modifications and Lonnie> implementation for the Lonnie> maskblt() functin Lonnie> in the graphics/bitble.c sources and have been able to run it in Lonnie> my version of wine 20020310 release. Lonnie> How can I get the source for the new bitble.c, or the new Lonnie> Maskblt() routine added to the CVS tree? By sending it to wine-patches(a)winehq.com or wine-devel(a)winehq.com if you want it discussed or to Alexandre directly. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 9, 2002

Re: Starting application from a directory with some kernel32.dll

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> when an application is run in a directory, where there is also a >> kernel32.dll, and this is _not_ the system directory, >> MODULE_GetLoadOrder doesn't strip the path and therefore crashes when >> native kernel32.dll is loaded. >> >> While the header of MODULE_GetLoadOrder talks about "any path is >> stripped", the function only strips the path for "16 bit modules or >> if the module resides in the system directory " >> >> Is this intended behaviour? Alexandre> Yes, there can be multiple versions of a 32-bit dll with the Alexandre> same name in different directories, and we have to be able to Alexandre> configure them separately. But loading native kernel32 and friends will lead to a crash. Would you abject an explicit check for those? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 9, 2002