wine-devel March 2010

wine-devel@winehq.org

102 participants
263 discussions

Re: Updated game checklist - columns now sortable
by Dan Kegel 20 Mar '10

20 Mar '10

On Thu, Mar 18, 2010 at 10:31 PM, Edward Savage <epssyis(a)gmail.com> wrote: > I would think a logical extension to this sort of work would be a > triage list of important bugs and regressions to be dealt with in > quick order. Well... that's kind of what bugzilla and the appdb are for. > I'm raising this as it seems very few gamers who use wine seem to > report bugs or do regression tests. At most they seem to report that > there is a problem on the forums or on the app page comments and leave > it at that. Yeah, historically, a few people (me included) have spent time watching the forums for that kind of report, and turned them into real bug reports. > If there was a centralised method of telling other gamers who are > prepared to do tests and reports that there is a specific problem with > xyz games it may improve the quality of information bug fixers have to > work with and get problems sorted out in a timely fashion. I suppose a way to make it really easy to test one's favorite set of games on the latest wine (as well as on any earlier release), and just click a big red 'Regression' button the moment one found one, might help. > Games are probably the biggest single application instance usage of > wine so having a specific case for this genre of application make > sense to me. Agreed. > As another suggestion I'd be prepared to write a WWN style monthly > report on the state of games running in wine. Including which ones no > longer work, what new ones work, and what major efforts need to be > undertaken for new games to work. I did a journalism elective last > semester so it probably wouldn't suck as bad as my last attempt at > writing a WWN. I would assume it would be totally independent of WWN > releases. Nah, just add it in to WWN, no reason to do anything separate. Start small! Just write a little section in http://wiki.winehq.org/RecentNewsQueue Heck, it is about time for another WWN, isn't it? - Dan [resending to list with permission]

1 0

Re: [PATCH 4/7] [Include]: created a wine only unwind.h include file for CPU specific unwind information
by Charles Davis 19 Mar '10

19 Mar '10

On 3/19/10 3:02 PM, Eric Pouech wrote: > > (and maps the definition to what MSDN states as field names) > > A+ > --- > > dlls/ntdll/signal_x86_64.c | 144 ++++++++++++++++++-------------------------- > 1 files changed, 58 insertions(+), 86 deletions(-) You forgot unwind.h. Chip

1 0

Re: [PATCH 1/2] d3d8/tests: Add some message processing to test_wndproc().
by Alexandre Julliard 19 Mar '10

19 Mar '10

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > --- > dlls/d3d8/tests/device.c | 22 ++++++++++++++++++---- > 1 files changed, 18 insertions(+), 4 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M d3d8.dll -T ../../.. -p d3d8_test.exe.so device.c && touch device.ok device.c:1616: Test failed: Expected focus 0x60100, got (nil). device.c:1618: Test failed: Expected foreground window 0x60100, got (nil). make[1]: *** [device.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

2 3

GSoC proposal: Implement the Explorer
by David Hedberg 19 Mar '10

19 Mar '10

Hi everyone, I too thought I'd see what my current thinking might be worth and therefore submit what you might call a rough (and perhaps somewhat too short) draft of my current "main proposal" for your tearing-apart pleasure. This is based on the idea with the same name available on the wine wiki, and is I guess sent to get some feedback on whether it would be considered useful and worthy of further refinement or not. ---------------------- Proposal for GSoC 2010: Implement the Explorer ---- The proposal is, in short, to implement the Windows Explorer as a replacement (or a complement) to winefile to browse the shell namespace, and also as an easily accessed test bed for the wine implementation of the windows shell components. It will also as a design decision involve implementing the new IExplorerBrowser interface available since Windows Vista which allows applications to host the explorer ( [1], [2] ). If there is time available after this I would also like to make explorer able to optionally show the task bar and start menu as noted in the wiki entry for GSoC ( [3] ) and in an enhancement request on wine bugzilla ( [4] ) . Very Rough Design Description: ---- This would, logically at least, involve mainly two parts: An implementation of IExplorerBrowser and IShellBrowser that uses the current implementation of the shell in wine, and an Explorer.exe that would be able to host IExplorerBrowser objects, interact with them and possibly handle showing the task bar and start menu. This should all be done in a way that is as compatible as possible with currently available shell extensions for the Explorer like custom toolbars, desk bands, and the like. If a choice have to made regarding what version of the Explorer to be compatible with, the current thought is to prefer the design decisions of the latter windows versions. For example, in Windows 7 (and Vista I assume), the explorer folder bar (showing the folder hierarchy) is replaced by a "navigation pane" that is available to all applications hosting the explorer through the IExplorerBrowser interface. As users of IExplorerBrowser would conceivably expect this pane to be available, making this a part of IExplorerBrowser would seem to make sense. Main goals --- * A functional implementation of explorer that can browse the shell namespace and be used for both file management tasks and manual testing of features of the wine shell implementation. * A working implementation of IExplorerBrowser. * Compatibility with shell extensions where it makes sense. Secondary goals ---- * An optional start menu/taskbar mode, mainly for use when running wine in virtual desktop mode. * Chances are that implementing the Explorer will turn up bugs in the wine shell implementation. Some of these bugs might hinder the main goal of implementing the Explorer in which case they would need to be investigated and fixed, and I suggest that those bugs (if any) that are not show-stoppers should be documented and - if there is time after finishing the main goals - investigated and (hopefully) fixed. Thoughts on the User Interface ---- The primary concern when it comes to the UI is that it should be functional. It would be loosely modeled after the Explorer in Windows, especially where needed for compatibility reasons (e.g. the navigation pane), but there might also be room for wine-specific features, look and behavior. On this point, it would perhaps make sense to seek some comments from other "heavy" explorer users and/or wine users. Quick summary of steps suggested ---- 1. Implement a simple initial container for IExplorerBrowser (explorer.exe) with basic support for navigating. Make sure it works with native IExplorerBrowser in windows Vista/7, and also write tests for the interface (if possible). 2. Implement IExplorerBrowser (and other necessary interfaces), test with new explorer.exe from step 1. 3. Refine explorer.exe as needed Optional: 4. Give explorer the ability to show the task bar/start menu, and/or 5. Fix bugs in the wine shell components found during the course of development. References: [1]. http://msdn.microsoft.com/en-us/library/bb761909(VS.85).aspx [2]. http://www.codeproject.com/KB/vista/ExplorerBrowser.aspx [3]. http://wiki.winehq.org/SummerOfCode#head-18241c95194e4e1c597bd2923cf296084f… [4]. http://bugs.winehq.org/show_bug.cgi?id=11629 ------------ Some notes and questions: In the above I am assuming that the Explorer and Internet Explorer should be regarded as separate applications as that seems to be the current state of affairs in the windows world. Is this assumption correct? I can also note that I am guessing (from visual inspection alone) that Vista/Win 7 uses IExplorerBrowser to implement IFileDialog (one of the GSoC ideas on the wiki). I might be wrong though, and I guess that it either way strictly speaking is an implementation detail that doesn't really matter to wine. Any thoughts, comments or questions on the above are very welcome. :-) I'm also idling in #winehackers with the nick sk atteola. Thanks, David Hedberg

