- Wine-Devel - list.winehq.org

TlsAlloc limitation in winxp mode
by Michael Ost March 19, 2005

March 19, 2005

With the emulation mode set to "winxp" I can only TlsAlloc 64 indexes, even though the MSDN docs say there should be at least 20 million. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba… Has anyone done any work on this? Any workaround/hackarounds? ... mo

3 3

Re: [WINEOSS] use default prepare functions
by Francois Gouget March 18, 2005

March 18, 2005

On Thu, 17 Mar 2005, Robert Reif wrote: > Fall back to default header prepare and unprepare functions. > > A driver only needs to support prepare and unprepare functions > when it is doing something special like allocating a DMA buffer for > each header. Since we don't do anything special, just fall back > to the default functions. Removes redundant code. Does that mean we could do the same wor winealsa, winearts, etc? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

3 4

Re: RICHEDIT: RTF reader i18n (now with font charset support)
by Vitaly Lipatov March 18, 2005

March 18, 2005

В сообщении от 17 Март 2005 13:20 Phil Krylov написал(a): > this patch replaces my precious patch "RICHEDIT: RTF reader i18n" and > needs to be applied after Krzysztof Foltman's "RICHEDIT: RTF reader > improvements and optimizations (TAB craziness fixed)" patch. > > ChangeLog: > > Replaced slow and outdated character set handling in RTF reader by > Unicode/codepages support. Added charset->codepage conversion. Will we do this code in locale independent manner? Why we have ansiCodePage=1252 by default? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Registration of dlls - proposition
by Jacek Caban March 18, 2005

March 18, 2005

Hi, Currently functions Dll[Un]RegisterServer in Wine look strange to me. It's a great code duplication. As we have ATLRegistrar implementation right now it can be changed. We can use ATL to register dlls. This way functions Dll[Un]RegisterServer can be really simple and registry can be described by elastic and simple rgs scripts. You can see example of rgs script here: http://cvs.winehq.org/cvsweb/wine/dlls/atl/atl.rgs?rev=1.2&content-type=tex… and documentation of ATLRegistrar here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/ht… There are two more aspects of this solution: - dependence on atl I don't think it's a true problem as we can create ATLRegistrar by CoCreateInstance and finally we depend on atl _only_ while registering, so it's not a great dependency... - header file We would need to make atliface.idl accessible for other dlls. Actually it is a public ATL header file, so there is nothing wrong in doing this. We could just move it to include/ (or maybe include/atl where, in future, more headers of ATL could be placed). The benefit is: no code duplication, more elastic and clean registration code. What do you think? Is it a good idea? Thanks, Jacek

2 1

Re: Add some autoconf warnings
by Alexandre Julliard March 18, 2005

March 18, 2005

Francois Gouget <fgouget(a)free.fr> writes: > I thought I had sent this patch months ago but apparently not. The > idea is to warn the user when some often used libraries are missing > and is based on the warnings issued for bad Mesa or X > configurations. Let me know if the range of checks should be expanded > or reduced or otherwise tweaked. We've discussed this before, I don't think we should warn about these things, it's perfectly harmless in most cases and will just alarm users for no good reason. -- Alexandre Julliard julliard(a)winehq.org

5 5

Re: Wine FAQ removed from the doc tarballs
by wino＠piments.com March 18, 2005

March 18, 2005

>> A FAQ is essentially a Web type of document, best view and browsed on the Web. This does not ring true. I dont see that any part of the doc "best viewed on the web" unless it's something like a change log or last minute info. Someone with limitted acces time or pay by the minute may well want to grab the whole thing at full speed and read it later off line. Neither do I think that the FAQ represents such a large percentage of the total that it merits speciail treatment. If the doc as a whole is deemed too big split it, I doubt that this is necessary. Regards. -- Opera 7 mail on Linux

1 0

Re: STI, device drivers and stuff
by Damjan Jovanovic March 18, 2005

March 18, 2005

--- Kuba Ober <kuba(a)mareimbrium.org> wrote: > > IStiDeviceControl are probably part of the Windows > DDK > > (Device Driver Kit), and that you get separately > from > > Microsoft (for a ridiculous price). > > It's a free CD. You pay only for shipping. If you > want, I've got two of those > and can transfer one of them to be taken care of by > the wine folks. As long > as it's a US address, that is. > > Cheers, Kuba No, I live in South Africa. Can't you email me the file? Bye Damjan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Wine FAQ removed from the doc tarballs
by Francois Gouget March 18, 2005

March 18, 2005

I noticed that we don't include the Wine FAQ in the Wine documentation tarballs. So I added it but then I noticed that it was removed from the tarballs by this patch: --- revision 1.36 date: 2003-09-18 20:51:32 +0000; author: julliard; state: Exp; lines: +9 -5 Remove the FAQ from the doc tarball, and build it as a single .html file (based on patch by Dimitrie O. Paun). --- What's the reasoning behind this? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

2 3

Re: ddraw correctness fixes patch
by Christian Costa March 18, 2005

March 18, 2005

> Message du 18/03/05 06:44 > De : "Tom Wickline" > A : "wine-devel" > Copie à : > Objet : ddraw correctness fixes patch > > anyone know why this patch hasn't been accepted? > > http://www.winehq.org/hypermail/wine-patches/2005/03/0328.html > > Tom > Hi Tom, Sorry I missed the patch on wine-patches but I do remember an old version sent to wine-devel. So let's review it. :-) The new locking mechanism is wrong. DDLOCK_xxx are just used for optimization. The thing to do during the blit should be something like that : sdesc.dwSize = sizeof(sdesc); ddesc.dwSize = sizeof(ddesc); if (src == NULL) IDirectDrawSurface7_Lock(iface, &lock_dst, &ddesc, DDLOCK_WRITEONLY, 0); else if (src == iface) { RECT lock_union = < rect that just contains lock_dst and lock_src >; IDirectDrawSurface7_Lock(iface, &lock_union, &ddesc, 0, 0); sdesc = ddesc; } else { IDirectDrawSurface7_Lock(src, &lock_src, &sdesc, DDLOCK_READONLY, 0); IDirectDrawSurface7_Lock(iface, &lock_dst, &ddesc, DDLOCK_WRITEONLY, 0); } and the previous locking code should be used. The added DD_STRUCT_INIT are useless. Hope that helps. Bye, Christian

1 0

animate control regression
by Krzysztof Foltman March 18, 2005

March 18, 2005

The current CVS version has a regression in the animate control, causing a deadlock, most probably in WM_DESTROY handler, in the app I'm testing Wine with. trace:message:SPY_ExitMessage (0x10038) L"{SysAnimate32}" message [0047] WM_WINDOWPOSCHANGED returned 00000000 trace:message:SPY_EnterMessage (0x10038) L"{SysAnimate32}" message [0002] WM_DESTROY sent from self wp=00000000 lp=00000000 err:ntdll:RtlpWaitForCriticalSection section 0x403a3cb8 "?" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) Reversing these two patches seems to fix the problem: http://cvs.winehq.org/patch.py?id=16654 http://cvs.winehq.org/patch.py?id=16619 I don't know if patch 16654 has any effect on this problem - I don't know this code well enough to reverse patches in random order. Hope it isn't difficult to fix... Krzysztof

3 3