August 2007 - Wine-Devel - list.winehq.org

Re: Direct3D Game test framework

by Tom Wickline

Can you try this, set Wine to run in a virtual desktop of 1024x768 and set X at 16bpp and run 3DMark2000 in win98 mode. then cd into the install directory and see if that works. Tom On 8/8/07, martin pilka <mpilka(a)codeweavers.com> wrote: > > Hello Martin > > > > If you cd into the 3DMark2000 install directory and run it from there > > does it work? > > > > Tom > > > Thanks Tom, that was it. I got a bit further, the message I got this time is: > > 3DMark could not initialize your 3D Accelerator. Try to downgrade your > display settings. > > I played with resolutions and xorg.conf file quite a bit, no joy so far, > could you send me your xorg.conf file? > > Thanks, > Martin > > > -- Microsoft's patent protection scheme is the equivalent of bailing water with a sieve.

Aug. 8, 2007

Re: Direct3D Game test framework

by martin pilka

> Hello Martin > > If you cd into the 3DMark2000 install directory and run it from there > does it work? > > Tom Thanks Tom, that was it. I got a bit further, the message I got this time is: 3DMark could not initialize your 3D Accelerator. Try to downgrade your display settings. I played with resolutions and xorg.conf file quite a bit, no joy so far, could you send me your xorg.conf file? Thanks, Martin

Aug. 8, 2007

Re: Wine Kernel Handle Support Module

by Marcus Meissner

On Wed, Aug 08, 2007 at 02:09:46AM -0400, James Keane wrote: > I have been working on something that might be useful for kernel > integration. It is a way for wine to create its own interrupt, so > that a wine server/kernel/handle/whatever function could be called > from userspace with a simple INT 0xwhatever. Just as linux uses int > 0x80. > > The only problem I could see with this technique is that it directly > modifies the IDT, which only exists on i386/amd64 architectures, so > that means we would have to find something else. > > I am not sure if this is the direction that some people want to take, > because I am sure this modification of the IDT would be considered > improper by kernel types but come on, I mean i386 has something like > 200 software interrupts and linux uses only one. > > As it stands now, I have code that works perfectly with amd64 > processors and just need to implement the actual wine system calls for > handles or whatever it is. i386 support is a stones throw away, I > just need to setup a virtual machine. > > I know there is some discussion of what should be put in the kernel > module, so I am asking for advice on what to implement... ie. just > handles, everything wineserver does, etc. The first question is: Why do you want to do that and what specifically do you want to achieve? Ciao, Marcus

Aug. 8, 2007

Re: [kernel32/tests 2/2] Skip all tests if one W-function can't be found

by Paul Vriens

On 8/7/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > (Should be applied after "[kernel32/tests] Changed skip message"). > > There are to many W-functions called so skip everything if the first function is > not implemented. This makes the test not crash on win95/win98. > > Changelog > Skip all tests if one W-function can't be found > > Cheers, > > Paul > > > Don't use this one. I'll sent an easier fix. The "[kernel32/tests] Changed skip message" can still be applied though. Cheers, Paul.

Aug. 8, 2007

Re: [Winetest] Possible removal of LoadLibrary and friends in the conformance tests

by Paul Vriens

Stefan Leichter wrote: > Am Tuesday 07 August 2007 09:43 schrieb Paul Vriens: >> This will be a lengthy process so if there are volunteers, please step up. >> >> Eventhough this is some considerable amount of work to be done, in the end >> the code will be cleaner (and several lines shorter). >> >> Comments/remarks ? >> > Make sure that Paul Millar has time to update the mingw build environment. > Otherwise we have to wait some time to get a new winetest.exe from the > download side. > > Bye > Stefan > The only issue I see there is if we now do a LoadLibrary and when we add the dll back to the IMPORTS of the Makefile.in. This could lead to issues if some dll/function is not known to mingw. The best thing to catch these upfront is to do a 'make crosstest' before submitting any patch, right? (But that's something I'm doing most of the time anyway.) Cheers, PAul.

Aug. 8, 2007

Wine Kernel Handle Support Module

by James Keane

I have been working on something that might be useful for kernel integration. It is a way for wine to create its own interrupt, so that a wine server/kernel/handle/whatever function could be called from userspace with a simple INT 0xwhatever. Just as linux uses int 0x80. The only problem I could see with this technique is that it directly modifies the IDT, which only exists on i386/amd64 architectures, so that means we would have to find something else. I am not sure if this is the direction that some people want to take, because I am sure this modification of the IDT would be considered improper by kernel types but come on, I mean i386 has something like 200 software interrupts and linux uses only one. As it stands now, I have code that works perfectly with amd64 processors and just need to implement the actual wine system calls for handles or whatever it is. i386 support is a stones throw away, I just need to setup a virtual machine. I know there is some discussion of what should be put in the kernel module, so I am asking for advice on what to implement... ie. just handles, everything wineserver does, etc.

Aug. 8, 2007

Re: WineD3D: move fake context code over to WGL

by Joseph Garvin

