- wine-devel - winehq.org

Dsound test fails with E_NOTIMPL error
by Sylvain Petreolle 25 Feb '03

25 Feb '03

make[3]: Entre dans le répertoire `/home/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok fixme:dsound:IDirectSoundImpl_SetCooperativeLevel 0x4026c758,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,1):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,1):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,1):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,1):stub fixme:wave:IDsCaptureDriverImpl_GetDriverDesc (0x4026c528,0x4026c778): stub! fixme:wave:IDsCaptureDriverImpl_Open (0x4026c528): stub! dsound.c:643: Test failed: DirectSoundCaptureCreate failed: 0x80004001 fixme:wave:IDsCaptureDriverImpl_Close (0x4026c528): stub! make[3]: *** [dsound.ok] Erreur 1 make[3]: Quitte le répertoire `/home/wine/dlls/dsound/tests' make[2]: *** [tests/__test__] Erreur 2 make[2]: Quitte le répertoire `/home/wine/dlls/dsound' make[1]: *** [dsound/__test__] Erreur 2 make[1]: Quitte le répertoire `/home/wine/dlls' make: *** [dlls/__test__] Erreur 2 ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

gcc 3.2.2?
by Gregory M. Turner 25 Feb '03

25 Feb '03

To my surprise, Gentoo (ACCEPT_KEYWORDS="", iow "stable" Gentoo) is ready to give me gcc 3.2.2 (in fact it compiles as I type). So, what can I expect from wine and gcc322? Any known interestingnesses? Anyone even tried it? Presumably, since the threading magic needs to be in the kernel (I run a modified linux-2.4.21-pre4-ac5 atm), I will not get the pthread bug... but then again, how do I know for sure if I suffer from that or not? Is there a test that is known to reliably break against the new threading model (or perhaps I can presume I "got it" if i can't run notepad?1) whee, gotta love Gentoo, where "stable" means "it's been released for several days" ;) -- gmt "Of all the tyrannies, a tyranny sincerly exercised for the good of its victims may be the most opressive. It may be better to live under robber barons than under omnipotent moral busybodies. The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end, for they do so with the approval of their own conscience." - C. S. Lewis

6 9

Is there some test app that reliable crashes?
by Gerhard W. Gruber 25 Feb '03

25 Feb '03

I need some app that will produce a crash in order to test winedbg and get used to it. Does anybody have such an application or can tell me a quick way how to create one? Except booting to Windows and writing a NULL pointer access or some such. :) I installed winedbg according to the winehq instructions but when Agent crashes and I say Yes to debug it the wineserver and agent is stuck and I have to kill -9 it. Maybe this is because the output goes to the console window? I think I read something about console but I have no console as a normal user so I can't check this. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

4 6

thread safe?
by Lonnie Cumberland 25 Feb '03

25 Feb '03

Hello All, I was wondering if someone could please tell me if Wine is thread safe? That is, I am wondering if is possible to be running multiple Windows applications under wine at the same time without much degradation of the performance of the system? Thanks in advance, Lonnie __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/

3 2

Retiring...for now
by Dustin Navea 25 Feb '03

25 Feb '03

Hey guys, I know its been a while.. Things have changed a lot since my last contact with you guys, just thought I would give you a heads up.. I couldnt afford the phone/dsl and let that go, lucky my email is still in tact.. Then I lost my job and couldn't afford rent, so I sold my PC.... :'-( Now, Im gettin ready to start a new job as a telemarketer, and will hopefully be able to make rent this month.. I think everything will be O.K. I just need time to get my priorities straight.. I will probably be leaving to go into the U.S. Army toward the end of the year this year or beginning of next year... Anyways, It's been fun; anyone that wants to take over my bugs on bugs.winehq.com may do so, anyone that wants to take over any of my other tasks (User's Guide, etc) may do so as well, but save a spot for in case I ever find a way to get back here.. May you all have much luck in your journeys and I hope to see you all again someday... Regards, Dustin

4 3

MoveFileW bug?
by Roderick Colenbrander 25 Feb '03

25 Feb '03

Hi, Today someone asked me to look at some Wine problems when running a gaming app called "Steam". Because I wasn't using the latest version of the app, the program tried to update itself. During the update process the main program (steam.exe) needs to be replaced by a new version. To do this the old program exits and another executable is being launched. The new process tries to backup the old steam.exe to wine's temp drive to restore it in case something goes wrong. Here the real problem appears. After "moving/renaming" the file the update tool gives an error stating that steam.exe still exists. After looking at the debug output I saw that to move the file the update tool is using MoveFileW. Normally nothing is wrong with this but according to MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/bas…) it can be used for about everything except for the following: "The MoveFile function will move (rename) either a file or a directory (including its children) either in the same directory or across directories. The one caveat is that the MoveFile function will fail on directory moves when the destination is on a different volume." The update tool is using something like this: MoveFileW(steam.exe, e:\\steam.exe) So it tries to move a file from c:\steam\steam.exe to e:\steam.exe which according to the MSDN docs is not possible. The same works fine on Win2k. After hacking MoveFileW to not check if the volumes are different it worked fine on Wine too. What shall we do? Shall we implement the same bugs Windows is doing or shall e listen to the docs at MSDN? (I'm sure some tests need to be made) Roderick Colenbrander

3 3

[Fwd: Re: GDI question]
by Mike Hearn 25 Feb '03

25 Feb '03

-----Forwarded Message----- From: James Chaldecott <james(a)swythan.co.uk> To: m.hearn(a)signal.dra.hmg.gb Subject: Re: GDI question Date: 25 Feb 2003 09:32:48 +0000 Mike, I'm a Win32 developer, and I take a look at WineHQ every so often and I noticed this thread. I don't know what Wine performance is like, but I thought you might be interested to know that some Windows graphics drivers (particularly Nvidia) are also very slow doing off-screen BitBlt operations under some circumstances. BitBlt'ing between two memory DC's seems to get very slow if the "acceleration level" is set to "Full" (the default) in the driver. I'm guessing they are, in fact, trying to overoptimize and they assume that at least one of the DC's is a real device (i.e. already in video memory), although I don't really know. We have the problem with our software and found the easy way to overcome it was to drop the driver acceleration factor a notch! I also spotted a bug in Mozilla's Bugzilla DB, and did some profiling for them. http://bugzilla.mozilla.org/show_bug.cgi?id=170272 Anyway, I thought you might be interested. I suppose it means that lots of the BitBlt's being done *are* being accelerated by the hardware, and this is a corner case were performance degrades. James Chaldecott P.S. Feel free to post this to the list if it's interesting, but I don't subscribe, ATM. >Well, I just tried a simple comparison of the Adobe SVG plugin under >Wine and IE6 on Windows XP. Wine _is_ slower by a visible amount when >doing repeated bitblts such as the plugin does on an animation I have, >but it's certainly not something that'd actually affect real world >usage. I don't think GDI performance is really an issue at present, most >apps don't do these kind of repeated double-buffer switches (i assume >flash doesn't actually use the gdi to render into its backbuffer?) so it >only affects apps like photoshop and director/flash. > >In particular when I run the SVG plugin, I can see a FIXME talking about >a potential optimization, so really the issue is just a case of elbow >grease for optimizations (esp in bitblt) rather than a rewrite I'd guess. > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Was reading through the newest news and wondered about Transgaming's fix.
by Joe Millenbach 25 Feb '03

25 Feb '03

Did I read that correctly, in that they fixed whatever issues Wine has with glibc 2.3? So that issue with threads being different would be fixed with this? And if the above is true then are they planning to submit this to the Wine project or is this only for thier version? Thanks for your time, Joe Millenbach _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

3 2

Re: Spam/Bounce-Mail
by Dan Kegel 25 Feb '03

25 Feb '03

Joerg Frings-Fuerst wrote: > first I say sorry for your trouble with my bounce-mails. > > This weekend I setup my new Mail-Backupserver. After this work I test a new > version of my Spamcheck-script. In this script I call "rblcheck". My mistake > was the test via list.dsbl.org. I don't mind -- it revealed a bug in my email setup! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: Don't use -Wpointer-arith if it produces excessive warnings
by Dmitry Timoshkov 25 Feb '03

25 Feb '03

"Mike McCormack" <mike(a)codeweavers.com> wrote: > On Slackware 8.1, this caused a screenful of warnings for *every* file > compiled, which makes it difficult to see important warnings. Same on RH 6.2. But it's actually bug(s) in string.h and a better way IMHO is just fix it, instead of silencing warnings if a user is *really* annoyed by that avalanche of warnings. -- Dmitry.

2 4

Re: WCMD AutoExec patch
by Eric Pouech 24 Feb '03

24 Feb '03

Dave Pickles wrote: > As discussed on Wine-devel recently this patch allows wcmd to execute a file > "autoexec.wine" if it exists in the root directory of the default drive. I think we'd better shouldn't we look in <%sysdir%>\system32\autoexec.wine instead (that's where NT puts the autoexec.nt files that cmd.exe loads on startup) ? A+ -- Eric Pouech

2 1

Re: wine/dlls/x11drv x11drv_main.c
by liu spider 24 Feb '03

24 Feb '03

It crashed every time when I closed an app, not just "sometimes" :( And I think maybe exchange the calling order of XCloseIM and XCloseDisplay is a better method than just comments out XCloseIM ( I think this will lead to some other problems). --- Alexandre Julliard <julliard(a)wine.codeweavers.com> wrote: > ChangeSet ID: 7168 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/01/29 > 19:08:53 > > Modified files: > dlls/x11drv : x11drv_main.c > > Log message: > XCloseIM sometimes crashes in Xlib, don't call it. > > Patch: http://cvs.winehq.com/patch.py?id=7168 > > Old revision New revision Changes Path > 1.67 1.68 +1 -1 > wine/dlls/x11drv/x11drv_main.c > > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 5

Re: Crashes in OSSs audio.c on FreeBSD
by Eric Pouech 24 Feb '03

24 Feb '03

> BSD is probably doing the same thing, but nevertheless, -STABLE (i.e. > FreeBSD 4.x) has a bug in the pcm-driver (I think) which makes mapping > the buffer write-only impossible (at least for me). > > FreeBSD 5.x does not have that problem and sadly the pcm-code between > 4.x and 5.x is virtually the same. I think I remember BSD folks speaking of mmap changes... can someone confirm ? >>>+#ifndef __FreeBSD__ >>> /* for some reason, es1371 and sblive! sometimes have junk in here. >>> * clear it, or we get junk noise */ >>> /* some libc implementations are buggy: their memset reads from the >>> buffer... >>>@@ -1826,6 +1832,9 @@ >>> /* in all cases, fill the remaining bytes */ >>> while (len-- != 0) *p1++ = 0; >>> } >>>+#else >>>+ memset(wwo->mapping,0, wwo->maplen); >>>+#endif >> >>you shouldn't need this chunk > > > I know, this has nothing to do with mmap()ing the buffer, but it looks > like FreeBSDs libc doesn't have the bug with memset(), so I just used > that instead. sure, not all Linux distros have this bug, but it creates a new code path, which is bad for maintenance... so leaving the code as it is, is a better option A+ -- Eric Pouech

1 0

Rebuilding font retrics each time Wine starts.
by J. Grant 24 Feb '03

24 Feb '03

Hi, Is there a reason the "font metrics" are rebuilt every day or so? (when I start to run a program with wine) I am using cvs 20030115 Regards JG

2 1

Re: Users Guide - added basic usage section
by Dan Kegel 24 Feb '03

24 Feb '03

Mike Hearn wrote: > + <para> > + Some programs install associated control panel applets, examples of this would be > + Internet Explorer and QuickTime. You can access the Wine control panel by running: > + </para> > + > + <screen> > + <prompt>$</prompt> <userinput>wine control</userinput> > + </screen> > + > + <para> > + which will open a window with the installed control panel applets in it, as in Windows. > + </para> Um, I tried running wine control and it started running, then exited silently, presumably because no apps have installed any controllet. Either we need to fix that doc, or we need to add a controllet for wine itself, so the list is never empty, or we need to make control.exe put up a dialog box saying "no control panel thingies installed". - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

Re: x11drv, ntdll separation
by David Fraser 24 Feb '03

24 Feb '03

Johan Gill wrote: > Mike Hearn wrote: > >>> And I have it in my tree :) It should be ready for submission in a >>> few months from now. >>> >> >> >> Hvae you checked that it wouldn't be easier to merge in the TransGaming >> implementation? It seems daft to duplicate work if that's the case... >> >> >> >> > It is their work, but I'm doing heavy changes. What stage is the implementation currently at? According to the TransGaming docs, there are still a number of functions to fill in... I would be interested in seeing a patch no matter how much/little is implemented ... because my main aim in getting rid of the fault handler is so that the x11drv can be ported to Windows... David

2 2

Re: Users Guide - added basic usage section
by Keith Matthews 24 Feb '03

24 Feb '03

On Mon, 24 Feb 2003 14:17:41 +0100 Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > And BTW: why is it that once you decide to do some major work, > EVERYBODY suddenly happens to come out of the eternally dark and dangerous > and forgotten woods?? ;-) > Looks like murphy wins again.

1 0

Re: Users Guide - added basic usage section
by Mike Hearn 24 Feb '03

24 Feb '03

> Again, I'm currently working on a MAJOR update of the Guides. > I'll incorporate these parts into my version. > And BTW: why is it that once you decide to do some major work, > EVERYBODY suddenly happens to come out of the eternally dark and dangerous > and forgotten woods?? ;-) Oops, sorry :) Well, just take it to mean that you chose a worthwhile thing to work on. I look forward to the new guides :) -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

Re: (resend) tests for GetPrivateProfileInt
by Dmitry Timoshkov 24 Feb '03

24 Feb '03

"Stefan Leichter" <Stefan.Leichter(a)camLine.com> wrote: > here are some tests for the function GetPrivateProfileInt. The expected > results are the one from NT4. Hopefully the will match for Win 9x also. > Before i convert GetPrivateProfileInt from ascii to unicode i like to > see some test result from Win9x/ME. > > ChangeLog > ------------- > Added test for GetPrivateProfileInt 1. The patch got wrapped by your mailer. 2. Unicode and Ansi versions of GetPrivateProfileInt (as all other APIs) should be tested separately. -- Dmitry.

2 2

Re: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 24 Feb '03

24 Feb '03

Roland McGrath wrote: > > In glibc, we actually allocate some excess space in the thread-local > storage area layout determined at startup time. This lets a dynamically > loaded module use static TLS if its PT_TLS segment fits in the available > surplus. (In sysdeps/generic/dl-tls.c, see TLS_STATIC_SURPLUS.) If there > is insufficient space preallocated, then loading the module will fail. In > fact, we put this feature there with GL in mind and can adjust the > preallocated surplus for what is most useful in practice. The last time we discussed this issue, I had the distinct impression that an OpenGL library would essentially be forced into using one of the dynamic access models (GD or LD) for __thread variables, hence requiring at least one function call to access a thread-local variable. I also had the distinct impression that the glibc maintainers were unwilling to modify their implementation so that we could use the LE access model, which would allow a 2 instruction thread-safe dispatcher among other things. It looks like I was wrong, and you've gone and addressed all the concerns I originally had with __thread variables. For that, I'm grateful. > In fact, we put this feature there with GL in mind... Did you inform the OpenGL vendors who were interested in this issue of this fact? Have you documented it anywhere, particularly in Ulrich Drepper's "ELF Handling For Thread-Local Storage" document? The current version of this document clearly states that the Local Exec TLS model "can only be used for code in the executable itself and to access variables in the executable itself". Perhaps you can see why I was still under the impression that it would not work for a dynamically loadable shared library. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

Building wine tests with nmake and cl in linux
by Dan Kegel 24 Feb '03

24 Feb '03

OK, so there's msvcmaker, but I don't use guis, so I threw together a way to build the wine tests using cl and nmake. I have the following files in ~/bin: nmake: wine -- wcmd /c F:\\bin\\nmake.bat "$@" nmake.bat: call f:/bin/vcvars32.bat echo on nmake %1 %2 %3 %4 %5 %6 vcvars32.bat: same as normal one, but without quotes nmakemaker: (attached) Then in any dll/tests directory, I can type nmakemaker > foo.mak nmake /f foo.mak and build all my tests with msvc. Each test is built as a separate executable, but that's the way I like it for testing anyway. Now I guess I'll submit patches to make everyone else's tests actually *compile* under msvc. It was real funny to see that article on slashdot appear as I was doing this. I seem to have gone a bit further than that guy, since I don't have to use that awful, horrible wcmd window. -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 #!/usr/bin/perl for $file (<*.c>) { push(@files, $file) if ($file !~ /generated.c/ && $file !~ /.spec.c/); } print "CC = cl\n"; print "CFLAGS = -I../../include\n"; print "all: "; foreach $a (@files) { chomp $a; $a =~ s/\.c$//; print "$a.exe " } print "\n"; foreach $a (@files) { chomp $a; $a =~ s/\.c$//; print "$a.exe: $a.c\n\t\$(CC) \$(CFLAGS) $a.c -o $a.exe\n" }

1 0

interestig link
by Igor 24 Feb '03

24 Feb '03

http://codingstyle.com/articles/using-ms-vcpp-with-gnu-wine.html

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 24 Feb '03

24 Feb '03

Ulrich Weigand wrote: > > From what I can see, you are actually getting LE model code > (omitting the ebp stuff which you can avoid using > -fomit-frame-pointer): > > movl %gs:0, %eax > movl __foo_dispatch@NTPOFF(%eax), %edx > movl (%edx), %ecx > jmp *%ecx > > Note that NTPOFF is used; for IE, you'd see INDNTPOFF > or GOTNTPOFF and an additional indirection. Right, thanks! Makes sense. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

1 0

Detect wine filesystem inconsistency ?
by Sylvain Petreolle 24 Feb '03

24 Feb '03

Digging into my C:\\windows\\system directory, I accidentally found two versions of shlwapi.dll. With chance, the 2 versions were identical. What if they werent ? I could have load an old version of the library or worse, of a document. Note this can happen with every file on the virtual disks if they re stored on a case sensitive filesystem. Could we detect and report a such "duplicated" file ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Wine Packagers Guide
by Dimitrie O. Paun 24 Feb '03

24 Feb '03

On February 16, 2003 12:53 am, Tony Lambregts wrote: > Change Log: Split up the Packagers Guide and move it to its own > directory. Include the the sample config file This is a bit of a problem: Tom is working on it, and splitting it now will screw him badly. Let's do the merge after he finishes integrating his changes. -- Dimi.

3 2

named pipe oddity
by Dan Kegel 24 Feb '03

24 Feb '03

A while ago, I noticed that our setup program didn't work with cvs wine. Somebody said "Oh, that's because named pipes are broken." Since then, the setup program works again with cvs wine, but I'm still curious about the state of named pipes. The simple sequence CreateNamedPipe CreateFile seems to work under Windows, but not under Wine. Does Wine for some reason require a ConnectNamedPipe between the two? A very simple test is attached. (BTW, I've been looking at the wineserver named pipe code a bit. Shame it's not better commented... at least it's small, so the lack of comments isn't too awful.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: dlls/kernel/tests/Makefile.in =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/Makefile.in,v retrieving revision 1.6 diff -u -p -u -r1.6 Makefile.in --- dlls/kernel/tests/Makefile.in 4 Oct 2002 17:42:27 -0000 1.6 +++ dlls/kernel/tests/Makefile.in 13 Feb 2003 16:54:45 -0000 @@ -17,6 +17,7 @@ CTESTS = \ generated.c \ locale.c \ path.c \ + pipe.c \ process.c \ thread.c --- /dev/null 2002-08-30 16:31:37.000000000 -0700 +++ dlls/kernel/tests/pipe.c 2003-02-17 17:26:42.000000000 -0800 @@ -0,0 +1,80 @@ +/* + * Unit tests for named pipe functions in Wine + * + * Copyright (c) 2002 Dan Kegel + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <stdlib.h> +#include <stdio.h> +#include <time.h> + +#ifndef STANDALONE +#include "wine/test.h" +#else +#include <assert.h> +#define START_TEST(name) main(int argc, char **argv) +#define ok(condition, msg) assert(condition) +#endif + +#include <windef.h> +#include <winbase.h> +#include <winerror.h> +#include <wtypes.h> + +#define PIPENAME "\\\\.\\PIPE\\tests_pipe" + +void test_CreateNamedPipeA(void) +{ + HANDLE hnp; + HANDLE hFile; + + /* Functional checks + * Just check things used internally by wine, in e.g. + * wine/dlls/ole32/compobj.c + * wine/programs/rpcss/np_server.c + * wine/dlls/rpcrt4/rpc_binding.c + */ + + hnp = CreateNamedPipeA(PIPENAME, + PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, + PIPE_UNLIMITED_INSTANCES, + 4096, + 4096, + NMPWAIT_USE_DEFAULT_WAIT, + NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + /* in wine, the CreateFile is in a different thread, but that + * shouldn't matter. Also, the first thread does a ConnectNamedPipe, + * but that isn't required by the Win32 API, it's optional. + */ + hFile = CreateFileA(PIPENAME, GENERIC_READ|GENERIC_WRITE, 0, + NULL, OPEN_EXISTING, 0, 0); + ok(hFile != INVALID_HANDLE_VALUE, "CreateFile failed"); + + if (hFile != INVALID_HANDLE_VALUE) { + CloseHandle(hFile); + } + + CloseHandle(hnp); +} + +START_TEST(pipe) +{ + test_CreateNamedPipeA(); +} +

3 11

gtk look progress and pthreads.
by James Gregory 24 Feb '03

24 Feb '03

Hi all, I posted something similar to mono-devel, so sorry if any of you are seeing this twice. I've spent some time working on getting wine to have the option to look like a gtk app. At present I'm just trying to get wine to use the same colours as the current GTK theme. I made great progress on this last night: modified configure.ac et al to allow building against gtk, added an item to the enum for the various "looks", added the option so setting "WineLook" does the right thing for this new look. I added another array of colour settings to syscolor.c, and modified the condition that loads in that array to recognise the new colours (which are currently all set to red), and call a function to do a gtk_init() (for those who are wondering, I'm currently using a dummy argc and argv in the call. I'll do something about this later) and then start setting that array to the *actual* colours of the gtk theme (I chose red to make it easy to find bugs -- colours that weren't set would be obvious) Now, this was all going great up until the gtk_init() call. I'm now in the position where running I'm wine and seeing this sort of thing: $ LD_LIBRARY_PATH=/home/james/lib /home/james/bin/notepad Loading required GL library /usr/X11R6/lib/libGL.so.1.2 wine: Unhandled exception, starting debugger... FIXME:pthread_cond_init (repeated n times) Now, I'm assuming from the FIXME: that this is an unimplemented piece of wine. Is this saying that gtk can't run with the existing wine threading implementation due to this (and possibly) other functions being buggy/nonexistent? So, the point: what should I do? is this something which will be fixed by someone who knows threading better than I (which is to say almost anyone :))? Does someone know of a workaround that I can use? Is this doomed ==> should I throw in the towel? Thanks, James.

4 10

wxWindows 2.4.0 samples bugs
by Oleg Prokhorov 23 Feb '03

23 Feb '03

Hello, I've found that wxWindows 2.4.0 samples shows a lot of visual bugs/glitches in wine. For example, Dialog sample opens without menu. menu shows on window size change Is anybody going to fix them or at least categorize all of them ? -- Best regards, Oleg mailto:xolegpro@rbcmail.ru

2 1

Unknown message
by Waldeck Schutzer 23 Feb '03

23 Feb '03

When I fireup Xmpeg, I get lots of these errors: err:tooltips:TOOLTIPS_WindowProc unknown msg 0420 wp=00000001 lp=004894f0 Does anyone know that message code 0420 is? Best, Waldeck

2 1

Re: SMATCH: missing LeaveCriticalSection in error path
by Dmitry Timoshkov 23 Feb '03

23 Feb '03

"Michael Stefaniuc" <mstefani(a)redhat.de> wrote: > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > - add missing LeaveCriticalSection's in error path. Michael, I'm just curious, how hard it would be to adapt your SMATCH script for finding EnterCriticalSection/LeaveCriticalSection pair matching to do a similar work with wine_tsx11_lock/wine_tsx11_unlock, GDI_GetObjPtr/GDI_ReleaseObj, DC_GetDC[Ptr|Update]/GDI_ReleaseObj, USER_Lock/USER_Unlock, WIN_GetPtr/WIN_ReleasePtr, WIN_FindWndPtr/ WIN_ReleaseWndPtr and some other internal Wine locks? -- Dmitry.

2 1

CreateProcess + STARTF_USESTDHANDLES
by Oleg Prokhorov 23 Feb '03

23 Feb '03

Hello , This bug occurs to chess.net client application and may be some others. I've debugged a problem with CreateProcess where parent process overrides child process' stdin, stderr, stdout handles. It can be done like this (portion of a code) // Override siStartInfo.dwFlags = STARTF_USESTDHANDLES; // Create the child process. if (!CreateProcess("child.exe", "child.exe", // command line NULL, // process security attributes NULL, // primary thread security attributes TRUE, // handles are inherited DETACHED_PROCESS, // creation flags NULL, // use parent's environment NULL, // use parent's current directory &siStartInfo, // STARTUPINFO pointer &piProcInfo)) // receives PROCESS_INFORMATION ErrorExit("Create process failed"); The bug in Wine is the following lines of scheduler/process.c else if (!(main_create_flags & (DETACHED_PROCESS|CREATE_NEW_CONSOLE))) { SetStdHandle( STD_INPUT_HANDLE, current_startupinfo.hStdInput ); SetStdHandle( STD_OUTPUT_HANDLE, current_startupinfo.hStdOutput ); SetStdHandle( STD_ERROR_HANDLE, current_startupinfo.hStdError ); } You see it does not allow any std handles overriding if main_create_flags' DETACHED_PROCESS or CREATE_NEW_CONSOLE bit is set on, which is partially wrong in Windows. Cause it doesn't take in account siStartInfo.dwFlags=STARTF_USESTDHANDLES, which requires overriding. The full proof of a bug is included, test it on Windows. It may be used as on of wine tests, if you need that. The bug seems to be easy to fix but to the wine server / client process creation insider. I'm not sure what will be better to you fix it yourself, or guide me how to do it in the most proper way. -- Best regards, Oleg mailto:xolegpro@rbcmail.ru

2 1

Wineconf 2003
by Jeremy White 23 Feb '03

23 Feb '03

Okay, folks, I think we should have a Wineconf, and I think it should be in conjunction with LinuxTag in 2003. However, I am too swamped to arrange a conference in Germany. Further, Dan, who was kindly following this up, can't make it to Germany in July (congrats, btw, Dan <g>). So, while he started a conversation with the Linuxtag folks, and while they were willing to help out, we really need someone to pick up the ball and run with this. I think we really need someone in Europe. Could someone please volunteer to take responsibility for making this happen? Here's the threat: unless someone steps up and volunteers to drive this process, I will hold it in Minneapolis/St. Paul, and I'll try to pick the coldest and nastiest month to do it <grin>. Cheers, Jeremy

2 1

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 23 Feb '03

23 Feb '03

Here's a sample app and library that uses a couple of __thread variables in a manner similar to OpenGL. I'd appreciate it if someone could take a look and explain what I'm doing incorrectly, as I've declared the variables as LE and yet seem to be getting IE. Note that I'm away from home and don't have a system that I can actually run this app on, so it may very well be completely broken. Thanks! -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Alexandre Julliard [mailto:julliard@winehq.com] wrote: > > There are no more guarantees with the GDI area than with anything > else. Microsoft is free to change that whenever they feel like it. > > Negative offsets could work, but they would waste a full page of > memory for each thread since the TEB has to be page-aligned. I'd > stronly recommend finding a way to use the glibc threading support > instead. As I keep saying, we need a solution that works on platforms that don't support __thread. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

3 3

HTMLHelp Setup
by Gerhard W. Gruber 22 Feb '03

22 Feb '03

I tried to run the html help setup programm I downloaded from MS website. When I launch it I get an error msg missing w95inf32.dll. When I copy this over from the original windows installation w95inf16.dll is also missing. I copied this also over then then I get an erro message after unpacking saying: Incorrect INF file syntax in section 'HHWDestinationDir ; Ask user for custom destination' Now I'd like to know: Are there any replacements planned/available for the w95inf dlls? Any idea whats wrong with the INF file? The only fixme that I get is about CreateProcess so I don't think that this is it, or could it? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

1 0

HTMLHelp Setup
by Gerhard W. Gruber 22 Feb '03

22 Feb '03

I tried to run the html help setup programm I downloaded from MS website. When I launch it I get an error msg missing w95inf32.dll. When I copy this over from the original windows installation w95inf16.dll is also missing. I copied this also over then then I get an erro message after unpacking saying: Incorrect INF file syntax in section 'HHWDestinationDir ; Ask user for custom destination' Now I'd like to know: Are there any replacements planned/available for the w95inf dlls? Any idea whats wrong with the INF file? The only fixme that I get is about CreateProcess so I don't think that this is it, or could it? -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)

1 0

Setupapi and Mingw
by Steven Edwards 22 Feb '03

22 Feb '03

Hola, Now that ReactOS is having some luck loading device drivers we are going to need a easy way to load inf scripts for the registry information. I have been testing building setupapi under mingw and am getting the following error. Info: resolving _wine_ldt_copy by linking to __imp__wine_ldt_copy (auto-import) fu000001.o(.idata$3+0xc): undefined reference to `libwine_a_iname' nmth000000.o(.idata$4+0x0): undefined reference to `_nm__wine_ldt_copy' E:\users\steven\mingw\bin\dllwrap.exe: E:\users\steven\mingw\bin\gcc exited with status 1 make: *** [setupapi.dll] Error 1 I have been looking at Jeroen Janssen's wine_ldt_copy importing on cygwin patch but havent had any luck. Anyone have any ideas? Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/

