wine-devel July 2009

wine-devel@winehq.org

116 participants
249 discussions

Build a6beb5066884 w2k-sp4-fr-netwrkdrv test results
by Nicolas Le Cam 07 Jul '09

07 Jul '09

Hello, Strangely the network drive has been disconnected during the test. Could you remove it ? I will rerun and resubmit it after checking that results are correct. -- Nicolas Le Cam

1 0

Re: [2/3] WineD3D: Make context_attach_surface_fbo fbo aware
by Henri Verbeet 06 Jul '09

06 Jul '09

2009/7/6 Stefan Dösinger <stefan(a)codeweavers.com>: > Subject: [PATCH] WineD3D: Make context_attach_surface_fbo fbo aware I hope you meant "sRGB" there. > context_apply_attachment_filter_states((IWineD3DDevice *)This, surface, TRUE); > > - GL_EXTCALL(glFramebufferTexture2DEXT(fbo_target, GL_COLOR_ATTACHMENT0_EXT + idx, surface_impl->glDescription.target, > - surface_impl->glDescription.textureName, surface_impl->glDescription.level)); > + switch(srgb) > + { > + case SRGB_BOTH: > + ERR("SRGB_BOTH fbo attachment requested\n"); > + /* drop through */ > + case SRGB_SRGB: > + GL_EXTCALL(glFramebufferTexture2DEXT(fbo_target, GL_COLOR_ATTACHMENT0_EXT > + idx, surface_impl->glDescription.target, > + surface_impl->glDescription.srgbTextureName, surface_impl->glDescription.level)); > + break; > + > + case SRGB_ANY: /* TODO: Keep track of the last use */ > + case SRGB_RGB: > + GL_EXTCALL(glFramebufferTexture2DEXT(fbo_target, GL_COLOR_ATTACHMENT0_EXT > + idx, surface_impl->glDescription.target, > + surface_impl->glDescription.textureName, surface_impl->glDescription.level)); > + break; > + } I don't think SRGB_BOTH and SRGB_ANY make sense here. I also don't think this can work like this, context_apply_attachment_filter_states() needs to be aware of which texture was requested.

2 1

Re: [3/3] WineD3D: Update sRGB copies with fbo_blit if possible
by Henri Verbeet 06 Jul '09

06 Jul '09