Alexandre Julliard wrote: > Roderick Colenbrander <thunderbird2k(a)gmx.net> writes: > > >> Subject: [PATCH] Move WineD3D_CreateFakeGLContext and friends over >> to WGL. For this we need a HDC and one received from lets say >> GetDC(0) won't do. Further this HDC needs CS_OWNDC set. For this >> reason we need our own window class. >> > > Why does it need CS_OWNDC? That sounds like a bug. > > I came across this today in the wxWidgets library. Although it's not clear it affects newer windows versions, this comment tries to explain, quoting src/msw/glcanvas.cpp: /* From Angel Popov <jumpo(a)bitex.com> Here are two snips from a dicussion in the OpenGL Gamedev list that explains how this problem can be fixed: "There are 5 common DCs available in Win95. These are aquired when you call GetDC or GetDCEx from a window that does _not_ have the OWNDC flag. OWNDC flagged windows do not get their DC from the common DC pool, the issue is they require 800 bytes each from the limited 64Kb local heap for GDI." "The deal is, if you hold onto one of the 5 shared DC's too long (as GL apps do), Win95 will actually "steal" it from you. MakeCurrent fails, apparently, because Windows re-assigns the HDC to a different window. The only way to prevent this, the only reliable means, is to set CS_OWNDC." */

Aug. 8, 2007

Re: user32: CallWindowProc[AW] for mismatched built-in winprocs should take into account if the window is Unicode (with testcase, fixes bug #9198)

by Dmitry Timoshkov

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > --- a/dlls/user32/tests/class.c > +++ b/dlls/user32/tests/class.c > @@ -32,6 +32,7 @@ > #include "winreg.h" > #include "wingdi.h" > #include "winuser.h" > +#include <commctrl.h> /* for WC_EDITW */ Besides using braces instead of quotes to match existing style it's not really nice to include commctrl.h in a user32 (more lower level) test. It shouldn't be too hard to add "Edit" in WCHAR notation. > /*********************************************************************** > */ > static void ClassTest(HINSTANCE hInstance, BOOL global) > @@ -560,7 +566,12 @@ static void test_defwndproc() > { > static const char classA[] = "deftest"; > static const WCHAR classW[] = {'d','e','f','t','e','s','t',0}; > + WCHAR unistring[] = {0x142, 0x40e, 0x3b4, 0}; /* a string that would be destoryed by a W->A->W conversion */ Any other string should work just fine. In the current form the test will fail for some locales. > diff --git a/dlls/user32/winproc.c b/dlls/user32/winproc.c > index 27b31a1..4feb3d5 100644 > --- a/dlls/user32/winproc.c > +++ b/dlls/user32/winproc.c > @@ -2257,7 +2257,17 @@ LRESULT WINAPI CallWindowProcA( > > if (!func) return 0; > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procA || !IsWindowUnicode( hwnd )) > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + else > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + return result; > + } > + > + if (!(proc = handle_to_proc( func ))) > call_window_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procA) > call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > @@ -2281,8 +2291,18 @@ LRESULT WINAPI CallWindowProcW( WNDPROC func, HWND hwnd, UINT msg, > LRESULT result; > > if (!func) return 0; > + > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procW || IsWindowUnicode( hwnd )) > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + else > + call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + return result; > + } > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + if (!(proc = handle_to_proc( func ))) > call_window_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procW) > call_window_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > @@ -2340,7 +2360,17 @@ INT_PTR WINPROC_CallDlgProcA( DLGPROC func, HWND hwnd, UINT msg, WPARAM wParam, > > if (!func) return 0; > > - if (!(proc = handle_to_proc( func )) && !(proc = find_builtin_proc( func ))) > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procA || !IsWindowUnicode( hwnd )) > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + else > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + return result; > + } > + > + if (!(proc = handle_to_proc( func ))) > ret = call_dialog_proc( hwnd, msg, wParam, lParam, &result, func ); > else if (proc->procA) > ret = call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > @@ -2368,8 +2398,18 @@ INT_PTR WINPROC_CallDlgProcW( DLGPROC func, HWND hwnd, UINT msg, WPARAM wParam, > INT_PTR ret; > > if (!func) return 0; > + > + /* for built-in procs we do as if the second item was a thunk */ > + if ((proc = find_builtin_proc( func )) != NULL) > + { > + if (func == proc->procW || IsWindowUnicode( hwnd )) > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procW ); > + else > + call_dialog_proc( hwnd, msg, wParam, lParam, &result, proc->procA ); > + return result; > + } Please use spaces instead of tabs to match current formatting. -- Dmitry.

Aug. 8, 2007

Re: [Winetest] Status update (rsabase and secur32)

by Robert Kim Wireless Internet Advisor

Paul, need more details here. Is that the latest dll version? On 8/7/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > The new winetest is running fine and new reports are produced > (http://test.winehq.org/data/200708071000/) > > I have seen at least 2 things so far that I need some info on. > > rsabase.dll is not available on for example w2k3 and vista but the tests ran in > the past. > > secur32.dll is not available on for example NT4 but the current tests check if > security.dll is available instead. > > What should we do to cater for the above: > > - we could move for example rsabase tests to rsaenh (we forward everything to > rsaenh as well) and something similar for secur32. > - we could implement an exception list in winetest for these particular cases. > > Remarks/Comments? > > Cheers, > > Paul. > > > -- Robert Q Kim, Wireless Satellite Internet http://groups.google.com/group/unpaid-overtime http://evdo-coverage.com/satellite-wireless-internet.html 2611 S. Pacific Coast Highway 101 Suite 203 Unpaid Overtime and Break Laws Dept SD, CA 92007 206 984 0880

Aug. 8, 2007

Re: Missing library - faultrep.

by Peter Dons Tychsen

On Tue, 2007-08-07 at 23:15 +0200, Alexandre Julliard wrote: > Peter Dons Tychsen <donpedro(a)tdcadsl.dk> writes: > > >> You need to write a proper spec file with all exported functions, > > There are no exported functions (for now). So i guess an empty spec file > > is OK ? > > No, there are exported functions in the native dll, you have to > declare them as stubs. > Ah... OK, now i get the point. I will check out the original DLL, and copy the function into the spec. Thanks, /pedro

Aug. 7, 2007