- Wine-Devel - list.winehq.org

How Thread Local Storage works in WIN32 and in Visual C++
by Jonathan Wilson Aug. 19, 2003

Aug. 19, 2003

This is information I have figured out and found out about how Thread Local Storage (that is, variables declared with __declspec(thread)) works in Win32 from the perspective of the exe file (as opposed to the perspective of the kernel). I am posting this to the ReactOS list since it needs support for this in its kernel code. I am posting this to the WINE list since it also should support this from a kernel point of view. Plus it should (ideally) support __declspec(thread) in WineGCC at some point if that is possible I am posting this to the MingW list since MingW needs __declspec(thread) support. First, TLS in visual C++ relies on: 1.the __declspec(thread) keyword & some special stuff the compiler does when accessing TLS variables 2.the .tls segment in the PE file 3.the IMAGE_TLS_DIRECTORY32 structure (pointed at by a field in the PE header and stored in the read only data segment) and the things it points at (specificly the TlsStart, TlsEnd and TlsIndex variables) TlsIndex is stored in the read/write data segment Tls 4.the tlssup.obj file (which is inside the Visual C++ runtime library .lib files like libc.lib and msvcrt.lib) and 5.a linker feature that will combine segments in a special way if they are named right (for example, .tls will be written first, then anything labeled .tls$ then .tls$zzz. All of them will be combined into one segment labeled .tls) Firstly, when you declare a variable as __declspec(thread), the compiler accesses it a special way. It takes the current value in the TlsIndex variable. Then it takes the value stored at offset 2C in the TEB (which contains the pointer to the TLS data area for that thread) it then does TlsPointer + TlsIndex * 4. This is what it uses when it reads and writes from Thread Local Storage variables. The first variable seems to be stored at (this address) + 4 then + 8 and so on. at (this address) is the _tls_start variable as explained below) Also, when you declare a __declspec(thread) variable, its put into the obj file inside the .tls$ segment. Most of the magic happens inside the linker. First, lets explain tlssup.obj This contains an item called __tls_used that resides in the read only data segment which then becomes the TLS directory pointed at by the PE header. This points at __tls_start which is in the .tls segment, __tls_end which is in the .tls$zzz segment and __tls_index which is in the read write data segment There is also ___xl_a and ___xl_z, ___xl_a is pointed to by the thread callbacks pointer. So, what we have in the resulting exe file is: the __tls_used variable in the read only data segment the __tls_index variable in the read write data segment and the .tls segment containing: __tls_start //all the user declared __declspec(thread) variables __tls_end And we also have ___xl_a followed by calls to the thread callback functions folowed by ___xl_z So, basicly, to implement TLS in compilers, we need to: 1.make __declspec(thread) point at the thread local storage and get the compiler to access these variables correctly. 2.make the variables all end up in the correct place in the exe file with the TLS directory pointing at the start and end of the list 3.write the needed support code for the RTL (as needed) 4.make the callbacks (if needed) get generated & output to the exe file properly and 5.make sure that the PE header points to the TLS directory. If anyone has anything to add or wants more details, do reply As for kernel-mode support in ReactOS or whatever, that seems easy enough to implement, anyone wanna have a go?

1 0

How Thread Local Storage works in WIN32 and in Visual C++
by Jonathan Wilson Aug. 19, 2003

Aug. 19, 2003

This is information I have figured out and found out about how Thread Local Storage (that is, variables declared with __declspec(thread)) works in Win32 from the perspective of the exe file (as opposed to the perspective of the kernel). I am posting this to the ReactOS list since it needs support for this in its kernel code. I am posting this to the WINE list since it also should support this from a kernel point of view. Plus it should (ideally) support __declspec(thread) in WineGCC at some point if that is possible I am posting this to the MingW list since MingW needs __declspec(thread) support. First, TLS in visual C++ relies on: 1.the __declspec(thread) keyword & some special stuff the compiler does when accessing TLS variables 2.the .tls segment in the PE file 3.the IMAGE_TLS_DIRECTORY32 structure (pointed at by a field in the PE header and stored in the read only data segment) and the things it points at (specificly the TlsStart, TlsEnd and TlsIndex variables) TlsIndex is stored in the read/write data segment Tls 4.the tlssup.obj file (which is inside the Visual C++ runtime library .lib files like libc.lib and msvcrt.lib) and 5.a linker feature that will combine segments in a special way if they are named right (for example, .tls will be written first, then anything labeled .tls$ then .tls$zzz. All of them will be combined into one segment labeled .tls) Firstly, when you declare a variable as __declspec(thread), the compiler accesses it a special way. It takes the current value in the TlsIndex variable. Then it takes the value stored at offset 2C in the TEB (which contains the pointer to the TLS data area for that thread) it then does TlsPointer + TlsIndex * 4. This is what it uses when it reads and writes from Thread Local Storage variables. The first variable seems to be stored at (this address) + 4 then + 8 and so on. at (this address) is the _tls_start variable as explained below) Also, when you declare a __declspec(thread) variable, its put into the obj file inside the .tls$ segment. Most of the magic happens inside the linker. First, lets explain tlssup.obj This contains an item called __tls_used that resides in the read only data segment which then becomes the TLS directory pointed at by the PE header. This points at __tls_start which is in the .tls segment, __tls_end which is in the .tls$zzz segment and __tls_index which is in the read write data segment There is also ___xl_a and ___xl_z, ___xl_a is pointed to by the thread callbacks pointer. So, what we have in the resulting exe file is: the __tls_used variable in the read only data segment the __tls_index variable in the read write data segment and the .tls segment containing: __tls_start //all the user declared __declspec(thread) variables __tls_end And we also have ___xl_a followed by calls to the thread callback functions folowed by ___xl_z So, basicly, to implement TLS in compilers, we need to: 1.make __declspec(thread) point at the thread local storage and get the compiler to access these variables correctly. 2.make the variables all end up in the correct place in the exe file with the TLS directory pointing at the start and end of the list 3.write the needed support code for the RTL (as needed) 4.make the callbacks (if needed) get generated & output to the exe file properly and 5.make sure that the PE header points to the TLS directory. If anyone has anything to add or wants more details, do reply :) As for kernel-mode support in ReactOS or whatever, that seems easy enough to implement, anyone wanna have a go?

