wine-devel August 2003

wine-devel@winehq.org

124 participants
293 discussions

Re: calls to int 3d corrupt the stack
by Jukka Heinonen 19 Aug '03

19 Aug '03

FPU handling got broken over half a year ago when I removed separate interrupt DLL and added support for DPMI32. Interrupt DLL made sure that builtin protected mode interrupt handlers saw regular IRET return record on stack. Current protected mode interrupt code does not provide an IRET record and real mode interrupt code never did provide it. I'm currently working on a two part fix for FPU code: 1. Make sure that DOSRELAY called via RELAY_BuildCallFrame sees original stack and code pointers and can modify them. 2. Make FPU emulation use CS/IP instead of IRET record. Both of these patches are about 10 lines of code so I guess I shall have it fixed within a week, assuming testing patches don't take up too much time. -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

Fw: Fix treeview with checkboxes creation
by Marcelo Duarte 19 Aug '03

19 Aug '03

I think that a comment in the code would have been very good. ;) > ----- Original Message ----- > From: "Dmitry Timoshkov" <dmitry(a)baikal.ru> > To: "Maxime Bellengé" <maxime.bellenge(a)laposte.net> > Cc: <wine-devel(a)winehq.com> > Sent: Monday, August 18, 2003 11:42 PM > Subject: Re: Fix treeview with checkboxes creation > > > > "Maxime Bellengé" <maxime.bellenge(a)laposte.net> wrote: > > > > > - hdc = CreateCompatibleDC(0); > > > - hbm = CreateCompatibleBitmap(hdc, 48, 16); > > > > > > hbm is a 1 bit per pixel bitmap > > > > > > + hdcScreen = CreateDCA("DISPLAY", NULL, NULL, NULL); > > > + > > > + hdc = CreateCompatibleDC(hdcScreen); > > > + hbm = CreateCompatibleBitmap(hdcScreen, 48, 16); > > > > > > hbm has now a screen compliant depth > > > > You are right. Probably it's better to just replace > CreateCompatibleBitmap() > > by CreateBitmap() with the desired number of bits per pixel. In any case > > send what you see more appropriate. > > > > -- > > Dmitry. > > > > > > >

1 0

How Thread Local Storage works in WIN32 and in Visual C++
by Jonathan Wilson 19 Aug '03

19 Aug '03

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 19 Aug '03

19 Aug '03

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 19 Aug '03

19 Aug '03

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 19 Aug '03

19 Aug '03

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 18 Aug '03

18 Aug '03

> 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 18 Aug '03

18 Aug '03

> 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 18 Aug '03

18 Aug '03

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 18 Aug '03

18 Aug '03

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

← Newer
1
...
15
16
17
18
19
20
21
...
30
Older →

Jump to page:

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 August 2003