February 2008 - Wine-Devel - list.winehq.org

Re: Making use of setupapi

by Maarten Lankhorst

2008/2/19, Juan Lang <juan.lang(a)gmail.com>: > Check bug 9649, it's got a sample .reg file that fools iTunes into > thinking an iPod is present. Or here's the link to the attachment: > http://bugs.winehq.org/attachment.cgi?id=8216 Oops, sorry for the double post. I couldn't really sleep last night. :-/ Thanks. I'll take a look at it. Cheers, Maarten.

Feb. 19, 2008

Re: Making use of setupapi

by James Hawkins

On Feb 19, 2008 5:40 PM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > Hi folks, > > Any one around who understands setupapi? For iTunes I would need to > add appropriate registry keys so that my usb device is detected. My > idea is to use libusb to find the things like guid, revision etc and > then adding the keys. However I am not 100% what the layout of the > keys is. > The test suite is your friend. Off the top of my head, I don't know if the setupapi device installation API requires an actual device or not, but regardless, tests are possible. The SetupDi.*Get.* APIs can be tested using regmon. You call the function in question then look at the regmon results to see what registry keys were queried. With this method, you then know the format of the registry entries. This is how most of the msi tests concerning the registry were written. Check out dlls/msi/tests/msi.c,source.c. It's tedious but accurate. -- James Hawkins

Feb. 19, 2008

Adding devices in setupapi

by Maarten Lankhorst

Hi all, I'm trying to add the ipod detection from crossover wine to winehq. However it seems to be not compatibel due to changes to setupapi in the last 3 years. Basically what I want to do is add an usb mass storage device with the correct device path and register it with setupapi. Composing the string is easy but I'm not 100% sure what the locations are. The code seems a bit vague in that aspect. The snippet iTunes uses for detection is shown below: SetupDiGetClassDevsExW {53f56307-b6bf-11d0-94f2-00a0c91efb8b} (null) (nil) 0x00000012 (nil) (null) (nil) SetupDiEnumDeviceInterfaces 0x136638, (nil), {53f56307-b6bf-11d0-94f2-00a0c91efb8b}, 0, 0x7aa2140c How do I get my device listed in SetupDiEnumDeviceInterfaces there so iTunes can pick it up? Cheers, Maarten.

Feb. 19, 2008

Re: Making use of setupapi

by Juan Lang

Hi Maarten, > Any one around who understands setupapi? For iTunes I would need to > add appropriate registry keys so that my usb device is detected. My > idea is to use libusb to find the things like guid, revision etc and > then adding the keys. However I am not 100% what the layout of the > keys is. Check bug 9649, it's got a sample .reg file that fools iTunes into thinking an iPod is present. Or here's the link to the attachment: http://bugs.winehq.org/attachment.cgi?id=8216 --Juan

Feb. 19, 2008

Making use of setupapi

by Maarten Lankhorst

Hi folks, Any one around who understands setupapi? For iTunes I would need to add appropriate registry keys so that my usb device is detected. My idea is to use libusb to find the things like guid, revision etc and then adding the keys. However I am not 100% what the layout of the keys is. Cheers, Maarten.

Feb. 19, 2008

Re: Do we need a forum?

by Steven Edwards

On Feb 19, 2008 6:07 PM, Dan Kegel <dank(a)kegel.com> wrote: > OK. I propose we make that a redirect to > http://groups.google.com/group/comp.emulators.ms-windows.wine/topics?lnk=srg -1 I still don't like the layout and easy of use of google groups. It has decent search but thats about all it has going for it. Running our own forum gives us more control over the layout and features. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 19, 2008

Re: Do we need a forum?

by Dan Kegel

On Feb 19, 2008 2:33 PM, Phil Krylov <phil(a)newstar.rinet.ru> wrote: > I think that any existing place will eventually grow really popular if > it will be called "http://forum.winehq.org". OK. I propose we make that a redirect to http://groups.google.com/group/comp.emulators.ms-windows.wine/topics?lnk=srg

