January 2003 - Wine-Devel - list.winehq.org

Re: PATCH: glibc 2.3.x and errno

by Marcus Meissner

On Sat, Jan 25, 2003 at 04:43:09AM -0800, Francois Gouget wrote: > On Fri, 24 Jan 2003, Ulrich Weigand wrote: > [...] > > This means that C source code compiled against the new headers will > > result in assembler code that *directly* accesses a thread-local > > variable as defined by the TLS ABI. In the case of errno, this > > will involve accessing the %gs segment using an offset from the GOT, > > without any function call being performed. (errno is defined to use > > the initial-exec TLS storage model.) > > I probably only have a limited understanding of these threading > problems. However I had an idea and this limited knowledge lead me to > believe that it might work and so now I have to inflict it on the > world<g>. > > So basically the problem as I understand it is that both Linux libraries > and some Windows applications believe that the %gs register points to a > TLS structure, except that these two structures are not compatible. No, this is just a side problem only for 16bit applications. The problem is different. Lets have a small example: wine does: #include <errno.h> ... ret = mkdir("/blub/"); if (ret == -1) { fprintf(stderr,"mkdir failed with errno %d\n",errno); exit(1); } In 1980 this was rather nice and worked all the time with the nice global 'errno' integer variable. However, someone had to invent multi threading. After this, errno could not stay a global integer variable, since you could get into race conditions writing/accessing it. Sinc millions of lines of code could not be changed, the <errno.h> header was changed to defined it as: extern int *__errno_location(); #define errno *(__errno_location()) With __errno_location (or similar) a function that returns a pointer to an integer variable within the thread local storage area. (The same goes for __h_errno_location and other internal functions.) The glibc implementation basically does: ... convert registers ... int 0x80 jae error lret... error: ... lcall __errno_location mov errorcode , ($eax) ... lret glibc follows the pthread style of threading, at the time WINE needed threading implemented by SIGALRM timers within a single process (clone(2) was not invented yet). As WINE started Win32 threading the clone(2) handler was available for us and we implemented our own kind of threading, Windows style. glibc however does not know a single thing about that and still assumes there is no threading and had __errno_location return a single pointer. So we had to overwrite __errno_location(), which was easy possible, since libpthread also did so and it was exported as weak symbol meant to be overwritten. However with glibc 2.3 the internal thread representation changed, most pthread libraries now use clone(2) too, and use a new way of Thread Local Storage, using a segment register. Since WINE was using %fs, they chose to use %gs. Now a system call looks like: ... convert registers ... int 0x80 jae error lret... error: ... mov errorcode , %gs:(offset) ... lret So we no longer can overwrite __errno_location to have our own errno storage, so we need to cooperate with the libc threading. Ciao, Marcus

Jan. 25, 2003

