September 2010 - Wine-devel

Re: [PATCH 1/4] kernel32: add test for WaitForSingleObject with lower 2 bits of handles set
by Paul Vriens 22 Sep '10

22 Sep '10

On 09/22/2010 07:53 PM, Peter Oberndorfer wrote: > + if(GetVersion()& 0x80000000) > + { > + win_skip("Handles work differently on win9x\n"); > + return; > + } > + > + signaled = CreateEventW(NULL, TRUE, TRUE, NULL); Hi Peter, You could just as easily check for the last error of CreateEventW which would be ERROR_CALL_NOT_IMPLEMENTED on win9x/winME. This is usually prefered above GetVersion(). I must say that I do see other GetVersion() calls in the kernel32 tests. The fact that you are using win_skip will make the tests fail if you run Wine in Win98 mode, but I guess nobody does that. -- Cheers, Paul.

1 0

Re: mscoree: Search for Mono in some predefined paths before using the registry.
by Alexandre Julliard 22 Sep '10

22 Sep '10

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > + hfind = FindFirstFileW(wildcard, &find_data); > + > + if (hfind == INVALID_HANDLE_VALUE) return FALSE; > + > + do { > + if (find_data.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) > + { > + strcpyW(mono_path, folder); > + strcatW(mono_path, slash); > + strcatW(mono_path, find_data.cFileName); > + > + found = find_mono_dll(mono_path, mono_dll_path, &abi_version); > + } > + } while (!found && FindNextFileW(hfind, &find_data)); That seems quite dangerous. I don't think we want to use any random mono dll we find, especially in a way where we can't predict which one will be used. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/4] kernel32: add test for WaitForSingleObject with lower 2 bits of handles set
by testbot＠testbot.winehq.org 22 Sep '10

22 Sep '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5404 Your paranoid android. === W2K8SE (32 bit sync) === sync.c:856: Test failed: DeleteTimerQueueTimer sync.c:857: Test failed: ChangeTimerQueueTimer

1 0

Re: About the Gallium Direct3D 10/11 work
by Luca Barbieri 22 Sep '10

22 Sep '10

> I do have a concern which I addressed in the Wine Users mailing list: > > Wine is not only used with Linux, it is also used with other *nix implementations, to include the one that use, MacOSX. Will there be a port to this platform or some > sort of 'hook' that will allow the use of your drivers on this platform. If you want to use the Gallium D3D10/11 implementation on Mac OS X, you will need a Gallium driver that can run on Mac OS X. The software renderers probably already work. For hardware acceleration, my proposal is to write a new Gallium driver that uses OpenGL underneath and can thus run on any platform providing OpenGL. I think that implementing such a Gallium driver is easier than implementing D3D10/11 from scratch, and will also benefit Mesa, since it will be possible to test additions to the Gallium interface without needing to write hardware-specific code or writing software rasterization code. I'm not sure if I'll write such a Gallium driver myself. Contributions would be greatly welcome. It's a fun project and certainly much easier than writing an actual hardware driver. Alternatively, you could port the kernel DRM and drivers to Mac OS X and other systems, but that's much harder and much less user friendly. At any rate, nothing stops Wine from also implementing D3D10/11 using WineD3D or OpenGL, and using that if a Gallium driver is not available. Note however that D3D10/11 are totally different from D3D9, so I'm not sure how much you can share (especially if you want a fast implementation, which may be impossible anyway over OpenGL).

1 0

About the Gallium Direct3D 10/11 work
by Luca Barbieri 22 Sep '10

22 Sep '10

> If any one wishes to make any comments I'll include those as well as > contacting Luca Barbieri (?) or who ever is relevant to this over at > Gallium3D. Here I am :) As you have read, this is an initial (but working and with most of the code there) implementation of the D3D10/11 APIs. The plan is to ship all the core interfaces (ID3D10Device, ID3D11Device, ID3D11DeviceContext and supporting ones) in Mesa/Gallium, and make it available to native Linux applications. In addition, some Wine dlls will be provided with just the minimal amount of code to hook the Gallium implementation to Wine's HWNDs. They could be shipped either as part of Mesa or as part of Wine. The initial plan would be to ship them as part of Mesa, but if having anything else than Wine ship Wine DLLs is a problem, this could be revisited. Wine would however need to provide all the non-core APIs, such as D3DX and effects, which I don't think anyone will implement for Gallium. The HLSL compiler might come from the GLSL compiler, especially if the Intel team writing it were to decide to support Cg in addition to GLSL. Alternatively Wine could provide it. In the meantime, Microsoft DLLs will be used for all these. > like the fact that it's C++ C++ dramatically increases productivity, especially when implementing COM interfaces, which in C require a lot of unnecessary boilerplate. >needs X11 windows, The current implementation does, but it's very easy to port to anything else supported by Gallium (currently KMS consoles, fbdev and GDI). > and is limited to Mesa drivers, It's limited to Gallium drivers. If desired, this limitation can be circumvented by writing a Gallium driver that uses GL3/4 underneath. I think this could be the best way forward. Even if Wine were to finish its own D3D10/11 implementation over OpenGL, Gallium would still have its own implementation, because going through OpenGL causes massive unnecessary overhead, reliability problems and difficulty of debugging. Furthermore, this allows to provide Direct3D 10/11 features even if Mesa doesn't yet support the corresponding OpenGL features. In fact it's possible that Mesa will make available features like Direct3D 11 tessellation first in the d3d11 state tracker, and only later in the OpenGL state tracker. >from talking to Luca on IRC it sounds > like this is just the "easy" parts like e.g. resource transfers, > texture format conversion and basic draw calls Not at all. This is a full implementation of ID3D10Device, ID3D11Device, ID3D11DeviceContext and all the interfaces required by them, except for deferred contexts and things not yet supported by Gallium. It should support almost everything in the D3D 9.3 feature level, some of the D3D10.0 feature level and almost nothing of the D3D11 feature level. This is mostly due to the current limitations of Gallium. It includes a shader translator which supports all SM4 opcodes, although not all addressing modes and declarations are supported, and it has been tested quite little. Also some things like resinfo and switch/case/default/endswitch aren't yet implemented by most Gallium drivers. It supports texturing with separate resource and samplers by putting every (resource, sampler) pair in a traditional "texture unit". This will change for DX10 hardware once Gallium gets support for distinct resources and samplers. Of course, it's a very young implementation with almost no tests, so it will surely need a lot of small bug fixes to get fully working. It's much more advanced than the Wine implementation, which apparently doesn't seem to even implement OMSetRenderTargets, which is obviously essential for rendering anything. > The *hard* parts are figuring out things > like the shader and effect formats in a clean way. Both are fully documented. Microsoft ships an header for the shaders and source code for Effects11 at least. Shader parsing is already fully done. The "hard part" is doing the Gallium hardware drivers, and making them competitive with the proprietary ones. Implementing Direct3D 10/11 doesn't really have any truly hard part, just a lot of work, especially for the auxiliary parts like the HLSL compiler, D3DX and effects. >Luca took a bit of > a shortcut there by not doing effects at all, and using the DDK for > the shader format. Yes, and that's seem a reasonable move. Effects can be layered on top of the core API and thus are out of the scope of a Gallium state tracker. > That may or may not be ok, depending on what's > actually in the DDK, but I'm not going to take that risk for no good > reason. As far as I can tell, there is no risk. The EULA doesn't even attempt to prevent alternative implementations and it's just an header file, not source code. As far as I can tell, the DDK license does not seem more restrictive than the Windows SDK one > To my knowledge the effect format > isn't documented anywhere.) As far as I know, Microsoft ships full source code for the Direct3D 11 effects implementation at least, and thus it is fully documented in that. Even if Wine developers don't want to just read the Microsoft source code, you can have someone read it and document it. At any rate, reading source code and implementing based on the ideas learned is perfectly legal. Note however that this has _not_ been done for the code in Gallium, especially because it only implements core APIs, and Microsoft (obviously) doesn't release source code for them at all. Even the C++ IUnknown implementation and COM smart pointer is _not_ based on the ones in ATL or MFC, which I haven't even examined. > Suffice it to say that I'm extremely unhappy with > the way D3D development is currently going. I think this is unjustified. Getting a new, working, Direct3D 10 and 11 implementation seems to me quite a positive thing for Wine. It would be great if we could get past this initial impression and have Mesa and Wine work together on this. If you have any concerns, they can be addressed.