1 1

Anyone having problems with Alsa ?
by Sylvain Petreolle Aug. 19, 2003

Aug. 19, 2003

After upgrading my alsa drivers from 0.9.4 to 0.9.6, the wine alsa driver isnt working anymore on my system. Sound is working when I use the OSS emulation with wineoss.drv. But if i use winealsa.drv, many winmm tests fail. (I attached the log) ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 alias upsf='false ; while [ $? -ne 0 ] ; do cvs update -APd ; done 2>&1 |tee cvslog' "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: Int21 : Dont reset systematically CFLAG
by Jukka Heinonen Aug. 19, 2003

Aug. 19, 2003

Sylvain Petreolle wrote: > Dont reset systematically CFLAG when calling the int 21 handler. > Some functions dont change it. This patch must not be applied because it is highly likely that it will break almost all DOS programs. Fix itself is correct but before this patch can be applied it must be made sure that all functions that are supposed to reset CFLAG really reset it. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

Re: Implement registry key unloading
by Steven Edwards Aug. 18, 2003

Aug. 18, 2003

> ChangeLog: > * Implement registry key unloading Speaking of the registry if you guys are interested in implementing a faster binary format for the registry take a look at what we have done in ReactOS. Eric Kohl has offered to license his work as LGPL if you guys want to try to move to the same format we use. It should be much faster then the existing system currently in WINE. Now that we have a GUI regedit for WINE and ReactOS once write support is implemented then it might be a good idea to implement this. Thanks Steven

1 0

Re: some questions (required for my dmusic work)
by John K. Hohm Aug. 18, 2003

Aug. 18, 2003

> 2. I still can't figure how to implement interface that consist of two > interfaces (I have IDirectMusicLoaderStream which should consist of > IStream and IDirectMusicGetLoader). Can someone send me detailed > instructions how to do it? (I can't find any examples) I think what you want to do is implement two interfaces in one object, which is a bit different than putting two interfaces in one interface (every interface has IUnknown in it). For an example, see the implementation of the StdComponentCategoriesMgr in dlls/comcat, which might be slightly unusual because there is just one static instance rather than potentially many dynamically created instances. The implementation is broken down like this: comcat_private.h declaration of ComCatMgrImpl struct with three Vtbl pointers manager.c implementation of IUnknown, used by other interface impls too, and static ComCatMgrImpl instance, would normally be alloc'd and init'd information.c implementation of ICatInformation, partially forwards to IUnknown register.c implementation of ICatRegister, partially forwards to IUnknown There are probably other examples, but that is one I'm familiar with.

1 0

Re: Re: winevdm: can't exec
by Christian Costa Aug. 18, 2003

Aug. 18, 2003

Hi, What about adding the comment in the code? :-) Bye, Christian Message du 18/08/03 12:05 De : Dmitry Timoshkov A : Dominik Strasser Copie à : wine-patches(a)winehq.com Objet : Re: winevdm: can't exec Hello, Changelog: Windows ignores values of e_cparhdr and e_crlc of the MZ header. --- cvs/hq/wine/loader/module.c Tue Jul 22 01:13:12 2003 +++ wine/loader/module.c Mon Aug 18 09:54:32 2003 @@ -200,10 +200,6 @@ * structure encompasses the "Offset to extended header" * field. */ - if ((header.mz.e_cparhdr << 4) < sizeof(IMAGE_DOS_HEADER)) - return BINARY_DOS; - if (header.mz.e_crlc && (header.mz.e_lfarlc < sizeof(IMAGE_DOS_HEADER))) - return BINARY_DOS; if (header.mz.e_lfanew < sizeof(IMAGE_DOS_HEADER)) return BINARY_DOS; if (SetFilePointer( hfile, header.mz.e_lfanew, NULL, SEEK_SET ) == -1)