2 2

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Alexandre Julliard wrote: > > This is not something we can guarantee. The layout of the thread > structure in Wine is defined by Microsoft, and it's very possible that > they will use these fields someday for something that we need to > emulate. What about the area currently used for GDI? One other method could be to have space at a negative offset from %fs reserved for OpenGL, similar to what the IA32 implementation of NTPL does in Variant II of its design. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

Fix to allow running msvc from commandline in linux
by Dan Kegel 22 Feb '03

22 Feb '03

Changelog: programs/wcmd/wcmdmain.c: make 'cmd /c cl /MUMBLE foo.c' pass /MUMBLE to cl LGPL. ------- Here's how I use msvc's compiler from the Linux shell. In ~/bin create the following three files: --- cl --- wine wcmd /c F:/bin/cl.bat "$@" --- cl.bat --- call F:/bin/vcvars32.bat cl %1 %2 %3 %4 %5 --- vcvars32.bat --- (same as one installed by msvc elsewhere, but with quotes removed -- wcmd doesn't deal well with quotes. Hopefully wcmd will be fixed soon, or is already fixed, to handle quotes properly.) Then you can just build demo programs under MSVC by saying cl foo.c in bash. This is handy for checking portability of wine conformance tests. Unfortunately, you can't pass options to cl, e.g. cl /DSTANDALONE foo.c without the attached patch. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: programs/wcmd/wcmdmain.c =================================================================== RCS file: /home/wine/wine/programs/wcmd/wcmdmain.c,v retrieving revision 1.22 diff -u -p -r1.22 wcmdmain.c --- programs/wcmd/wcmdmain.c 11 Feb 2003 22:01:11 -0000 1.22 +++ programs/wcmd/wcmdmain.c 22 Feb 2003 19:37:48 -0000 @@ -56,14 +56,14 @@ HANDLE h; args[0] = param[0] = '\0'; if (argc > 1) { - for (i=1; i<argc; i++) { - if (argv[i][0] == '/') { + /* interpreter options must come before the command to execute. + * Any options after the command are command options, not interpreter options. + */ + for (i=1; i<argc && argv[i][0] == '/'; i++) strcat (args, argv[i]); - } - else { + for (; i<argc; i++) { strcat (param, argv[i]); strcat (param, " "); - } } }

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Dan Kegel wrote: > > OK, "all new platforms". Sounds like a good argument for tagging > along with glibc's __thread variable support, if you ask me. We still have to support all older platforms as well. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Dan Kegel wrote: > > Sure, but it doesn't have to be as blazingly fast on old platforms. Actually, yes it does. > And, practically speaking, what you're looking for > might in fact only be possible using the new glibc > stuff; as Alexander said, Wine might be forced > to break any constraint you try to get them to agree to. Negative offsets from %fs would avoid any overlap. Perhaps that would be a better solution. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Jakub Jelinek wrote: > > What actually matters is the size of PT_TLS segment of the shared library > which defines those 2-3 __thread variables (I assume it is libGL.so, > right?). Generally, yes. > It would be good if the rest of __thread variables which aren't > performance critical is provided by some other library (and accessed > always through GD or LD model). I guess it would be possible to have non-critical variables defined in the driver backend, say. > Forgot to say, the offsets are obviously constant (until you dlclose the > library which declares them). > If they weren't, one couldn't keep pointers to __thread variables around > in IE/LE models. The variables could move in the dynamic case, hence the function call to get their address. We're trying to avoid that, obviously :-) -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Jakub Jelinek wrote: > > > I'm pretty sure all implementations of OpenGL are not compiled as PIC at > > this point in time. > > AFAIK on x86 only, but it is wrong everywhere. Can you elaborate? > On x86, ld supports Local Exec model in shared libraries (while for most > other targets it does not). R_386_TLS_LE relocation is simply during > -shared linking changed into R_386_TLS_TPOFF dynamic relocation (the same > as is used for IE model, but there this reloc is against .got section > while for LE it is against text section). To be clear, are you saying that even if you declare a variable as LE, once you link the relevant code into a shared library it is changed to IE? > So, if you don't use -fpic anyway, you can just use LE model on IA-32, > if you finally change it so that -fpic is used for the whole library, > then those functions (or assembly stubs) can be put into > some SHF_ALLOC|SHF_WRITE|SHF_EXECINSTR section. If we don't use PIC, do we always get LE if we declare a variable as LE? > Which means you should use the default -ftls-model and use > __attribute__((tls_model("initial-exec"))) or > __attribute__((tls_model("local-exec"))) > for the variables which are really performance critical. Yes, that would be the plan. > On IA-32, you can use > __asm ("jmp 1f; .section writetext, \"awx\"; 1: movl > $foo@ntpoff, %0; jmp 2f; .previous; 2:" : "=r" (foo_offset)); > to query some variable's offset which you can later on use with: > __asm ("movl %gs:0(%1), %0" : "=r" (foo_value) : "r" (foo_offset)); > Please do something like this only for runtime generated code, not for > anything else. Of course, silly me. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

1 0

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Dan Kegel wrote: > > If it turns out glibc's new __thread variable support really can do what > you need on all platforms, do you agree that it might be better to use > that? Insert the word "new" between "all" and "platforms", and maybe you'll have more of an appreciation for my point of view :-) > Which platforms are those? I didn't see this in your previous email. How about basically every IA32 Linux installation out there (or, at the very least, those that are currently supported by our drivers)? How many people are actually using systems that have full support for __thread? As I understand it, RedHat 8.1 will be the first large-scale release that does. -- Gareth

2 1

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Daniel Jacobowitz wrote: > > Note the "always" in Roland's paragraph. Note the fact that he said it would require one of the dynamic access models (GD or LD), which require at least one function call to access thread local variables. As I've said, this is an unacceptable hit on performance. > When you say two or three, are these two or three pointers or two or > three large tables? Two or three pointers. I'm pretty sure we use less than 8 pointers all up, although many of those aren't performance critical. Three of ours most definitely are, and it would be nice if moving to a couple more didn't break things. We only ever use thread-local pointers, never whole structs or anything like that. > In any case, it sounds like you could: > - select the thread-local variables that you need fast access to > - Arrange for those variables to be tagged with an > __attribute__((tls_model("initial-exec"))), or something similar. > - Make sure the TLS_STATIC_SURPLUS is big enough to hold them. Will this be okay, considering that two shared libraries will need access to the variables (libGL.so itself and the driver backend)? Can you use IE or LE with variables that live in another shared library? > I don't see a problem, but you'd have to do some serious reading of the > TLS ABI documents.... they're quite thorough. Sure, the code itself isn't hard to understand. The problem is, at runtime, how do I know what code to generate to access a given __thread variable? Do I have do disassemble a function that accesses the variable to know the right model to use? Fixed offsets make this trivial, but maybe this isn't a real problem after all. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

wine-patches broken?
by Stefan Leichter 22 Feb '03

22 Feb '03

Hello, since Thursday i have tried two times to send a mail to wine-patches but the mails does not show up there. I have also check the archive on winehq. The mails are not in. To check the mail account i have send the last mail to another email address of me, where it was received. Anyone else have this problem? There are two special things on my email account that may trigger the problem: * the email address used for posting has mail delivery disables for the mailing lists wine-patches and wine-devel. * the domain the mails are send (t-online.de) do not match the domain of the email address. This causes sometimes problems with spamfilers, abuse ... Bye Stefan

1 0

Re: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Roland McGrath wrote: > > These people clearly haven't read all of the TLS paper, or looked at the > GCC implementation of __thread long enough to notice -ftls-model and > __attribute__ ((tls_model)). This is what I was talking about. I've read the entire document several times, and still can't see a way that a dynamically loadable shared library can be guaranteed to use the single-instruction Local Exec access model. If I'm wrong, please explain why. > I think the TLS document intends to explain what the models mean in > practical terms on each architecture, but I can believe it's not all > that clear. The GCC manual doesn't explain the access models and code > sequences, just tells you how to tell the compiler what you want in the > terms that the TLS document defines. > > If you want maximal flexibility, i.e. to always work with dlopen, then > indeed you must use the "dynamic" TLS access models (GD or LD). You can > use the Initial Exec model if you want faster accesses at the cost of some > flexibility. libGL.so simply has to work with dlopen -- if for no other reason than essentially all major 3D games (Quake3, Doom3, UT2003 etc) dlopen libGL.so rather than linking with it. This is not going to change. > When compiling PIC, IE-model accesses have one additional indirection, > i.e. loading the offset from the GOT just as the address of a global > variable is loaded in PIC. See the instruction sequences in the TLS spec. I'm pretty sure all implementations of OpenGL are not compiled as PIC at this point in time. That's a whole other discussion, however. > If you use static linking, these instruction sequences reduce to constants > at link time (i.e. direct "%gs:NNN" accesses on x86). Can you describe how I could use static linking here? As I said, libGL.so must be a dynamically loadable shared library. What we want is the single-instruction Local Exec access model. At this point in time, my understanding of the situation is that these are mutually exclusive requirements. > If you link a shared object containing IE-model access relocs, the object > will have the DF_STATIC_TLS flag set. By the spec, this means that dlopen > might refuse to load it. As I said, not being able to dlopen libGL.so is unacceptable. > In glibc, we actually allocate some excess space in the thread-local > storage area layout determined at startup time. This lets a dynamically > loaded module use static TLS if its PT_TLS segment fits in the available > surplus. (In sysdeps/generic/dl-tls.c, see TLS_STATIC_SURPLUS.) If there > is insufficient space preallocated, then loading the module will fail. In > fact, we put this feature there with GL in mind and can adjust the > preallocated surplus for what is most useful in practice. I think the set of performance critical thread-local variables is something like two or three (depending on the implementation). The libGL.so API dispatcher needs fast access to one or two of these (dispatch table pointers), while the driver backend needs fast access to all of them (context pointer and dispatch table pointers). The other thread-local variables are generally not accessed in performance-critical situations. Another issue I forgot to mention, or forgot to make clear, is that we need to be able to access these thread-local variables in runtime generated code. A driver's top-level API functions are often generated at runtime, and need to be able to do things like switch dispatch tables (obviously, they'd have direct access to the context they were associated with, and so wouldn't need to go through the pointer in TLS). Are we guaranteed that the __thread variables aren't going to move around? How would we work out what code to generate to access a given __thread variable? (I've included both phil-list and wine-devel, if you'd like this discussion kept to one or other of these lists, please say so). -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

3 2

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

Dan Kegel wrote: > > It does look like the TLS model does what you want it to, > and no new methods are needed. Can you explain in more detail > why your new proposal is needed, if you still think it is? To be clear, what I'm proposing requires ZERO code changes to Wine and glibc. It will work today, with Wine implementations already in the field. All I'm proposing we do is make sure it continues to work in the future, irrespective of the decision made regarding the use of glibc's new __thread variable support. As I said in my last email, there are some unresolved issues with using __thread variables: 1) We need fast TLS access on platforms where __thread variables are not supported. 2) libGL.so must be able to be dynamically loaded. Failing to dlopen libGL.so will, at the very least, make the entire Linux gaming community very unhappy :-) 3) It is unclear how online generated code can interact with __thread variables. Perhaps this is simpler than I think... -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

3 2

wcmd/wine default window configuration
by J. Grant 22 Feb '03

22 Feb '03

Hello I have been using wcmd lately, its been really useful to my research. However, could wcmd default to its "command history" (a la doskey) value to something other than zero please? Perhaps 50 would be enough, it would not take up much memory for the queue strcture I think. I do not know if this is wcmd, but the wcmd context menu uses a serif font. I think in UI design serif is not a good choice... most programs use a sans serif one, such as the widget in wcmd->propeties. Sans serif is generally accepted as more appealing in most contexts. It would be great if the wcmd text area was bigger too, current it starts as 80x25, however, if I change it to 80x80 in the wcmd prefs (then resize the window, as it does not auto adjust) and type "dir" the same top 80x25 chars are the only ones used to display text. I ran cmd.exe from within wcmd and the same problem showed up. So it appears that its either the way Wine displays windows, or wcmd. I tried "wineconsole ./cmd.exe" too, that locked up my terminal with lots of NCURSES fixme printf's. cmd.exe in MS-Windows is resizable vertically, and the extra lines are used. Regards JG

3 6

Fast thread-local storage for OpenGL drivers
by Gareth Hughes 22 Feb '03

22 Feb '03

It is critically important for OpenGL drivers to have fast (single-instruction) access to thread local variables. I'd be happy to provide more information to anyone who's interested, but a typical case where TLS access can severely hurt performance is at the very front-end of an OpenGL library. Ideally, you'd like something like the following: libGL.so: // This function loads a dispatch table pointer from // thread-local storage and jumps through to the // backend function (which typically resides in a // different shared library). glTexCoord2f: mov %fs:DISPATCH_TABLE_OFFSET, %eax jmp *__glapi_TexCoord2f(%eax) // Points to __my_TexCoord2f libGLcore.so: // This function copies some data into the OpenGL // context, sets some magic flags to record what data // was copied, and returns. __my_TexCoord2f: mov %fs:CONTEXT_OFFSET, %eax // Copy 2 floats into the context // Set a flag ret All in all, you have 2 TLS accesses in less than 10 instructions or so. Even if you don't understand exactly what's going on here, you can see that it is important to have fast access to thread-local data. While glibc's new thread library implementation has many benefits, particularly to application programmers (with support for the new keyword '__thread', and so on), it basically forces a function call per thread local variable access for situations like the one I described above. This is clearly unacceptable for a high-performance OpenGL driver. Furthermore, the glibc developers have been completely unwilling to work with OpenGL driver developers (Open Source or otherwise) to provide a mechanism to access thread-local data in a way that meets our performance requirements. Therefore, I'd like to propose a solution where Wine and the OpenGL driver cooperate to provide such a TLS access mechanism (at least on x86 platforms). Wine currently uses %fs to access the Windows Thread Environment Block (TEB), while glibc uses %gs to access its per-thread data. With the following patch to Wine's TEB structure: --- include/thread.h 2002-12-17 16:06:25.000000000 -0500 +++ include/thread.h.new 2003-02-21 14:27:50.000000000 -0500 @@ -116,10 +116,12 @@ DWORD alarms; /* --3 22c Data for vm86 mode */ DWORD vm86_pending; /* --3 230 Data for vm86 mode */ void *vm86_ptr; /* --3 234 Data for vm86 mode */ + /* here is plenty space for wine specific fields (don't forget to change pad6!!) */ + DWORD pad6[608]; /* --n 238 */ + DWORD ogl_data[16]; /* --n bb8 OpenGL driver private data */ /* the following are nt specific fields */ - DWORD pad6[624]; /* --n 238 */ UNICODE_STRING StaticUnicodeString; /* -2- bf8 used by advapi32 */ USHORT StaticUnicodeBuffer[261]; /* -2- c00 used by advapi32 */ void *stack_base; /* -2- e0c Base of the stack */ we reserve %fs:0xbb8 to %fs:0xbf8 for use by the OpenGL driver. Any and all OpenGL implementations can use this area, and we agree that when Wine is present, it leaves this area untouched. The question of who allocates the TEB should be pretty straight forward: when an OpenGL driver is first loaded, if the TEB is missing it is allocated as expected. I would imagine when Wine is running that it would have the chance to allocate the TEB before the OpenGL driver is loaded, and thus the OpenGL driver wouldn't have to do anything. The size of the reserved area should be sufficient, although we can debate that if required. Comments, questions are welcome. I've CC'ed Brian Paul and Keith Whitwell of Mesa/DRI fame, as I know they are interested in this issue. Please CC us on any replies, as we are not subscribed to the list. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel