September 2007 - Wine-Devel

Re: Wine gets exposed in Norway :)

by Alexander Nicolaysen Sørnes

On Thursday 27 September 2007 19:58:29 Tomas Zijdemans wrote: > The most visited and respected technology related site in Norway (210 > 000 unique norwegian hits a week), is now launching a series of articles > where they will test 3 games thoroughly in wine each month! > > Today the first article tested Fahrenheit, Guild Wars: Nightfall and > Civilization IV: Warlords. The results where good and focused on what > users should do to make them work smoothly. > > Hope this is an encouragement for Stefan and all the others of you > working to get games working :) Please note that this is a secret website, so we Norwegians cannot send the website address to the list. :) Alexander N. Sørnes

Sept. 27, 2007

Wine gets exposed in Norway :)

by Tomas Zijdemans

The most visited and respected technology related site in Norway (210 000 unique norwegian hits a week), is now launching a series of articles where they will test 3 games thoroughly in wine each month! Today the first article tested Fahrenheit, Guild Wars: Nightfall and Civilization IV: Warlords. The results where good and focused on what users should do to make them work smoothly. Hope this is an encouragement for Stefan and all the others of you working to get games working :)

Sept. 27, 2007

Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation

by Roy Shea

Howdy, On Thu, Sep 27, 2007 at 02:55:40PM +0200, Stefan D?singer wrote: > Am Donnerstag, 27. September 2007 12:58:46 schrieb Alexandre Julliard: > > Roy Shea <roy(a)cs.hmc.edu> writes: > > > Resubmission of a bare bones bits implementation. > > > > There is no bits.dll on any Windows version I've checked. Where does > > this dll come from? > It is an extra download, but requires a WGA check. Argh! My bad. I just finished looking into this a bit more and here is my current understanding. You can download "bits" from Microsoft, but I don't think you are going to get a bits.dll out of it. The dll that I'm working on is intended to stand in for the collection of dlls available at http://support.microsoft.com/?kbid=923845, although most Windows users should already have the dlls: Qmgr.dll -> Very old version of bits that appears to be heading towards deprecation. Bitsprx2.dll -> Base version of bits that I'm trying to implement for wine. Bitsprx3.dll -> Version 2.0 of bits adding features to the base version (gotta love the off by one numbering scheme!). Bitsprx4.dll -> Newest extensions to bits available on some systems. As far as I can tell the Bitsprx2.dll is generated from Bits.Idl, that is equivalent to the bits.idl I'm developing. Since my dll is not acting as a proxy, at least as I understand proxy dlls (I'm still digging through COM books), I thought it would be more accurate to not include the "prx" in the name of my dll. Simply changing the name from bits.dll to bitsprx2.dll is easy enough, but I worry that the semantics between a regular dll and a proxy dll would cause confusion or problems. My understanding of proxies is that they allow "cross-apartment access" to a COM object. Ideally, I'd like to first get in process support of bits (CLSCTX_INPROC_SERVER object instantiation), and then worry about support across apartments. I am new to both COM and Wine and I may be a bit off in my understanding of some of these points. I would love any advice on how to get my current code in shape for Wine. In particular, should I provide a full proxy version of bits and resubmit it as Bitsprx2.dll or should I introduce basic functionality first, perhaps through bits.dll or something else, and then jump in on the proxy code. Thanks for the advice! -Roy

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Chris Morgan

> >> > >> The right way is to use XInput, and work with the X.org guys to fix > >> what's necessary to make it work for our needs. > >> > > I don't see how will that solve (c,d,f,g)? Also how long should we wait on > > that? Year? 5 years? I looked at the current Xorg source and it still > > explicitly forbidding opening of the mouse and keyboard devices. Yet some > > one mentioned they would change that. > > > > I'm talking about solutions right now, so we can move on and fix other > > related issues, not sit and wait for some one to give us what we need. > > We can always send patches to the projects for the things we would like > to see improved support. That was the case for kernel, gnome, freetype, > binutils, cygwin, mingw, and many others. > > -- I'd suggest we see if we can get someone from X.org involved in the discussion. While this wouldn't result in a fix today it would certainly let us get cooperation which is likely to result in a better fix. We might have to wait half a year for the full fix to get out there but we can always provide a short term work around and see if we can't run-time detect the improved correct way of doing it. Chris

