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

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE. (Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..) You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms! However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. Oh please Santa ! Let us adultrate WINE with C++, please. It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ? Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can atleast run under WINE ? DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it ! As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it ! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy. Most of the time we are passing around multilevel pointers when a simple reference would have done: For example a call like Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )'] can be made to a simple Stream_LoadString(sString); using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR& pstr )' and making it a member function of IStream (and thus the 'IStream* stm' and 'BOOL unicode' would be member variables..) We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" ! Please give us the green card - alternately, a new test branch may also be created just to see if C++ would work.All C++ based modfications would goto that tree. If that test branch works and delivers, it maybe merged into the main WINE tree, otherwise if it fails

2 1

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE. (Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..) You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms! However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. Oh please Santa ! Let us adultrate WINE with C++, please. It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ? Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can atleast run under WINE ? DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it ! As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it ! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy. Most of the time we are passing around multilevel pointers when a simple reference would have done: For example a call like Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )'] can be made to a simple Stream_LoadString(sString); using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR& pstr )' and makin

1 0

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE. (Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..) You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms! However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. Oh please Santa ! Let us adultrate WINE with C++, please. It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about M

1 0

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE. (Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..) You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms! However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. Oh please Santa ! Let us adultrate WINE with C++, please. It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ? Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can atleast run under WINE ? DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it ! As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it ! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy. Most of the time we are passing around multilevel pointers when a simple reference would have done: For example a call like Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )'] can be made to a simple Stream_LoadString(sString); using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR& pstr )' and makin

1 0

Re: regedit: consistent formatting
by Lionel Ulmer 09 Dec '03

09 Dec '03

On Mon, Dec 08, 2003 at 12:03:00AM -0500, Dimitrie O. Paun wrote: > Only whitespace changes. Unfortunately, the formatting was > all messed up by having tabs of 4 and 8 chars (I said it > before, and I'll say it again: the only sane way of dealing > with tabs is to always use the standard size of 8 chars. > Anything else is too complicated to ever work reliably). Just to flame a bit (the lists were a bit quiet lately) : the only sane way to dealing with TABs is when TABs are used properly (ie by an editor that uses them only to go to the current C indenting level and uses spaces for everything that comes after). With such an editor, tab size does not matter at all. No idea if Emacs / Vi can be used to work like that :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

6 10

Question about libwine_unicode functions and others in WINE
by Steven Edwards 08 Dec '03

08 Dec '03

Hello, We are looking at porting more code from WINE to ReactOS and I am having trouble understanding the need for libwine_unicode as a shared library. Some of the functions that it exports such as CompareString are implemented in ntdll as RtlCompareString and then also used in shlwapi as per a recent patch. Wouldnt it better to import the function from ntdll and hide libwine_unicode or make the parts that we need to share a static library? In ReactOS we have created NT compatible NLS files. Could WINE do this also and dump libwine_nicode? Also I was looking at the HeapAlloc stuff in WINE and code we have ported from ReactOS such as the FormatMessage function in kernel32. Doesnt kernel32 HeapAlloc and friends map on top of ntdll RtlHelpAlloc? Can we submit patches to WINE so that everything just calls RtlHeapAlloc so we dont have to change the sources? Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

7 19

ATI driver crashes the system with wine
by Gerhard W. Gruber 08 Dec '03

08 Dec '03

I tried to install the ATI 3D acceleration for my card Radeon 9800XT. So far I didn'tsucced and I currently have to use Mesa for that. Now I managed to get at least the fglrx driver working with agpgart but when I use this then my system immediatly crashes when I try to run Agent from wine. I doubt that Agent is the cuplrit, so I guess this is something in wine. The screen goes simply blank and I can't see anything. I have to power off. When I disable the agpgart module I can run wine as well. My system: Kernel 2.4.22 (kernel.org) Suse 8.2 pro (with the drivers from the latest release). Wine is the CVS download from today (I just downloaded it about an hour ago and installed it). Everything else works fine. When I run glxgears it works, even though I have only 400 FPS because of the missing 3D acceleration. Any ideas whats wrong there or how I can debug this? Maybe this will give me a clue as whats wrong with my 3D acceleration as well. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

4 5

Re: wine/windows painting.c
by Marcelo Duarte 08 Dec '03

08 Dec '03

This patch caused a regression in Winamp 2.91, and the top window is not repainted. I use with the folowing modifications in the ~/.wine/config: ; Winamp 2.91 runs good, but the title is eated. In desktop is better. [AppDefaults\\winamp.exe\\x11drv] "Desktop" = "560x700" Em Sex 05 Dez 2003 01:42, Alexandre Julliard escreveu: > ChangeSet ID: 10338 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/12/04 22:42:43 > > Modified files: > windows : painting.c > > Log message: > In RDW_ValidateParent, get rid of the parent update region if it is > empty after the validation, to avoid a useless WM_PAINT. > > Patch: http://cvs.winehq.com/patch.py?id=10338 > > Old revision New revision Changes Path > 1.88 1.89 +9 -1 wine/windows/painting.c Index: wine/windows/painting.c diff -u wine/windows/painting.c:1.88 wine/windows/painting.c:1.89 --- wine/windows/painting.c:1.88 Sun Dec 7 05:54:18 2003 +++ wine/windows/painting.c Sun Dec 7 05:54:18 2003 @@ -379,7 +379,15 @@ ptOffset.x = rect.left - rectParent.left; ptOffset.y = rect.top - rectParent.top; OffsetRgn( hrg, ptOffset.x, ptOffset.y ); - CombineRgn( wndParent->hrgnUpdate, wndParent->hrgnUpdate, hrg, RGN_DIFF ); + if (CombineRgn( wndParent->hrgnUpdate, wndParent->hrgnUpdate, hrg, RGN_DIFF ) == NULLREGION) + { + /* the update region has become empty */ + DeleteObject( wndParent->hrgnUpdate ); + wndParent->hrgnUpdate = 0; + wndParent->flags &= ~WIN_NEEDS_ERASEBKGND; + if( !(wndParent->flags & WIN_INTERNAL_PAINT) ) + add_paint_count( wndParent->hwndSelf, -1 ); + } OffsetRgn( hrg, -ptOffset.x, -ptOffset.y ); } } -- Marcelo Duarte

2 2

Status : Multimedia section
by Tom 07 Dec '03

07 Dec '03

Hi, Here is the new layout of the Multimedia section of the "Status Dll's" page. May I ask what you guys here think of it?, constructive criticism? Tom

5 10

Re: small file reorganisation
by Alexandre Julliard 06 Dec '03

06 Dec '03

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > I hope Alexandre will not got mad about the introduced circular dep > (kernel32 => (delay) winedos => kernel32). Since, we're now building > the DLLs through the .spec files, I assumed, since it no longer > impacts the make system, it would be ok. I don't think that's a good idea, especially since winedos is not a standard dll. And IMO it's preferable to have kernel export _lclose16 which is a standard API, than replacing it by a new DisposeFileHandle function that doesn't correspond to anything on Windows. -- Alexandre Julliard julliard(a)winehq.com

2 4