Feb. 19, 2008

Re: ddraw: Assign to structs instead of using memcpy

by Andrew Talbot

Stefan Dösinger wrote: > Am Sonntag, 17. Februar 2008 01:38:50 schrieb Andrew Talbot: >> And I presume that if the underlying struct tags >> are different between two similar types, then the compiler would warn of >> type incompatibility if such an assignment were attempted. > Not quite. You can have a DDSURFACEDESC2 *ddsd pointer, with ddsd->dwSize > == sizeof(DDSURFACEDESC). Then you have in binary a DDSURFACEDESC *, not a > DDSURFACEDESC2 *. The compiler won't see that, since the type is > determined at runtime. > > (Don't blame me, Microsoft invented that) Hi Stefan, I am probably losing the plot, but thank you for your patience and I am always glad to be put straight. My thinking is as follows. If I apply the following patch: diff --git a/dlls/ddraw/ddraw_thunks.c b/dlls/ddraw/ddraw_thunks.c index b748ad4..57210a5 100644 --- a/dlls/ddraw/ddraw_thunks.c +++ b/dlls/ddraw/ddraw_thunks.c @@ -615,7 +615,7 @@ EnumDisplayModesCallbackThunk(LPDDSURFACEDESC2 pDDSD2, LPVOID context) DDSURFACEDESC DDSD; struct displaymodescallback_context *cbcontext = context; - memcpy(&DDSD,pDDSD2,sizeof(DDSD)); + DDSD = *pDDSD2; DDSD.dwSize = sizeof(DDSD); return cbcontext->func(&DDSD, cbcontext->context); I get this from the compiler (doing "make clean && make"): ddraw_thunks.c: In function ?EnumDisplayModesCallbackThunk?: ddraw_thunks.c:618: error: incompatible types in assignment make: *** [ddraw_thunks.o] Error 1 I reason that the compiler throws this error because a DDSURFACEDESC is a type based on a struct _DDSURFACEDESC, and a DDSURFACEDESC2 is one based on a struct _DDSURFACEDESC2. So, regardless of size issues, the compiler will not let me assign between two derived types that are not both aliases for a common base type. One beauty of assignment over bit copying is the type checking one gains. Am I missing the point? Thanks, -- Andy.

Feb. 19, 2008

Re: Do we need a forum?

by Phil Krylov

Hi, On 19/02/2008, Dan Kegel <dank(a)kegel.com> wrote: > Steven Edwards wrote: > > My thoughts, as well as > > Tom's was that by creating a "blessed" location, all third parties as > > well as vendors that develop Wine related products could say "if you > > want to discuss using a vendor provided Wine product in a > > non-supported manner all are advised to go here and share information" > > Yes, of course, it would be nice if there were One True Place to go, > but the closest we're ever going to get is essentially the status quo, > where the wine-users mailing list is the place of record for user support, > the appdb is the place of record for looking for tips for a particular app, > and all the other areas are secondary. We can improve slightly > on this by linking to other popular wine forums as they pop up, > emphasizing all the while that they are secondary. I think that any existing place will eventually grow really popular if it will be called "http://forum.winehq.org". -- Ph.

Feb. 19, 2008

Re: WineD3D: let flush_to_framebuffer_drawpixels use a valid rect

by Stefan Dösinger

Am Dienstag, 19. Februar 2008 21:26:24 schrieben Sie: > Hi, > > Originally flush_to_framebuffer_drawpixels was called from UnlockRect, so > in that case LockedRect was always set. These days it can also be called > (through LoadLocation) from other places. This patch makes it use the > LockedRect when the surface is locked else the whole surface is uploaded. > This fixes rendering issues in Red Alert and other apps. Wouldn't it be better to make sure that the caller passes the correct rectangle to flush_to_framebuffer_* ? > - if(dxVersion >= 8) { > + if(0 && dxVersion >= 8) { Is this intentional?

Feb. 19, 2008