1 0

Re: winspool.drv: Support pDevMode field in {Get/Set}Job
by Detlef Riekenberg 22 Sep '10

22 Sep '10

Hi Vitaly. Thanks for fixing printing issues. You use sizeof(DEVMODEW) in you patch, but the correct size is: devmodeW->dmSize + devmodeW->dmDriverExtra You should change the FIXME in the comment of get_job_info_2 to a real FIXME, when unicode is FALSE I'm fine with the unicode - only patch for now, as the related code has to move to localspl later (localspl is unicode only). Thanks -- By by ... Detlef

2 1

Re: user32: Uncomment the GetWindowPlacement() test, fill the test data with real values. Take 2.
by testbot＠testbot.winehq.org 22 Sep '10

22 Sep '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=5397 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Re: USB Device Support
by Damjan Jovanovic 22 Sep '10

22 Sep '10

On Wed, Sep 15, 2010 at 1:39 AM, Eric Durbin <eadurbin(a)gmail.com> wrote: > > > On Tue, Sep 14, 2010 at 10:48 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> > wrote: >> >> When last I heard from Alexander Morozov (October 2009), he wasn't >> working on those patches much, and had no interest in sending them to >> wine-patches. >> >> I did some work on USB since then, and sent some patches starting from >> around March 2010 (too many attempts to list, search for them). Most >> were rejected. >> >> The USB story goes as follows: >> >> My libusb patch was rejected IIRC because the libusb situation was >> unclear. There's the old libusb-0.1 and the new more powerful >> libusb-1.0. IIRC each *nix hacked up its own specific variation of >> libusb that had to be detected specifically, and some *nixes didn't >> support the libusb-1.0 interface yet (libusb-1.0 itself only supports >> Linux and MacOS when last I checked, and they were doing a Windows >> port). >> >> The ntoskrnl that Wine currently emulates is total bogus: one process >> per driver, drivers all in separate processes from each other. On >> Windows there's a single address space for all drivers and they can >> communicate amongst themselves. I don't think inter-driver >> communication is that crucial initially, but it will be eventually >> (eg. last I heard, the iPod driver stacks on top of USBSTOR.SYS, and >> multi-function USB devices can use a different driver for each >> interface - these may communicate among themselves with private ioctl >> requests). The big problem with the multi process situation is >> hardware sharing: how do you set it up so each driver accesses its own >> and only its own hardware? >> >> Drivers either start on system startup (Wine starts those with the >> first process that starts), or get loaded on-demand as the hardware is >> plugged in. Most drivers should install themselves to be loaded >> on-demand. Who loads those and how? >> >> Windows uses USBHUB.SYS to do device I/O and load drivers on demand. >> Alexandre didn't want that dll because it exports nothing (all its >> features are accessible via internal ioctls), and suggested adding the >> features to USBD.SYS instead, which we already have and which has >> exports. Now USBD.SYS is linked to by most (but not all) USB drivers >> so (most of the time) it automatically gets loaded into each one - >> great right? - but it has no idea which driver it got loaded with, nor >> a straightforward way to determine which device(s!) that driver wants >> to drive. Also, since most drivers only load on-demand, the driver >> will never load, and thus this won't work unless we load those drivers >> on startup instead. The other approach, which I tried, was to get >> Wine's mountmgr.sys to detect USB devices using HAL, then pass them to >> a loaded-on-startup instance of USBHUB.SYS using a Wine-private ioctl, >> which would detect the driver for the device and launch a new instance >> of itself that would make a device object and load the driver to >> attach to it. This was all a bit a hack (USBHUB.SYS uses environment >> variables to tell the child which device and driver to run) and >> Alexandre also didn't the the Wine-private ioctls. Alexander Morozov's >> patch did things the Windows way: all drivers in one ntoskrnl process >> - this won't work properly in Wine for years, if ever, since ntoskrnl >> is so incomplete and one bad driver will crash them all. Another >> possibility could be to keep drivers in separate processes, but allow >> inter-process communication, but I see serializing IRPs between >> processes as being complex and very slow. >> >> Driver installation is also quite a mission. Windows detects that the >> hardware doesn't have a driver installed, and then generates the >> device ID and compatible IDs and searches .INF files for one that can >> support it. Our setupapi needs to be substantially improved to be able >> to do the same, and some newdev.dll and manual INF parsing work to >> install the driver may also be necessary, and I can already think of >> cases where even class installers will be necessary too :-(. >> >> Wine only sends DeviceIoControl to drivers. For anything non-trivial, >> other file-related user-space functions (at least ReadFile, WriteFile) >> need to go to the driver too. The infrastructure for this does not >> even exist yet, and would probably affects wineserver as well. >> >> Regression tests for ntosnkrl.exe and kernel drivers don't exist, and >> are difficult to come up with, since we'd have to compile and load >> drivers on Windows and run tests that don't crash Windows :-). >> >> So the architecture for USB support is tricky to say the least. But >> I'd still like to resume work on my USB patches some time soon, would >> you like to help? > > I'd be willing to help if you want some assistance. I don't know much about > the subject yet, but I'm reading programming the wdm atm. Firstly I'd like to find a cheap simple USB device that we can actually get working quickly. Earlier I was experimenting with my Blackberry driver, but that's not going far quickly, since it's a multi-protocol device (modem, mass storage, and proprietary protocols, etc.). I've got a USB scanner that's unsupported by SANE, but that needs ReadFile/WriteFile which is a lot of work by itself. Same with USB flash sticks. I can get hold of an iPod but that's probably the most complex, needing to stack on top of USBSTOR.SYS IIRC. Ironically drivers for the easy hardware (USB mice) are unnecessary anyway, since the Linux drivers are good enough, and the Windows drivers probably need to be driven from user-space by bits Wine doesn't have. Maybe I should give up and just get something partially working, add the rest later gradually. Any ideas? Then it's largely a matter of design. I think Alexandre's idea (process per driver, host all USB code in USBD.SYS) is good enough initially. Essentially the first steps would be: 1. libusb integration 2. driver loading hacks 3. driver -> devices lookup 4. usb bus enumeration for devices 5. create pdo and fdo for each device 6. AddDevice to driver 7. perform I/O for IRPs coming down from the driver using libusb I/O functions That should get a very basic driver (that only uses the control pipe) working. I'll try to get some of this done later this week/weekend. Damjan

3 11

D3D via Gallium
by Zachary Goldberg 22 Sep '10

22 Sep '10

Hello, I found the following article/commit very interesting this morning. Has anybody else been looking at this and put thought into whether it will work with Wine? http://cgit.freedesktop.org/mesa/mesa/commit/?id=92617aeac109481258f0c3863d… http://www.phoronix.com/scan.php?page=article&item=mesa_gallium3d_d3d11&num… -Zach

5 5

Re: user32: Uncomment the GetWindowPlacement() test, fill the test data with real values.
by Alexandre Julliard 21 Sep '10

21 Sep '10

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > --- > dlls/user32/tests/msg.c | 141 +++++++++++++++++++++++++--------------------- > 1 files changed, 77 insertions(+), 64 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so msg.c && touch msg.ok msg.c:10881: Test succeeded inside todo block: expected 120,120-210,210 got 120,120-210,210 msg.c:11314: Tests skipped: Skipping DBCS WM_CHAR test in SBCS codepage 'ANSI Latin 1' make[1]: *** [msg.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0