Re: Games Swat 3d

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Mercredi 22 Janvier 2003 23:39, Greg Turner a écrit : > > > > can you report the current working state of the game under wine Dx > > after ? As d3d<8 not support multi-texturing yet, i think you should > > have some graphics problems > > OK, I gave this a whorl. It went surprisingly well. The installer, and > all the upgrades up to 2.1 (except maybe the mission pack) seem to go > fine. As for the game itself, no dice, it uses safedisc. But, I found > a no-cd at gamecopyworld ;) > > After swapping in their exe, it gets pretty far, but still no dice. It > behaves something like Rogue Spear: xvidmode changes, it complains > about some BitBlt stuff, and "locks up" silently without a crash. With > native devenum (thanks to the familiar DllGetClassObject unimplemented > in that dll), it even starts to play the intro music (via winealsa, my > audio is kind of screwed up ATM). It's having trouble with the intel > codec dlls, but, nevertheless, I get the feeling that it's a lot closer > to actually showing me something than it was the last time I tried this > game under wine. ouch ;( i'll try it to see how it locks ... but for me it seems a ddraw layer problem maybe lionel have already seen this behavior. > According to Transgaming's website, it runs better under winex, but > still exhibits some problems. > > Great game, I hope it improves. I wouldn't mind debugging this, I > really like this game a lot.... but I have a lot of wine stuff going on > right now, might not be the best moment to take on yet another pet > project. I guess it goes on my "fun" queue, which gets processed in > times of boredom :) > > I am a little concerned that once wine starts running my favorite games > well I am going to have a hard time getting work done :) lol don't worry we have hard work before wine running fully games like swat3d Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Mpwcp7NA3AmQTU4RAkf2AKCEx7Wg1gMPtpyMFKMAHkm01Y/Y1ACfYGs2 LXwrG/3C4xpRSha/iNTy+EY= =6C5H -----END PGP SIGNATURE-----

Jan. 25, 2003

Re: PATCH: glibc 2.3.x and errno

by Francois Gouget

On Fri, 24 Jan 2003, Ulrich Weigand wrote: [...] > This means that C source code compiled against the new headers will > result in assembler code that *directly* accesses a thread-local > variable as defined by the TLS ABI. In the case of errno, this > will involve accessing the %gs segment using an offset from the GOT, > without any function call being performed. (errno is defined to use > the initial-exec TLS storage model.) I probably only have a limited understanding of these threading problems. However I had an idea and this limited knowledge lead me to believe that it might work and so now I have to inflict it on the world<g>. So basically the problem as I understand it is that both Linux libraries and some Windows applications believe that the %gs register points to a TLS structure, except that these two structures are not compatible. Hmmm, wait a minute, could they be made compatible? E.g. by changing the struct definition in glibc? Anyway, assuming that's not possible... So we basically need separate values for this register for the Windows code and the Linux code. So why not save and restore that register whenever we enter and exit a builtin dll? It seems that it should be pretty easy to modify each DLL entry point to do: { wine_restore_linux_gs(); ... wine_restore_windows_gs(); return ret; } Of course, the DLL entry points are the easy part. The hard part is: * modifying all code that invokes a callback function to first restore the windows %gs and the linux one when the call returns * modifying all builtin callback functions to do the same as entry points * modifying all COM functions Well, now I will let people who know better explain why this cannot work :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Jan. 25, 2003

wine ICMP code

by Jason Algol

hi guys, in dlls/icmp/icmp_main.c would it be possible to use system("/bin/ping..."); if not running as uid 0?, (or using pipes if the ouput needs to be parsed) as /bin/ping is obviously usually suid root and if the required options are available as arguments to /bin/ping then wine can do as requested without running as root, this would be useful to me with something im working on. if you guys do consider it a possibility, i would be willing to research it and write the patch, id just like the go-ahead from you :) if you can think of any other way round it, id be greatful to hear your suggestions. _________________________________________________________________ Worried what your kids see online? Protect them better with MSN 8 http://join.msn.com/?page=features/parental&pgmarket=en-gb&XAPID=186&DI=1059

Jan. 25, 2003

resize client size errors

by Shachar Shemesh

Hi list, When running the winelib notepad in managed mode, after resizing the main window the scroll bar is not aligned with the right side of the windows as it is upon startup, but is located about one scroll bar's width to the left of the edge. This problem persists even if I change the code to explicitly call "GetClientRect", instead of using the parameters passed on WM_SIZE. I suspect that something in our resize code does not calculate the client area properly, causing this problem. Is there anyone here who wishes to take a look? Shachar

Jan. 25, 2003

build problem with current CVS (20030125 9:45 UTC)

by Stefan Leichter

