May 2008 - Wine-devel - list.winehq.org

kernel32: Implementation of GetLargestConsoleWindowSize.
by Reijo T Sund 02 May '08

02 May '08

Eric Pouech (Fri May 2 01:38:37 CDT 2008): > first of all, implementing twice the same function is a bad idea > you should wrap the two implementations into a single function, and have > simple wrappers for handling the different return convention > in the other items: > - you never handle errors in return from server calls > - where do the 2 (resp 3) factors come from ? Kirill K. Smirnov (Fri May 2 04:47:48 CDT 2008): > Fortunately, since you do not check error codes (as Eric pointed out), > all variables get initialized to somehow sane values and this does not fail > for curses. Thank you very much for your comments. I have now revised the patch to have a single helper function and similar simple wrappers as there were with the fixed constants. I also added the error handling for the server calls, and initialized all variables to have sensible values even if the server calls fail, so that the code should not fail for curses. The factors 2 and 3 come from the fact that the client area is smaller than the desktop area, and in addition to window frames also the scrollbars and desktopbar should be taken into account. Please check out the test code attached to bug report 10919: http://bugs.winehq.org/show_bug.cgi?id=10919 I'll send the corrected version of the patch to the patches-list. Reijo

1 0

Problem with VoIP applications
by Pavel Troller 02 May '08

02 May '08

Hi! I was trying to run FreeCall VoIP client, however, it detects a problem and tries to contact its authors. I've done a bit of googling and I've found that there are at least 3 similar programs (FreeCall, VoipCheap, VoipDiscount) which behave exactly the same way, they are using probably the same client. Also AppDb lists at least one of them, with identical symptoms. There is the following report generated by wine: patrol(a)arcus:~/.wine/drive_c/Program Files/FreeCall.com/FreeCall$ wine FreeCall.exe preloader: Warning: failed to reserve range 00000000-00010000 preloader: Warning: failed to reserve range 00000000-00010000 preloader: Warning: failed to reserve range 00000000-00010000 preloader: Warning: failed to reserve range 00000000-00010000 err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element preloader: Warning: failed to reserve range 00000000-00010000 err:ole:CoInitializeEx Attempt to change threading model of this apartment from apartment threaded to multi-threaded err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not registered err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not registered err:ole:create_server class {bcde0395-e52f-467c-8e3d-c4579291692e} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {bcde0395-e52f-467c-8e3d-c4579291692e} could be created for context 0x17 err:ole:CoInitializeEx Attempt to change threading model of this apartment from apartment threaded to multi-threaded err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not registered err:ole:CoGetClassObject class {bcde0395-e52f-467c-8e3d-c4579291692e} not registered err:ole:create_server class {bcde0395-e52f-467c-8e3d-c4579291692e} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {bcde0395-e52f-467c-8e3d-c4579291692e} could be created for context 0x17 The preloader warnings are harmless in this case. I think the ole errors are the real cause. I don't need to use the program for calling, just to make a registration to FreeCall - they offer also the web-based registration, but then they don't allow to pay with PayPal - "for better security" :-(. Any chance the program could be started at least to allow the registration ? With regards, Pavel Troller

2 1

Re: DDraw: enable EnableAutoDepthStencil to receive depth support
by Stefan Dösinger 02 May '08

02 May '08

Actually, setting AutoDepthStencil to TRUE is technically wrong, but I am afraid the only option. DDraw doesn't create a depth stencil surface automatically. The app has to create it manually, then attach it to the primary. When the app creates the depth stencil, ddraw creates a wined3d depth stencil. When the app attaches the depth stencil, ddraw calls SetDepthStencilSurface. So the bug is in WineD3D, not ddraw. We would have to fetch a depth stencil buffer from somewhere on SetDepthStencilSurface. In the very same way, a d3d9 application could set autodepthstencil = FALSE and create the depth stencil on its own. Since we cannot attach a depth stencil surface in the d3d9 way without rendering to an FBO(if they are available at all), we have a problem. One option would be to always create an opengl depth stencil capable format, which would undo some of the gains from the pixel format support. Another option is this patch - we didn't have a manual d3d9 depth stencil creation yet. A third option is to change the opengl pixelformat in SetDepthStencilSurface(upwards only, UNKNOWN -> D16 -> D24X8 -> D24S8).

1 0

Re: widl: Add a framework for automated testing of IDL files that should succeed or fail to be parsed.
by Dan Hipschman 02 May '08

02 May '08

On Mon, Apr 28, 2008 at 08:37:26PM +0100, Robert Shearman wrote: > > This should aid in testing more-obscure parts of the parser that aren't > necessarily valid when using RPC (and hence don't make sense being put > in dlls/rpcrt4/tests/server.idl). Obviously this is a good idea. I tried doing something similar a while ago, but it didn't get accepted on the first try and I never asked why, so I'll ask why now. See here: http://winehq.org/pipermail/wine-patches/2006-September/030438.html It has some benefits over the approach you're proposing so it's worth bringing up. One is that it can run the tests against MIDL, so we know the tests themselves are correct (ok, MIDL has been known to do things differently than the spec, but we may want to copy MIDL's behaviour anyway, and in any case it's easier to automatically validate the tests on MIDL than to do so by hand or by inspection). Another is versatility in what it can test. Since the tests are shell scripts, not only can it test the success/failure of a parse, but it can check that all the correct files were created, and it can perform further tests on the output (e.g., if we have an import in the IDL file, we can grep the output to make sure a #include was generated for the import). It already supports "todo"s, and the test scripts look similar to the usual Wine tests written in C. On the other hand your method has some advantages over mine. You already provide a "make test" framework, and including the expected result of the compilation in the IDL file is cleaner. Alexandre may very well disagree with what I see as valid points (like testing on MIDL), but these are my suggestions anyway. Hope they're useful.

