- Wine-devel - list.winehq.org

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard 18 Aug '01

18 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > WM_GETTEXTLENGTH, WM_GETTEXT, then DrawText with the > length returned by WM_GETTEXTLENGTH. > If the app had used the length returned by WM_GETTEXT, it would > have worked all right of course - maybe that's the reason why > the problem does not appear more often ? For standard controls like buttons it should never be a problem since there is both an ASCII and Unicode win proc, so in a pure ASCII app we should never do the conversion. I think the problem is that the dialog code does a CreateWindowW, so the button is Unicode even though the app does everything in ASCII. I guess we'll have to maintain both A and W win procs inside each window, not only inside the class. -- Alexandre Julliard julliard(a)winehq.com

1 0

WM_GETTEXTLENGTH change in winproc.c
by Gerard Patel 18 Aug '01

18 Aug '01

I don't understand it : case WM_GETTEXTLENGTH: 719 case CB_GETLBTEXTLEN: 720 case LB_GETTEXTLEN: 721 /* there may be one DBCS char for each Unicode char */ 722 return result * 2; This has a bad effect on one of my test apps - returns a length of 12 for a text of 6 characters, displays funny symbols after the text. The Unicode window proc returns 6, why the unicode/ascii conversion should make it 12 ? The Api returns number of chars, not bytes. Gerard

1 0

Re: WM_GETTEXTLENGTH change in winproc.c
by Alexandre Julliard 18 Aug '01

18 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > I don't understand it : > > case WM_GETTEXTLENGTH: > 719 case CB_GETLBTEXTLEN: > 720 case LB_GETTEXTLEN: > 721 /* there may be one DBCS char for each Unicode char */ > 722 return result * 2; > > This has a bad effect on one of my test apps - returns a length of 12 > for a text of 6 characters, displays funny symbols after the text. > > The Unicode window proc returns 6, why the unicode/ascii conversion > should make it 12 ? The Api returns number of chars, not bytes. The idea is that 6 Unicode chars can yield more than 6 ASCII chars with DBCS text. The MSDN doc states that WM_GETTEXTLENGTH can return more than the actual size when mixing ASCII and Unicode. What does the app do exactly? Maybe there are cases where the conversion can be avoided. -- Alexandre Julliard julliard(a)winehq.com

1 0

not-yet-connected sockets?
by Daniel Walker 18 Aug '01

18 Aug '01

The problem is that poll returns POLLHUP when a socket isn't connected, then wine ignores the socket and it's events .. I realize this has been known for a some time(since linux 2.4), but why hasn't it been fix? Doesn't this effect a lot of non-blocking socket applications? Daniel Walker

3 13

Re: Toolbar background error
by Gerard Patel 18 Aug '01

18 Aug '01

At 06:54 PM 17/08/2001 -0700, you wrote: <snip> >But their solution is still not correct IMO. How about something like >this? All clear for me on this one, tested without problem for all of my test apps - at least the one surviving the Gdi lock slaughter :-) Gerard

1 0

Re:CryptoAPI
by Eric Pouech 18 Aug '01

18 Aug '01

from a pure technical point of view, the crypto API is in a pure WOSA style : - a set of high level API (in advapi) - an extendable set of low level service providers (here for example the crypto algos - RSA....) - the high level maps the fonctional request of the user onto on of the available SP. so, my advice here would be to implement this type of scheme. This would allow to: - use native DLLs if they exist (and go beyond what's supported by Linux) - still allow to use Linux lib (just build a wrapper DLL to that lib) and you should be all set from a copyright point of view: - Wine use a X11 like licence, so make sure all the external libs you use are not GPL (LGPL is fine). If they are GPL, you won't be able to ship the result with Wine. - Use of native DLL is granted as long as you have a Windows licence on the target machine (native DLLs shall not be shipped with Wine, Wine should be configured to use the local resources) from an exportation point of view: - some countries (US as an example) puts lots of contraints on the type of crypto algo to be used outside of the US. So those shouldn't be shipped with Wine's, but be provided as an external resource) > Hi, > > I was going to start implementing the Cypto API (in advapi32.dll) over the > next few weeks. As of yet these functions are no more than stubs. However, > I am finding increased use of this API as more applications becomed > networkable and relying more heavily on internet connections. > > I was hoping to implement these functions by using the OpenSSL library > (if/when available). This library seems to have similar capabilities. > > One of my concerns is about legal issues. What special concerns should I > note about cryptographic software? Are there any special copyright issues I > should be aware of? > > Another question is about design. M$ seems to split the cryptographic > software into different dlls (rsabase.dll, rsasig.dll, dssbase.dll, etc.). > Should I do this as well so that, applications can use the native dlls if > necessary or should I simply implement it entirely though advapi32.dll which > and avoid the need to create several new (and very small) dlls under wine? > Because most of the code is already in another library (OpenSSL) creating > extra dlls seems abit unnecessary. > > - Travis > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > > --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: Toolbar background error
by Alexandre Julliard 17 Aug '01