1 0

Kernel mode tests?
by Damjan Jovanovic 19 Mar '10

19 Mar '10

Hi We've already got ntoskrnl.exe, hal.dll, mountmgr.sys and usbd.sys, with at least usbhub.sys hopefully coming soon, and I've been thinking it's a good idea to have some regressions tests for these. The problem, of course, is that on Windows these all run in kernel mode. So what would be a good way to structure these regression tests? We could cross-compile each test to a .sys file, install and load that, call it from user-space to run the tests, then unload and uninstall. This would work, but has the problem that a lot of complexity is necessary to set up the tests (driver signing, administrator access, UAC, etc.), and any bugs that would crash a user-space application would now crash Windows instead (we all know how easy that is :-). Another possibility might be to use a custom program loader to load the Windows .sys file being tested into user-space, the way we do now on Wine, and test it like that. This seems to preclude us from testing ntoskrnl.exe and hal.dll though. Any thoughts/ideas/suggestions? Thank you Damjan Jovanovic

3 2

Re: [PATCH 2/2] d3d9/tests: Add some message processing to test_wndproc().
by Henri Verbeet 19 Mar '10

19 Mar '10

On 19 March 2010 14:33, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > For some reason Windows XP allows device creation to be blocked by the lack of > message processing in wndproc_thread(). Also, many thanks to Wylda for helping debug this.

1 0

GSoC '10 Project Proposal: Buildbot Automated Testing System
by Arjun Comar 19 Mar '10

19 Mar '10