3 3

kernel32: Implementation of GetLargestConsoleWindowSize.
by Kirill K. Smirnov 02 May '08

02 May '08

Hi, + + hWnd = GetConsoleWindow(); + + SERVER_START_REQ( get_window_rectangles ) + { + req->handle = hWnd; + ret = !wine_server_call_err(req); + colpix = reply->client.right - reply->client.left; + linpix = reply->client.bottom - reply->client.top; + colext = (reply->window.right - reply->window.left) - colpix; + linext = (reply->window.bottom - reply->window.top) - linpix; + } + SERVER_END_REQ; This piece of code does not checks for curses backend. Yes, right now it is broken in mainstream, but 1) it may resurrected some day 2) bug #8069 contains quick hack to make it working. Fortunately, since you do not check error codes (as Eric pointed out), all variables get initialized to somehow sane values and this does not fail for curses. -- Kirill

1 0

Re: [PATCH] user32: only send WM_SIZE if the window size actually changed.
by Alexandre Julliard 02 May '08

02 May '08

"Lei Zhang" <thestig(a)google.com> writes: > We shouldn't send WM_SIZE in response to WM_WINDOWPOSCHANGED unless > the window size actually changed. The client size can change even if the window size doesn't. What are you trying to fix? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/5] kernel32: implement __wine_kernel_init_environment.
by Alexandre Julliard 02 May '08

02 May '08

"Lei Zhang" <thestig(a)google.com> writes: > This makes several internal kernel32 process functions more flexible > in order to accommodate __wine_kernel_init_environment. > __wine_kernel_init_environment is needed for CreateEnvironmentBlock. It's not appropriate to export that from kernel32; userenv should use only standard APIs. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: kernel32: Implementation of GetLargestConsoleWindowSize.
by Eric Pouech 02 May '08

02 May '08

Reijo T Sund a écrit : > >From e59f5ec4eaf6936b7ecb6e4d0a471d38622f22aa Mon Sep 17 00:00:00 2001 > From: Reijo Sund <reijo.sund(a)helsinki.fi> > Date: Thu, 1 May 2008 10:20:19 +0300 > Subject: kernel32: Implementation of GetLargestConsoleWindowSize. > > The function should return the largest size instead of hard coded > constants. A fix for the bug 10919. > first of all, implementing twice the same function is a bad idea you should wrap the two implementations into a single function, and have simple wrappers for handling the different return convention in the other items: - you never handle errors in return from server calls - where do the 2 (resp 3) factors come from ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Re: hhctrl.ocx: Fix for memory release problem in ReleaseWebBrowser (fixes bug #12767)
by Tefnet Developers 01 May '08

01 May '08

Dnia 24-04-2008, czw o godzinie 12:48 +0200, Tomasz Jezierski - Tefnet pisze: > For more information check bug report. > Hi.. what's the status of this patch? I haven't found any comments on wine-devel about it.

2 1

Re: shlwapi: expose the IStream_Read and IStream_Write functions.
by Robert Shearman 01 May '08

01 May '08

Reece Dunn wrote: > @@ -926,6 +926,13 @@ HRESULT WINAPI SHCreateStreamOnFileEx(LPCWSTR,DWORD,DWORD,BOOL,struct IStream*,s > > HRESULT WINAPI SHCreateStreamWrapper(LPBYTE,DWORD,DWORD,struct IStream**); > > +#undef IStream_Read > +#undef IStream_Write > + > +HRESULT WINAPI IStream_Read(struct IStream *, LPVOID, ULONG); > + > +HRESULT WINAPI IStream_Write(struct IStream *, LPCVOID, ULONG); > + > #endif /* NO_SHLWAPI_STREAM */ > > /* SHAutoComplete flags */ > You've put this in the section guarded by NO_SHLWAPI_STREAM, but in the PSDK header it isn't guarded by this define. If it were the case, then you could have fixed the issue in files that include shlwapi.h by defining this before including it. However, I think having to work around not being able to use the IStream_Read and IStream_Write macros is a bit ugly. -- Rob Shearman

2 1