1 0

exceptions
by flyker Aug. 18, 2003

Aug. 18, 2003

I use __TRY __EXCEPT defined in <wine/exception.h> but i get error: undefined reference to `__wine_exception_handler(__EXCEPTION_RECORD*, __EXCEPTION_FRAME*, _CONTEXT86*, void*)' what library support this ?

2 1

Compiling winboard (GNU Chess)
by root Aug. 18, 2003

Aug. 18, 2003

Hi everybody, I'm busy with compiling winboard (the win32 version of xboard -- ftp://ftp.gnu.org/pub/gnu/winboard-4_2_6-src.tar.gz ). I made this makefile based on cygwin.mak (included in the source tarball) and I ran into problem. (I changed none of the source files.) The problem is probably one of the wine header files because the compiler gives this output: winegcc -I. -mwindows -mno-cygwin -g -c -o winboard.o winboard.c In file included from /usr/local/include/wine/windows/windows.h:55, from winboard.c:54: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [winboard.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o backend.o backend.c flex -L parser.l cp lex.yy.c parser.c winegcc -I. -mwindows -mno-cygwin -g -c -o parser.o parser.c winegcc -I. -mwindows -mno-cygwin -g -c -o moves.o moves.c winegcc -I. -mwindows -mno-cygwin -g -c -o lists.o lists.c winegcc -I. -mwindows -mno-cygwin -g -c -o gamelist.o gamelist.c winegcc -I. -mwindows -mno-cygwin -g -c -o pgntags.o pgntags.c winegcc -I. -mwindows -mno-cygwin -g -c -o wedittags.o wedittags.c In file included from /usr/local/include/wine/windows/windows.h:55, from wedittags.c:26: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [wedittags.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o wgamelist.o wgamelist.c In file included from /usr/local/include/wine/windows/windows.h:55, from wgamelist.c:26: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [wgamelist.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o zippy.o zippy.c winegcc -I. -mwindows -mno-cygwin -g -c -o wsockerr.o wsockerr.c res --use-temp-file winboard.rc -O coff -o wbres.o make: res: Commando niet gevonden make: [wbres.o] Fout 127 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o wclipbrd.o wclipbrd.c In file included from /usr/local/include/wine/windows/windows.h:55, from wclipbrd.c:26: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [wclipbrd.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -g -c -o woptions.o woptions.c In file included from /usr/local/include/wine/windows/windows.h:55, from woptions.c:26: /usr/local/include/wine/windows/mmsystem.h:69: parse-fout voor stringconstante Error: gcc failed. make: [woptions.o] Fout 2 (genegeerd) winegcc -I. -mwindows -mno-cygwin -mwindows -Xlinker "-e" -Xlinker "_mainCRTStartup" -g -mno-cygwin winboard.o backend.o parser.o moves.o lists.o gamelist.o pgntags.o wedittags.o wgamelist.o zippy.o wsockerr.o wbres.o wclipbrd.o woptions.o \ -lwsock32 -lcomctl32 -lwinmm -lkernel32 \ -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lwinspool \ -o winboard.exe gcc: -e: linker input file unused because linking not done gcc: _mainCRTStartup: linker input file unused because linking not done Error: Can n��lllllll Error: /usr/local/bin/winewrap failed. make: [winboard.exe] Fout 2 (genegeerd) [root(a)erwin winboard]# ock32 -lcomctl32 -lwinmm -lkernel32 \ > -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lwinspool \ > -o winboard.exe bash: ock32: command not found [root(a)erwin winboard]# gcc: -e: linker input file unused because linking not done bash: gcc:: command not found [root(a)erwin winboard]# gcc: _mainCRTStartup: linker input file unused because linking not done bash: gcc:: command not found [root(a)erwin winboard]# Error: Can n��lllllll bash: Error:: command not found [root(a)erwin winboard]# Error: /usr/local/bin/winewrap failed. bash: Error:: command not found [root(a)erwin winboard]# make: [winboard.exe] Fout 2 (genegeerd) As you can clearly see, some of the files compile correctly but 5 files have a problem with a header file called mmsystem.h. If anyone can fix this we have another program for the Fun Projects page :). -- E.C.F. Wolff

1 0

Re: dlopen libncurses.so in wineconsole (take 3)
by Dimitrie O. Paun Aug. 18, 2003

Aug. 18, 2003

On August 14, 2003 10:00 pm, Mike McCormack wrote: > +#ifdef HAVE_NCURSES_H > + char *ncname = SONAME_LIBNCURSES; > +#else > + char *ncname = SONAME_LIBCURSES; > +#endif Since we're doing this dynamically, shouldn't we also determine at runtime if we should use ncurses or curses? It would make a lot more sense, as we typically compile on one box, and run on another... -- Dimi.

2 1