August 2011 - Wine-Devel - list.winehq.org

Re: w9x testbot state?

by Maarten Lankhorst

On 08/01/2011 07:12 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > what happened to the w9x test bots? I'd like them to run some kernel32 tests. > Testbot says "offline". > They were hosted at Gé's house. Testbot can no longer reach them. ~Maarten

Aug. 3, 2011

Re: w9x testbot state?

by Frédéric Delanoy

On Wed, Aug 3, 2011 at 10:09, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > Stefan Dösinger wrote: >>> Testbot says "offline". >>I think we killed w9x testing a few months ago > > That's not exactly right. While test.winehq.org no more performs daily w9x > tests for Wine, the w9x machines have been available on testbot.winehq when > you select "show all VMs" -- and they are still listed now. > > I know, because I used them not too long ago. > Marvin tells me that on 2011-04-28, W98SE was functioning. Those aren't available anymore (retired) it seems: VM name Type of VM 32 or 64 bits Current status Description W95 retired 32 offline Windows 95 W95B retired 32 offline Windows 95 OSR2 W98 retired 32 offline Windows 98 W98SE retired 32 offline Windows 98 Second Edition

Aug. 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Henri Verbeet

Well yes, it's implementation defined, not undefined. The point is that there isn't necessarily any relation to endianness. Just use shifts and masks.

Aug. 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by max

On 08/03/2011 05:18 AM, Stefan Dösinger wrote: > On Wednesday 03 August 2011 10:56:25 Michael Mc Donnell wrote: >> It is *technically* undefined, but all the compilers I have tested it >> on do the same thing. > There may be a future compiler that behaves differently. You may get away with > it right now, but it will cause pain in the rear sooner or later. > > (I didn't know bitfield layout is undefined, otherwise I wouldn't have advised > you to keep using them) Technically they are 'implementation defined', not 'undefined', which means each compiler has to define them but different compilers may define them differently. Because different compilers DO define them differently, they are not portable. Since they are not portable, wine should not use them without cloaking them in macros that compensate for the differences. Which is a PITA. Has anybody done the cloaks already? Max

Aug. 3, 2011

Re: mmdevapi tests

by Andrew Eikum

On 08/02/2011 09:30 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > I've a couple of mmdevapi tests that I could put into submittable > form soon, however there's one big problem: There are three different > backends (ALSA, OSS, MacOS) and each one needs a different set of todo_wine. > > How to deal with that? I think the best thing to do is mark only the tests that fail on all drivers as todo_wine. Tests that pass on any driver should not be marked todo_wine. The idea is that the drivers should be as similar as possible. So if something works on one driver and not others, then the broken drivers will appear in the test results and should be fixed. Tests that crash on some drivers and not others should be accompanied by a fix for the crashes. Andrew

Aug. 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Wed, Aug 3, 2011 at 11:18 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Wednesday 03 August 2011 10:56:25 Michael Mc Donnell wrote: >> It is *technically* undefined, but all the compilers I have tested it >> on do the same thing. > There may be a future compiler that behaves differently. You may get away with > it right now, but it will cause pain in the rear sooner or later. > > (I didn't know bitfield layout is undefined, otherwise I wouldn't have advised > you to keep using them) Looking at the ISO C99 draft I can't find anything about the memory layout being undefined. Only that things are implementation specific like alignment, padding, and endianness. Not much unlike the definition of int :-) Anyway you're right it's probably a good idea to stay clear of them in order to avoid potential compiler issues. I've updated the patch to implement UDEC3 and UDEC3N using shifts and masks instead of bit-fields. It will still only work on little-endian machines though. Does it look ok? Thanks, Michael

Aug. 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Stefan Dösinger

On Wednesday 03 August 2011 10:56:25 Michael Mc Donnell wrote: > It is *technically* undefined, but all the compilers I have tested it > on do the same thing. There may be a future compiler that behaves differently. You may get away with it right now, but it will cause pain in the rear sooner or later. (I didn't know bitfield layout is undefined, otherwise I wouldn't have advised you to keep using them)

Aug. 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Wed, Aug 3, 2011 at 10:56 AM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > On Tue, Aug 2, 2011 at 2:26 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> On 1 August 2011 14:08, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: >>>> With the bitfields I'm not sure about stuff like endianess. My gut feeling >>>> would be to use bitmasks and shifts to separate a DWORD instead, but bitfields >>>> certainly look nicer. Beyond that endianess is a somewhat academic >>>> consideration with an API that's available on x86 only. So I'd say keep the >>>> bitfields. >>> >>> Ok good. That'll keep me from the pain of doing bit twiddling on a >>> little endian machine :-) >>> >> You can't do that, even on x86. Bitfield memory layout is undefined. > > It is *technically* undefined, but all the compilers I have tested it > on do the same thing. The little test I've attached has been tested on > Visual Studio x86, GCC x86 and x86-64, llvm/clang x86, and suncc on a > SPARC-Enterprise-T5220, and they all behave the same way. The raw byte > ordering on the SPARC is different because it's big endian, but the > bit-fields still work the same way, in that it extracts the correct > values. Do you know any common compiler and architecture combinations > where it does not work? > > I've removed the support for DEC3N and UDEC3 so it doesn't block the patch. Oops here is the patch where I have actually removed it :-)

Aug. 3, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Tue, Aug 2, 2011 at 2:26 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 1 August 2011 14:08, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: >>> With the bitfields I'm not sure about stuff like endianess. My gut feeling >>> would be to use bitmasks and shifts to separate a DWORD instead, but bitfields >>> certainly look nicer. Beyond that endianess is a somewhat academic >>> consideration with an API that's available on x86 only. So I'd say keep the >>> bitfields. >> >> Ok good. That'll keep me from the pain of doing bit twiddling on a >> little endian machine :-) >> > You can't do that, even on x86. Bitfield memory layout is undefined. It is *technically* undefined, but all the compilers I have tested it on do the same thing. The little test I've attached has been tested on Visual Studio x86, GCC x86 and x86-64, llvm/clang x86, and suncc on a SPARC-Enterprise-T5220, and they all behave the same way. The raw byte ordering on the SPARC is different because it's big endian, but the bit-fields still work the same way, in that it extracts the correct values. Do you know any common compiler and architecture combinations where it does not work? I've removed the support for DEC3N and UDEC3 so it doesn't block the patch. Thanks for the review, Michael

Aug. 3, 2011

w9x testbot state?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Stefan Dösinger wrote: >> Testbot says "offline". >I think we killed w9x testing a few months ago That's not exactly right. While test.winehq.org no more performs daily w9x tests for Wine, the w9x machines have been available on testbot.winehq when you select "show all VMs" -- and they are still listed now. I know, because I used them not too long ago. Marvin tells me that on 2011-04-28, W98SE was functioning. Regards, Jörg Höhle

Aug. 3, 2011