17 Aug '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > I suggest reading the Corel CVS for this part of the code. > > They rewrote this part like _5_ times. But their solution is still not correct IMO. How about something like this? Index: windows/defwnd.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/defwnd.c,v retrieving revision 1.59 diff -u -r1.59 defwnd.c --- windows/defwnd.c 2001/08/10 22:51:43 1.59 +++ windows/defwnd.c 2001/08/18 00:21:43 @@ -461,10 +461,13 @@ HBRUSH hbr = GetClassLongW( wndPtr->hwndSelf, GCL_HBRBACKGROUND ); if (!hbr) return 0; - /* GetClientRect used to be GetClipBox, but it is not what - * Windows does, and it breaks badly with CS_PARENTDC */ - GetClientRect( wndPtr->hwndSelf, &rect ); - DPtoLP( hdc, (LPPOINT)&rect, 2 ); + if (GetClassLongW( wndPtr->hwndSelf, GCL_STYLE ) & CS_PARENTDC) + { + /* can't use GetClipBox with a parent DC or we fill the whole parent */ + GetClientRect( wndPtr->hwndSelf, &rect ); + DPtoLP( hdc, (LPPOINT)&rect, 2 ); + } + else GetClipBox( hdc, &rect ); FillRect( hdc, &rect, hbr ); return 1; } -- Alexandre Julliard julliard(a)winehq.com

1 0

dsound ??
by Bobby Bingham 17 Aug '01

17 Aug '01

Hello all, I completely rebuilt my computer a while back, and updated wine, so I'm not sure which is causing it, but not dsound doesn't seem to work where it did before. Starcraft doesn't play any music, sound, etc, but it's installer still plays it's sound (without dsound). Before this I hadn't updated WINE for a while, so I'm not sure when it broke. Bobby Bingham

1 0

Re: Toolbar background error
by Gerard Patel 17 Aug '01

17 Aug '01

At 11:08 AM 17/08/2001 -0700, you wrote: >That's not what Windows does. If you pass a window DC to WM_ERASEBKGND >it only erases an area equivalent to the client area (shifted to be >relative to the whole window), so GetClientRect is correct IMO. The >non-client area should be painted upon WM_NCPAINT, not WM_ERASEBKGND. How do you test this under Windows ? In my test app, I have a white brush as class brush. So my window is white. If I add after the BeginPaint : GetClientRect(hwnd, &r); r.top += 200; FillRect(ps.hdc, &r, (HBRUSH) COLOR_WINDOW) the lower part of my window is painted with the beautiful window color (brown) Now if I add immediately after : hdc = GetWindowDC(hwnd); SendMessage(hwnd, WM_ERASEBKGND, (WPARAM) hdc, 0); ReleaseDC(hwnd, hdc); I get a window that is completely white; maybe I am missing something but I should see a small brown strip at the lower part of the window, corresponding to the caption + menu height, no ? Gerard

1 0

Re: Toolbar background error
by Gerard Patel 17 Aug '01

17 Aug '01

At 02:33 PM 17/08/2001 GMT, you wrote: <snip> >So how does an application modify the location of the client rectangle >after it has been created? By changing rgrc[0] when responding to WM_NCCALCSIZE. It seems that it is only possible to erase properly the 'custom' nonclient area by using GetWindowDC... So : --- defwnd.c.orig Sat Aug 11 10:23:18 2001 +++ defwnd.c Fri Aug 17 19:47:17 2001 @@ -462,8 +462,12 @@ if (!hbr) return 0; /* GetClientRect used to be GetClipBox, but it is not what - * Windows does, and it breaks badly with CS_PARENTDC */ - GetClientRect( wndPtr->hwndSelf, &rect ); + * Windows does, and it breaks badly with CS_PARENTDC + * GetClientRect breaks too when we are called with a window + * DC (!!) - what next ? */ + rect.left = rect.top = 0; + rect.right = wndPtr->rectWindow.right - wndPtr->rectWindow.left; + rect.bottom = wndPtr->rectWindow.bottom - wndPtr->rectWindow.top; DPtoLP( hdc, (LPPOINT)&rect, 2 ); FillRect( hdc, &rect, hbr ); return 1; What do you think ? Gerard

2 1