2009/7/6 Stefan Dösinger <stefan(a)codeweavers.com>: > +void fbo_srgb_load(IWineD3DDevice *iface, IWineD3DSurface *surface, BOOL dst_srgb) > +{ > + IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface; > + IWineD3DSurfaceImpl *surf = (IWineD3DSurfaceImpl *) surface; > + > + ENTER_GL(); This code needs an active GL context.

2 1

Re: crypt32: Update german translation (depends)
by Paul Vriens 06 Jul '09

06 Jul '09

André Hentschel wrote: > This is for the case Paul Vriens patch gets in > (http://www.winehq.org/pipermail/wine-patches/2009-July/075450.html) > --- > dlls/crypt32/crypt32_De.rc | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > > ------------------------------------------------------------------------ > > Hi André, There is no dependency here. I merely changed one of the English resources, I didn't add one. -- Cheers, Paul.

2 2

Re: Try #2: user32: Windows test request (cursors/icons)
by Daniel Santos 06 Jul '09

06 Jul '09

> The way you are checking for Win9x is discouraged. We > rather not have GetVersion() but instead rely on behaviour > to check for Win9x. The checks I've inserted for Win9x are strictly to prevent crashing the OS. There were some previous checks in there and since I've had to add more checks, I made an inline function for it. Prior to NT, ms wasn't checking validity of handles in many cases, so calls to SetCursor and DestroyCursor with known invalid handles are what I believe is bringing them down. All of those should now be disabled on win9x. I wouldn't normally focus on such a thing so intensively (passing invalid handles), but this is precisely the type of issue that's been causing hangs and other annoyances in Lord of the Rings Online since their upgrade late last year, which started me working on these fixes. > test_DestroyCursorIcon returns a BOOL but most of the calls > don't use the returned value. A few do but then the return > value is not checked against, for example: > 996 /* Clean up. */ > 997 ret = > test_DestroyCursorIcon(handle, TRUE, TRUE, __LINE__, > 0xdeadbeef); Yea, when I added test_DestroyCursorIcon, I replaced all of the calls to DestroyCursor and DestroyIcon that didn't have special checks like ok(!ret, broken(ret), "..."), but I wanted the return value to be available in case it was needed later in the test code. I've removed all of the cases where the return value was captured in a variable and then never used and now nothing uses the return value, but I figure it's probably better to leave it returning the value than remove it in case some test modification later needs it for something. > There are also some spelling fixes needed (minor though, > I'd guess): hehe, lots of spelling errors, thanks! > 22 * FIXME: Add tests for CreateCursor and verify > that width & hight cannot exceed > Btw. This FIXME doesn't look right. The problem is specifically with the CreateCursor function. When I analysed it, I couldn't find any place that max height & width were checked and the GetSystemMetrics calls for those values are just hard-coded to return 32. Personally, I don't understand the X Windows implications well enough to delve further at this point, but I know that we are definitely missing tests for CreateCursor as well as the hidden 16-bit API function DestroyIcon32() which I've modified in my patches (yet to be submitted). > 78 * shouldFail [I] Rather of not it should > fail > Not sure what you are trying to say here. I clarified this documentation better. Essentially, TRUE if the call to DestroyCursor or DestroyIcon is expected to fail. I think I'll have the time so I'm going to try to get a new patch to you today. Thanks! Daniel

1 0

Re: Try #2: user32: Windows test request (cursors/icons)
by Daniel Santos 06 Jul '09

06 Jul '09

Thank you again for your time, effort and feedback! I wont have much time today, but I'll get another rendition as soon as I can. Daniel --- On Mon, 7/6/09, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > From: Paul Vriens <paul.vriens.wine(a)gmail.com> > Subject: Re: Try #2: user32: Windows test request (cursors/icons) > To: daniel.santos(a)pobox.com > Cc: wine-devel(a)winehq.org > Date: Monday, July 6, 2009, 3:49 AM > Daniel Santos wrote: > > Thanks again for testing this for me, Paul. I > have modified the tests so that they should pass and I've > skipped tests on win9x that I suspect are causing the blue > screens (personally, I doubt it's due to VMware). > > > > I moved the new test functions to the top of the file, > but I didn't remove the comments. I can shorten them > if preferred, but I personally prefer to have functions well > documented. > > > > So if you or anybody else could test this again for > me, I would greatly appreciate it. > > > > I guess it will be AJ's call in the end if these types of > comments are necessary. I don't have a strong opinion about > them. > > The way you are checking for Win9x is discouraged. We > rather not have GetVersion() but instead rely on behaviour > to check for Win9x. > > test_DestroyCursorIcon returns a BOOL but most of the calls > don't use the returned value. A few do but then the return > value is not checked against, for example: > > 996 /* Clean up. */ > 997 ret = > test_DestroyCursorIcon(handle, TRUE, TRUE, __LINE__, > 0xdeadbeef); > > There are also some spelling fixes needed (minor though, > I'd guess): > > (hight -> height) > 22 * FIXME: Add tests for CreateCursor and verify > that width & hight cannot exceed > Btw. This FIXME doesn't look right. > > 78 * shouldFail [I] Rather of not it should > fail > Not sure what you are trying to say here. > > (consistenit -> consistent) > (accross -> across) > 166 * Only use on very simple test cases where > behavior is consistenit accross > > (destory -> destroy) > 1365 /* Try to destory a bunch of > crap */ > FWIW, I don't like the word crap, but that's probably just > me. > > Test results: > > Win95: > cursoricon.c:1003: Test failed: Last error is 3735928559 > (0xdeadbeef), expected ERROR_INVALID_CURSOR_HANDLE (1402). > cursoricon.c:1004: Test failed: Last error is 3735928559 > (0xdeadbeef), expected ERROR_INVALID_CURSOR_HANDLE (1402). > cursoricon.c:305: Test failed: DestroyCursor returned 1, > expected FALSE. > cursoricon.c:305: Test failed: Last error is 3735928559 > (0xdeadbeef), expected 1402 (0x57a). > cursoricon.c:307: Test failed: DestroyIcon returned 1, > expected FALSE. > cursoricon.c:307: Test failed: Last error is 3735928559 > (0xdeadbeef), expected 1402 (0x57a). > cursoricon: 6 tests executed (0 marked as todo, 0 > failures), 0 skipped. > cursoricon: 495 tests executed (0 marked as todo, 6 > failures), 0 skipped. > > Running it a second time hangs the box !!! > > Win98: > > Logged the output to file but then notepad.exe crashed. > Soon after that the system hangs !!!!! > > So Win9x needs definitely some more work. > > NT4: No failures. > > XP: No failures. > > Didn't test W2K, W2K3 and Vista as the output previously > was the same as XP. > > -- Cheers, > > Paul. >

1 0

installshield and 3GB ram (affects Dragon Naturally Speaking)
by Dan Kegel 06 Jul '09

06 Jul '09

Jay, does the problem affect any other apps? Until some confirms the patch works and/or that other apps are affected, the bug might not get much attention. - Dan ---------- Forwarded message ---------- From: Jay Starkman <jay(a)starkman.com> Date: Mon, Jul 6, 2009 at 5:38 AM Subject: Bug 15708 To: bugs-admin There's a patch posted for Bug 15708, LARGE_ADDRESS_AWARE flag. In attempting to install Dragon Naturally Speaking 7.0, all of us have gotten the message "DNS requires...at least 128MB RAM. Your system has...-673MB RAM." The setup program sees negative RAM on systems with over 2G. Since the patch is already out there, is it possible to compile the next iteration WITH the patch? I tried compiling my own WINE using the patch, but it caused problems and the WINE I compiled didn't work at all. I don't see Bug 15708 in your list of Bugs Scheduled to be Fixed before WINE 2.0 is released. There appears to be a simple patch that fixes it. Wouldn't it be possible to incorporate that patch into your next Wine_1.1.26? -Jay Starkman -------------------------------------------------------------------------- Jay Starkman, CPA Voice: 404-636-1400 Fax: 404-636-1130 2531 Briarcliff Road, Suite 116 e-mail: j(a)starkman.com Atlanta, Georgia 30329 Internet: http://www.starkman.com --------------------------------------------------------------------------

1 0

Re: crypt32: Add "Disallowed" to CryptFindLocalizedName
by Paul Vriens 06 Jul '09

06 Jul '09

Aurimas Fišeras wrote: > "Disallowed" is Used in Chrome. > > > ------------------------------------------------------------------------ > > Hi Aurimas, I was trying to update the NL resources but wasn't sure what to translate to. Disallowed on an English Windows version is actually "Untrusted Certificates". I will sent a "fix" for the English resources as the above makes more sense then 'Disallowed', I think. -- Cheers, Paul.

1 0

Re: why is Kronenberg's Wine/Mac work blacklisted on winehq?
by James Mckenzie 06 Jul '09

06 Jul '09

>James McKenzie wrote: >>Something that I do have to point out is that freetype, a very >important >>library for Wine is not shipped with XCode nor MacOSX. We have to >>include it. > >Huh? On my 10.5.7 Leopard system, Wine was able to find FreeType -- with >LD_LIBRARY_PATH guidance. And I have nothing but >- MacOS (with iLife preinstalled) >- (selected packages from) the Xcode install DVD and >- XQuartz 2.3.3.2 >installed on that box. > >Did you install Apple's X11 before installing XQuartz, as the XQuartz >site recommends? > >Are you mislead by the following error message? Possibly. I will check my system and see if libfreetype exists in /usr/X11/lib. James McKenzie

1 0

Re: Direct3D 10 Current Status
by Henri Verbeet 06 Jul '09

06 Jul '09

Chris Smowton wrote: > Hello, > > First of all my apologies if you're the wrong person to ask; I got your > name by searching the wine-cvs list for who seemed to be doing most > D3D10 work. If you're not the right person to ask the following > questions, I'd appreciate if you'd advise who if anyone I'd be better > off asking. > In general, wine-devel is the most appropriate place for questions like these. > Now then, I'd like to ask you about the current state of Wine's D3D10 > support. I'm looking at how much effort will be required to gain D3D10 > support for virtual machines, and Wine's D3D9 code has of course been > used in a few virtualisation solutions. Here are my specific questions: > > 1. Would I be right in assuming that D3D10 support is currently very > basic -- at the level of user apps being able to create a device and > context, but not perform rendering as of yet? > Pretty much. We can do some rendering, but don't expect anything beyond very simple sample applications to work. > 2. What about shaders -- has the Wine project made much progress > supporting the new shader models? > We have some initial SM4 support. We can reuse a lot of the infrastructure for previous shader models, but the SM4 binary format isn't publicly documented anywhere, as far as I'm aware. > 3. Whilst of course Wine doesn't need to do this, have you gained any > insight into how the MS D3D10 usermode runtime interfaces with the DWM? > I assume that simply replacing d3d10.dll on a Windows system with the > hope of remoting rendering is not practicable because the runtime > presumably creates the window's primary surface with a shared handle, > and passes that handle on to the DWM to perform rendering. I see no > reason why that internal D3D usermode runtime <--> window manager > process interaction ought to be documented, and so a replacement for > d3d10.dll on a real Windows system would seem like it would necessarily > involve reverse engineering that process, but perhaps I'm wrong? > We didn't really look. I'd expect that to be done by dxgi rather than d3d10 or d3d10core though. Henri

1 0

← Newer
1
...
17
18
19
20
21
22
23
24
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2009