Hello compiling the current cvs fails for me with: make[2]: Entering directory `/usr/src/wine/wine-build/dlls/winspool' gcc -shared -Wl,-Bsymbolic,-z,defs winspool.drv.spec.o info.o wspool.o winspool.drv.dbg.o -o winspool.drv.so -L../../dlls -L../../library -lwine -lm -lc info.o: In function `PRINTER_INFO_2AtoW': /home/sle/src/wine/wine-build/dlls/winspool/info.c:554: undefined reference to `HEAP_strdupAtoW' /home/sle/src/wine/wine-build/dlls/winspool/info.c:555: undefined reference to `HEAP_strdupAtoW' /home/sle/src/wine/wine-build/dlls/winspool/info.c:556: undefined reference to `HEAP_strdupAtoW' /home/sle/src/wine/wine-build/dlls/winspool/info.c:557: undefined reference to `HEAP_strdupAtoW' /home/sle/src/wine/wine-build/dlls/winspool/info.c:558: undefined reference to `HEAP_strdupAtoW' info.o:/home/sle/src/wine/wine-build/dlls/winspool/info.c:559: more undefined references to `HEAP_strdupAtoW' follow collect2: ld returned 1 exit status make[2]: *** [winspool.drv.so] Error 1 make[2]: Leaving directory `/usr/src/wine/wine-build/dlls/winspool' make[1]: *** [winspool] Error 2 make[1]: Leaving directory `/usr/src/wine/wine-build/dlls' make: *** [dlls] Error 2 Does someone else have this problem ? For me it looks like the patch http://www.winehq.com/hypermail/wine-patches/2003/01/0320.html or some parts of it did not make it into cvs Bye Stefan

Jan. 25, 2003

Re: Unhandled exception in VB app "Yardi Property Management"

by Marcus Meissner

On Sat, Jan 25, 2003 at 12:06:10AM -0800, Dan Kegel wrote: > A local company wants to run Yardi Professional Property Management, > a VB app that doesn't use Access, under Wine. (See http://www.yardi.com.) > > I tried it under CVS wine as of a few days ago. > Happily, the setup program completes, with just a few warnings > and one 'illegal function call' vb dialog box, e.g. > err:ddeml:WDML_CreateString Unknown code page 437 > err:module:BUILTIN32_LoadLibraryExA loaded .so but dll commdlg.dll still > not found - 16-bit dll or version conflict. > ... > Not bad, I guess; after all, setup did run all the way to the end. > > Problem came when I tried running the app. It gets an unhandled > exception -- and oddly, the wine debugger refused to run. > > [dank(a)boogie PMWPROG]$ wine --debugmsg +wc_font Y.EXE > err:fixup:NE_LoadSegment No implementation for HEDLG.26, setting to > 0xdeadbeef > err:fixup:NE_LoadSegment No implementation for HEDLG.27, setting to > 0xdeadbeef > fixme:hook:SetWindowsHookEx16 System-global hooks (7) broken in Win16 > fixme:hook:SetWindowsHookEx16 System-global hooks (2) broken in Win16 > wine: Unhandled exception, starting debugger... > trace:wc_font:WCUSER_SetFontPmt => L"Misc Fixed" h=13 w=0 > trace:wc_font:WCUSER_DumpLogFont InitFamily: truetype > lf.lfHeight=99 lf.lfWidth=97 lf.lfEscapement=0 lf.lfOrientation=0 > lf.lfWeight=400 lf.lfItalic=0 lf.lfUnderline=0 lf.lfStrikeOut=0 > lf.lfCharSet=0 lf.lfOutPrecision=3 lf.lfClipPrecision=2 > lf.lfQuality=1 > lf->lfPitchAndFamily=18 lf.lfFaceName=L"AdvMICR" > err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting > > Editing ~/.wine/config and changing UseXTerm to 0 helped there. > (And what the hell, I can never get wine debugger copy-and-paste to work > properly with that at its default value, so it's just as well.) > The error was: > Unhandled exception: privileged instruction in 16-bit code (25f7:0ca4). > Backtrace: > =>0 0x25f7:0x0ca4 (bp=6cd4) > 1 0x00f7:0x0000 (bp=6d1c, far call assumed) > 2 0x407cf7dd (K32WOWCallback16Ex+0x45(vpfn16=0x25f70c78, dwFlags=0x0, > cbArgs=0x18, pArgs=0x40e12b90, pdwRetCode=0x40e12b88) [wowthunk.c:298] in > kernel32.dll.so) (ebp=40e12b68) > 3 0x412d8005 (StgIsStorageILockBytes16+0x75(plkbyt=0x26ff0042) > [storage.c:1716] in ole32.dll.so) (ebp=40e12bbc) Now this should work. What does -debugmsg +relay,+ole say just before the crash? However, if it will try to create a IStorage interface later (most certainly) it will just fail, I did not come around to implement it yet. You still have to use: -dll compobj,storage,ole...=n Ciao, Marcus

Jan. 25, 2003

Unhandled exception in VB app "Yardi Property Management"

by Dan Kegel

A local company wants to run Yardi Professional Property Management, a VB app that doesn't use Access, under Wine. (See http://www.yardi.com.) I tried it under CVS wine as of a few days ago. Happily, the setup program completes, with just a few warnings and one 'illegal function call' vb dialog box, e.g. err:ddeml:WDML_CreateString Unknown code page 437 err:module:BUILTIN32_LoadLibraryExA loaded .so but dll commdlg.dll still not found - 16-bit dll or version conflict. ... Not bad, I guess; after all, setup did run all the way to the end. Problem came when I tried running the app. It gets an unhandled exception -- and oddly, the wine debugger refused to run. [dank(a)boogie PMWPROG]$ wine --debugmsg +wc_font Y.EXE err:fixup:NE_LoadSegment No implementation for HEDLG.26, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for HEDLG.27, setting to 0xdeadbeef fixme:hook:SetWindowsHookEx16 System-global hooks (7) broken in Win16 fixme:hook:SetWindowsHookEx16 System-global hooks (2) broken in Win16 wine: Unhandled exception, starting debugger... trace:wc_font:WCUSER_SetFontPmt => L"Misc Fixed" h=13 w=0 trace:wc_font:WCUSER_DumpLogFont InitFamily: truetype lf.lfHeight=99 lf.lfWidth=97 lf.lfEscapement=0 lf.lfOrientation=0 lf.lfWeight=400 lf.lfItalic=0 lf.lfUnderline=0 lf.lfStrikeOut=0 lf.lfCharSet=0 lf.lfOutPrecision=3 lf.lfClipPrecision=2 lf.lfQuality=1 lf->lfPitchAndFamily=18 lf.lfFaceName=L"AdvMICR" err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting Editing ~/.wine/config and changing UseXTerm to 0 helped there. (And what the hell, I can never get wine debugger copy-and-paste to work properly with that at its default value, so it's just as well.) The error was: Unhandled exception: privileged instruction in 16-bit code (25f7:0ca4). Backtrace: =>0 0x25f7:0x0ca4 (bp=6cd4) 1 0x00f7:0x0000 (bp=6d1c, far call assumed) 2 0x407cf7dd (K32WOWCallback16Ex+0x45(vpfn16=0x25f70c78, dwFlags=0x0, cbArgs=0x18, pArgs=0x40e12b90, pdwRetCode=0x40e12b88) [wowthunk.c:298] in kernel32.dll.so) (ebp=40e12b68) 3 0x412d8005 (StgIsStorageILockBytes16+0x75(plkbyt=0x26ff0042) [storage.c:1716] in ole32.dll.so) (ebp=40e12bbc) 4 0x412b516f (__wine_storage_dll_CallFrom16_p_long_l+0xb(proc=0x412d7f90, args=0x40fdbf5a) [storage.spec.c:169] in ole32.dll.so) (ebp=40e12bc8) 5 0x400c9cd5 (__wine_call_from_16_long+0x8d [relay16.s] in libntdll.dll.so) (ebp=40e12c00) 6 0x25df:0x198f (bp=6d56) 7 0x40086142 (NE_StartTask+0x1e6 [module.c:1234] in libntdll.dll.so) (ebp=40e12f04) 8 0x40081625 (task_start+0x41(pTask=0x40259728) [task.c:444] in libntdll.dll.so) (ebp=40e12f18) 9 0x400b2e54 (THREAD_Start+0x60 [thread.c:269] in libntdll.dll.so) (ebp=40e12f30) 10 0x400b227c (SYSDEPS_StartThread+0x8c(teb=0x40e23000) [sysdeps.c:165] in libntdll.dll.so) (ebp=40e12ff4) 11 0x420da1ca (NTDLL.DLL.memcpy+0x5dd7a) (ebp=00000000) Any suggestions? I'm kind of jazzed it gets this far... Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 25, 2003

Re: Packagers Guide Update #5

by Tony Lambregts

Dan Kegel wrote: > Tom Wickline wrote: > >>> IMHO this doesn't even have *any* business in the Packaging Guide. >>> The guide should simply contain a pointer to the REAL sample config >>> file ... >> >> >> I'm not saying this is the best approach but at least it is upto date! > > > How about writing a shell script or Makefile rule to > automatically insert the current config into the > doc when you're about to process it? > - Dan > I don't think it is nessasary for a configure or shell script for this. I think we can just include it. Declaring it as an entity and wraping it in <programlisting> _should_ work. Tom: you can try this your self or if you want/need some help with this I'll see what I can do. -- Tony Lambregts

Jan. 25, 2003

Re: PATCH: glibc 2.3.x and errno

by Gavriel State

Alexandre Julliard wrote: > I'm afraid that won't be enough. When using thread-local storage, > glibc doesn't even call __errno_location any more, it directly stores > errno into the thread storage using %gs. It seems the only solution is > to make Wine threads work on top of libc threads, but that will be > messy. We have a winethreads-on-pthread implementation that we did for some of our non-x86 work a while back. It's pretty simple, and we haven't really tested it on an x86 machine recently - when we did so last, it definitely had some problems. It is pretty similar to work that Andrew Lewycky did at Corel to support cprof and multithreaded profiling, and probably has some of the same caveats that were discussed on wine-devel in March of 2000. The code (excluding some configure checks) is here - some updates will probably be required to get it working with a more recent tree. WineHQ is welcome to use it. It would be nice if any improvements made to it were donated to ReWind as well: http://www.geocrawler.com/archives/3/9376/2001/12/50/7309863/ Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. gav(a)transgaming.com http://www.transgaming.com/ Let the games begin

Jan. 25, 2003