Sept. 27, 2007

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function

by Juan Lang

Hi Konstantin, > I have one more question. To add realization of new function, I can add it in > struct WNetProvider? For example: > > typedef struct _WNetProvider (snip) > PF_NPGetResourceInformation getResourceInformation; //my added function > } WNetProvider, *PWNetProvider; > > It is correct? Yes, precisely correct. --Juan

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Stefan Dösinger

Am Donnerstag, 27. September 2007 17:23:42 schrieb Vitaliy Margolen: > Stefan Dösinger wrote: > > 1) Multiple Mice. If there are 2 mouse devices, the X server manages them > > and combines them to one core pointer. These configurations are pretty > > common, for example on laptops with touchpad + usb mouse. > > This is true, each mouse will have it's own device. However I have never > seen a single person who used 2 or more mice while playing games <g> I do That's the great thing about laptops, at least when playing Battlefield 1942. You can keep an aircraft controlled with one hand, but for serious fighting you need the real mouse. Imagine a LAN Party, running bf1942, some pizza next to you. With the thumb on the touchpad and the WASD keys, you can take off with a plane and steer to the battle, while the right hand is free to grab a glass or some pizza. Yes, it makes the keyboard and mouse oily and there's a risk to poor liquid over the laptop, but it works with the current dinput code :-) > Not true. That's what so great about evdev driver - it's unified. > Everything is handled by the kernel, and we get common interface to things > like axis movement and buttons. I have tested this with USB and PS/2 mouse > - works properly in each case. Should all mouse types create a event device node? Maybe I've done something wrong on my new laptop. On the old laptop, the touchpad had such a node, on the new one it doesn't.

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Dmitry Timoshkov

"Vitaliy Margolen" <wine-devel(a)kievinfo.com> wrote: > Alexandre Julliard wrote: >> Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: >> >>> Anything else I missed? Are there are any better ways to solve these >>> problems? Any other ways at all? >> >> The right way is to use XInput, and work with the X.org guys to fix >> what's necessary to make it work for our needs. >> > I don't see how will that solve (c,d,f,g)? Also how long should we wait on > that? Year? 5 years? I looked at the current Xorg source and it still > explicitly forbidding opening of the mouse and keyboard devices. Yet some > one mentioned they would change that. > > I'm talking about solutions right now, so we can move on and fix other > related issues, not sit and wait for some one to give us what we need. We can always send patches to the projects for the things we would like to see improved support. That was the case for kernel, gnome, freetype, binutils, cygwin, mingw, and many others. -- Dmitry.

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> Anything else I missed? Are there are any better ways to solve these >> problems? Any other ways at all? > > The right way is to use XInput, and work with the X.org guys to fix > what's necessary to make it work for our needs. > I don't see how will that solve (c,d,f,g)? Also how long should we wait on that? Year? 5 years? I looked at the current Xorg source and it still explicitly forbidding opening of the mouse and keyboard devices. Yet some one mentioned they would change that. I'm talking about solutions right now, so we can move on and fix other related issues, not sit and wait for some one to give us what we need. Vitaliy.

Sept. 27, 2007

Re: DInput mouse - where to go from here?

by Vitaliy Margolen

Stefan Dösinger wrote: > 1) Multiple Mice. If there are 2 mouse devices, the X server manages them and > combines them to one core pointer. These configurations are pretty common, > for example on laptops with touchpad + usb mouse. This is true, each mouse will have it's own device. However I have never seen a single person who used 2 or more mice while playing games <g> > 2) Different devices: An USB mouse creates a /dev/input/eventX node, but other > devices, like my synaptics touchpad do not. In the worst case we need a > driver for each mouse type, USB, serial, PS2, Synaptics, busmouse, > logitech, ... Not true. That's what so great about evdev driver - it's unified. Everything is handled by the kernel, and we get common interface to things like axis movement and buttons. I have tested this with USB and PS/2 mouse - works properly in each case. Vitaliy

Sept. 27, 2007

Re: WineD3D surface management cleanup

by Mirek Slugeň

Sept. 27, 2007