February 2003 - Wine-devel - list.winehq.org

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

wcmd mark/paste
by J. Grant 22 Feb '03

22 Feb '03

Hi, wcmd mark/paste has greatly improved since the last version, the current CVS feels very good so far. However, to copy text it is still not possible to drag over the text as in other X apps. In fact even if Context menu->Edit->Mark is selected it is necessary to use the keyboard to increase the selection area. This is not very quick because keyboard repeat is not used, so I have to hammer my arrow keys like I am playing an old Atari game! (perhaps related to the other X11 Clipboard thread currently) I'm glad to see the copied text is not corrupted anymore The wine debugger also exhibits this problem. The "quick edit" functionality is great, however I am still getting an extra date column on the right of my pastes when typing "dir" (date column is on the left of dir output). Regards JG

4 7

Building WinMM on mingw
by Steven Edwards 22 Feb '03

22 Feb '03

I think the export in ntdll may be wrong playsound.o(.text+0x7d7): In function `PlaySound_Alloc': e:/users/steven/source/wine/dlls/winmm/playsound.c:222: undefined reference to `RtlCreateUnicodeStringFromAsciiz(a)8' E:\users\steven\mingw\bin\dllwrap.exe: E:\users\steven\mingw\bin\gcc exited with status 1 make: *** [winmm.dll] Error 1 Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/

2 1

registry patch
by Matthieu Foillard 22 Feb '03

22 Feb '03

Hi, this fix a bug when data is null. (3dsmax v3 now works with this) Note that i'm not a wine developper and this patch might not be the right way to fix the problem. Someone on #winehq told me this is acceptable so... Index: dlls/advapi32/registry.c =================================================================== RCS file: /home/wine/wine/dlls/advapi32/registry.c,v retrieving revision 1.50 diff -u -3 -p -r1.50 registry.c --- dlls/advapi32/registry.c 20 Jan 2003 23:23:12 -0000 1.50 +++ dlls/advapi32/registry.c 14 Feb 2003 22:49:13 -0000 @@ -902,7 +902,7 @@ DWORD WINAPI RegSetValueExA( HKEY hkey, if (!is_version_nt()) /* win95 */ { - if (type == REG_SZ) count = strlen(data) + 1; + if (type == REG_SZ && data != NULL) count = strlen(data) + 1; } else if (count && is_string(type)) { -- Matthieu Foillard <m.foillard(a)taktile.com> tel : 0146090496 - gsm : 0686574170 pgp : 0x1609654F

2 1

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

21 Feb '03

> - wwo->mapping = mmap(NULL, wwo->maplen, PROT_WRITE, MAP_SHARED, > - wwo->ossdev->fd, 0); > + wwo->mapping = mmap(NULL, wwo->maplen, > +#if (defined(__FreeBSD__) && (__FreeBSD_version < 500000)) > + PROT_READ|PROT_WRITE, > +#else > + PROT_WRITE, > +#endif > + MAP_SHARED, wwo->ossdev->fd, 0); hmm this type of coding isn't really a great idea... do you really know what's behind this mmap issue not being possible ? I don't know how OSS will handle it on BSD: Linux semantics are: if the device has been mapped as read only, then assume the mapping is for ouput, otherwise assume it's for capture I don't know what BSD is going to do in this case > +#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 A+ -- Eric Pouech

1 0

Re: Wine 0.9 config applets?
by Jeff Smith 21 Feb '03

21 Feb '03

>From: Mike Hearn <m.hearn(a)signal.qinetiq.com> >Hmmm, do we even have a control panel? Presumably programs can install >control applets (capplets in gnome-speak), but I don't see any way to >see them other than executing the cpl files manually. Try 'wine control'. That is our winelib control panel app if I am not mistaken. -- Jeff S _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

4 3

Thomas Brothers Digital Edition?
by Dan Kegel 21 Feb '03

21 Feb '03

Has anyone tried to run the "Thomas Brothers Digital Edition" aka "Thomas Brothers DE 4.0" mapping software under Wine? http://www.thomas.com/prod/ (Anyone who lives in Los Angeles and has a car has a copy of the printed Thomas Brothers map; this is their digital equivalent.) A local businessman I know wants to switch his PCs to Linux, and this is one of the apps he requires. It's only $30, so I'll probably get a copy just to see, but I thought I'd ask here first. Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Music font problem
by Andrew Johnson 21 Feb '03

21 Feb '03

I originally posted this to comp.emulators.ms-windows.wine, where it was suggested I send a copy here. Please CC: replies to me as I'm not subscribed to wine-devel. TIA! I have been using a shareware program called Noteworthy Composer for many years on Windows, but am trying to switch to a Linux-only setup and this is one the last obstacles. I don't want to switch to the other Linux music programs as to my mind they don't provide as simple an interface as NWC does, and I already have many song files in the NWC format. The main problem with running this is that it uses its own TrueType Font, which doesn't display properly under Wine - I just get outline boxes instead of the note symbols. Here's how I got to where I am right now: I tried various RPM versions of wine on my RH8.0 system, and finally downloaded the Wine source and did a cvs update and build about a week ago. The first problem was that I was using a fake C drive and the NWCV15.TTF font was the only one found, and was being used for all text including menus & dialog boxes - this just doesn't make sense, the NWCV15 font is analagous to a symbol font and doesn't have text characters, so everything came out totally illegible, although recognizable enough to see that it was mostly working. I installed a few standard TTF fonts in the windows\Fonts directory to fix that, but then the program wouldn't start, complaining that it couldn't find its special font NWCV15.ttf, which had been correctly installed in the C:\Windows\Fonts directory. I ran wine with --debugmsg +font and added a few more TRACE() statements to dlls/gdi/freetype.c, and discovered that the font was being ignored by Wine because the program doesn't specify SYMBOL_CHARSET when requesting the font; Windows finds the font but Wine doesn't. There is a specific check in the routine WineEngCreateFontInstance to compare the font name requested with "Symbol" and in that case to set the charset being searched for to SYMBOL_CHARSET. When I add similar code for the font name "NWCV15" the program now starts up and finds its font, but doesn't display it correctly. My change is obviously highly specific to running this program, so there's obviously a significant algorithm difference between Wine and Windows when it comes to font selection of SYMBOL_CHARSET fonts. Now I can read the dialogs properly and the program runs pretty well (it even plays MIDI stuff properly after I installed the ALSA drivers from source - cool), but the score display is still only only showing boxes instead of the note heads and other symbols that appear in that font. The font file does show various expected glyphs if I install it in the xfs truetype directory and look at it using xfontsel, but I don't know of any other Linux tools for analysing .ttf files. Can anyone suggest what I should do next to try and get the NWCV15 font displaying properly? This is obviously an unusual font but I'm not sure whether that's causing the problems or not. Ideas? If anyone wants to have a look at the font file for themselves, free evaluation copies of the software can be obtained from http://www.noteworthysoftware.com/composer/download.htm - Andrew PS: Thanks to all the Wine developers for making this feat achievable, it amazes me how well it all works!

3 5