Hey all, I wanted to run my proposal for GSoC by everybody for some feedback and commentary, especially since student apps start in just 10 days. Any advice is greatly appreciated. GSoC 2010 Proposal: Buildbot Automated Testing System For those who aren't aware, http://buildbot.net/ provides an automated testing suite. I propose to set up a Buildbot system for Wine, using both a periodic scheduler, and a try scheduler. I also intend to create an easy configuration scheme that should keep maintenance fairly simple. In addition the test suite should be modular and easily extensible, ideally building on AppInstall and the existing test suite, as well as providing a means for new tests to be hooked in. --Buildbot-- To keep from seeming pedantic, I'll be brief with this one. Automating testing suites are awesome and help keep down the number of bugs/regressions that pop up. It'd be really cool if Wine had something like this. --Schedulers-- The periodic scheduler's purpose is to run the full test suite at particular time intervals. The timing on this one would need to be decided by the project. For example, it could be set up to run the full test suite half a week or so prior to the bi-weekly releases, or perhaps once a night if people care to read the logs that often. The try scheduler serves a slightly different purpose, namely to test on a patch by patch basis. Initially, this means that the patch would have to be directly uploaded to the test machine, though perhaps integration with patchwatcher may be possible (though I'm told that patchwatcher is fragile at best). Naturally, the full gamut of tests is probably not required for every single patch, and so a more selective (and fast) subset of the test suite can be run on the codebase after each patch, perhaps as limited as a compilation check. --Configuration-- Currently, one of the downsides of buildbot is that setup and configuration is all done by editing a python script that initializes all the various variables. This is clunky and adds a dependency to the person maintaining the system. Since the configuration script is full python, configuration can be moved out to a simple sh file (like most other Linux programs), and parsing done in the current configuration script. --Test Suite-- I would like to break apart the test suite into several, modular, components that can then be strung together in some order for a particular test run. Naturally, I intend to take advantage of the current test suite, and make use of AppInstall, integrating the two together to provide a comprehensive test suite. The conformance tests are also something that could potentially be included. Tying into the previous section, I'd also like to make it easy to attach new tests / test suites as people come up with new and better ways to stress test various things. This is the portion that may wind up being too much for a single person to do over the summer, though I doubt it. Buildbot appears to have decent support for this kind of thing, so it may just be wrestling it into doing what we need. Also, I should have a sample buildbot system ready to showcase soon. I'm currently testing it on a machine other than mine, but due to time constraints this weekend, I probably won't be able to send it out until early next week. Thanks for taking the time to read this. Once again, any advice is greatly appreciated. If you'd like any more detail or information, feel free to ask. It's entirely possible I forgot to include something. I look forward to working with all of you in the months to come. -- Arjun Comar, Rose-Hulman '12

5 7

ANGLE: wined3d in reverse?
by Dan Kegel 19 Mar '10

19 Mar '10

http://blog.chromium.org/2010/03/introducing-angle-project.html "We're happy to announce a new open source project called Almost Native Graphics Layer Engine, or ANGLE for short. The goal of ANGLE is to layer WebGL's subset of the OpenGL ES 2.0 API over DirectX 9.0c API calls. We're open-sourcing ANGLE under the BSD license as an early work-in-progress, but when complete, it will enable browsers like Google Chrome to run WebGL content on Windows computers without having to rely on OpenGL drivers. Current browser implementations of WebGL need to be able to issue graphics commands to desktop OpenGL to render content. This requirement isn't a problem on computers running OS X or Linux, where OpenGL is the primary 3D API and therefore enjoys solid support. On Windows, however, most graphics-intensive apps use Microsoft Direct3D APIs instead of OpenGL, so OpenGL drivers are not always available. Unfortunately, this situation means that even if they have powerful graphics hardware, many Windows machines can't render WebGL content because they don't have the necessary OpenGL drivers installed. ANGLE will allow Windows users to run WebGL content without having to find and install new drivers for their system. Because ANGLE aims to implement most of the OpenGL ES 2.0 API, the project may also be useful for developers who are working on applications for mobile and embedded devices. ANGLE should make it simpler to prototype these applications on Windows, and also gives developers new options for deploying production versions of their code to the desktop. We hope that other WebGL implementors and others in the graphics community will join us to make ANGLE successful! For more info on ANGLE and to access the code repository, visit the new project on Google Code or join our discussion group." So, it'd be interesting to see if it runs on Wine. I love stacking them blocks as high as I can :-)

3 2

Re: [PATCH 03/10] d3d9/tests: Extend the window proc / focus window tests.
by Paul Vriens 19 Mar '10

19 Mar '10

On 03/17/2010 09:59 PM, Henri Verbeet wrote: > --- > dlls/d3d9/tests/device.c | 103 +++++++++++++++++++++++++++++++++++++++------ > 1 files changed, 89 insertions(+), 14 deletions(-) > Hi Henry, These new tests (and also the d3d8 ones) introduce some timeouts on boxes. Mostly real boxes btw. Could you have a look? -- Cheers, Paul.

2 2

Re: [PATCH 1/2] d3dx9: Add d3dx9effect.h include file
by Henri Verbeet 19 Mar '10

19 Mar '10

On 17 March 2010 12:21, Christian Costa <titan.costa(a)wanadoo.fr> wrote: > > +typedef struct _D3DXPASS_DESC { > + LPCSTR Name; > + UINT Annotations; > + DWORD VSVersion; > + DWORD PSVersion; > + UINT VSSemanticsUsed; > + D3DXSEMANTIC VSSemantics[MAXD3DDECLLENGTH]; > + UINT PSSemanticsUsed; > + D3DXSEMANTIC PSSemantics[MAXD3DDECLLENGTH]; > + UINT PSSamplersUsed; > + LPCSTR PSSamplers[16]; > +} D3DXPASS_DESC; Which version of the SDK is this supposed to match? It doesn't match mine or MSDN. > +#define ID3DXBaseEffect_GetDesc(p,a) (p)->GetDesc(p,a) ... > +#define ID3DXBaseEffect_SetArrayRange(p,a,b,c) (p)->SetArrayRange(p,a,b,c) Those don't like right for C++. The other interfaces have similar issues, including: > +#define ID3DXEffect_CommitChanges() (p)->lpVtbl->CommitChanges(p) and > +#define ID3DXEffect_GetVertexShader(p,a,b) (p)->>GetVertexShader(p,a,b) However, my SDK doesn't have C object macros for any of the interfaces in d3dx9effect.h.

2 3

← Newer
1
...
9
10
11
12
13
14
15
...
27
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 March 2010