July 2014 - Wine-Devel - list.winehq.org

Re: wininet: Call WSAStartup/WSACleanup to mime the Windows behavior

by Erich E. Hoover

On Sat, Jul 5, 2014 at 10:52 AM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > ... > The point of this system is to isolate the implementer from the > implementation details of the original, so they can't copy those > details. They are supposed to only be given an interface to implement, > which they may do differently (if that's possible while still > implementing the required interface). It doesn't work if the > implementer is told the implementation details, so when doing this you > have to be careful about the information you give. Yeah, I'm aware - I was actually surprised to find (after some Googling as a result of this discussion) that the 9th circuit ruled in favor of explicit copying in a case back in 2000 ( http://en.wikipedia.org/wiki/Sony_Computer_Entertainment,_Inc._v._Connectix… ). It was my understanding that US law (and case law) didn't have any precedent for permitting something like that. Anyway, it's probably still a good idea to stick to strict clean room techniques. > I can't explain why the relay call out from wininet to winsock is too > much information in this case, but it's been a general policy that we > don't look at the calls native makes. (I also learned that policy the > hard way, unfortunately.) Maybe we should update http://wiki.winehq.org/CleanRoomGuidelines and make it more prominent on http://www.winehq.org/devel/ ? I don't even know how to get to it from that page, and it seems like a pretty important document... Best, Erich

July 6, 2014

Re: wininet: Call WSAStartup/WSACleanup to mime the Windows behavior

by Vincent Povirk

On Fri, Jul 4, 2014 at 10:56 AM, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > As he said in the original email, Anastasius Focht is the one who looked at > the wininet behavior and described it others > (https://bugs.winehq.org/show_bug.cgi?id=36830#c0) Sounds to me like the > old Compaq system of having one person look at what the original does while > having another person implement it from their notes. The point of this system is to isolate the implementer from the implementation details of the original, so they can't copy those details. They are supposed to only be given an interface to implement, which they may do differently (if that's possible while still implementing the required interface). It doesn't work if the implementer is told the implementation details, so when doing this you have to be careful about the information you give. I can't explain why the relay call out from wininet to winsock is too much information in this case, but it's been a general policy that we don't look at the calls native makes. (I also learned that policy the hard way, unfortunately.)

July 5, 2014

Re: [PATCH 3/3] winecoreaudio.drv: Use AUHAL API instead of AudioQueue

by Ken Thomases

On Jul 5, 2014, at 4:13 AM, Francois Gouget wrote: > On Fri, 27 Jun 2014, Andrew Eikum wrote: > [...] >> + if(This->wrap_bufsize_frames < *nframes){ >> + free(This->wrap_buffer); >> + This->wrap_buffer = malloc(data->mBuffers[0].mDataByteSize); >> + This->wrap_bufsize_frames = *nframes; > > Does the AUHAL API require that we use malloc() / free() here (and in > the other locations dealing with wrap_buffer) or could this be switched > to HeapAlloc() / HeapFree()? > > If we're free to use the latter doing so would be more consistent with > the rest of Wine. This code is in a callback that Core Audio calls on a thread of its own creation. That thread is not set up as a Wine thread, so you can't call other Wine code. My argument was that this allocation can be completely avoided in this context. It is possible to know in advance the upper limit of the buffer size required and allocate it during setup. In that case, HeapAlloc() could be used. -Ken

July 5, 2014

Re: [4/9] wined3d: replace vendor specific callbacks with generic code that uses vendor specific renderer string tables

by Andrei Slăvoiu

În ziua de Sîm 05 Iul 2014, la 11:43:29, Stefan Dösinger a scris: > Am 2014-07-04 00:40, schrieb Andrei Slăvoiu: > > +/* See http://developer.amd.com/drivers/pc_vendor_id/Pages/default.aspx > > + * > > + * Beware: renderer string do not match exact card model, > > + * eg HD 4800 is returned for multiple cards, even for RV790 based ones. > > */ > This link is dead. I recommend to remove it. Is it ok to replace it with this one? http://developer.amd.com/resources/hardware-drivers/ati-catalyst-pc-vendor-…

July 5, 2014

Re: [5/9] wined3d: Make d3d_level_from_gl_info return an enum instead of a plain int

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-07-04 00:40, schrieb Andrei Slăvoiu: > +enum wined3d_d3d_level > +{ > + D3D5, > + D3D6, > + D3D7, > + D3D8, > + D3D9_SM2, > + D3D9_SM3, > + D3D10, > + D3D11, > +}; I'd prefer enum values like D3D_LEVEL_5 etc. I think D3Dx is too short and generic. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTt9weAAoJEN0/YqbEcdMwZ7QP/RPzNly/5CRWpcwKFI2VAh6O IquSkL2PeTlsDRJPwiywF4lXc1IqDHnrqFRHpTfI1u+eQMijtQ2iaTMBHcClLeaY VQGg4Td2UBenMMPjVtqLsP5FAdOZEeI8cWo6dQoA/ZMakgWqz2ZJDuLq/YhSAKFU 1msCqEyGIukOyzYp5ThbQXobVwHkJYO34ORMciHpbWRu1X97fHReAZLL21zEIwVi RRQTPBF/O4KvCLzJMpLVG0F35Ki8vIeJJPS/QU0pN2H88n//SWQBPHE9Epm3KCE0 qczqa8P9SjW7eCJ/xD59mbc89tRUjwegcNnP7ItjiRDgAnwk98jbgyZbrQfTKyLU b7K8xezH6kmgC6+SotPcIVtvU9Ucw6kNLhJKtlhdiEHprhQcBXTp27+uMfWCS9Nx tsjGw8VpKJ4D6jssD7nY/b/reNZ6M3qMCQYyWiGOe1hi0gerq+ouOLBDCyTbJD2n XcifP/jj+3BuuCO8gXJwmYECutq6Ao23ziOjgKPuqKY3XLgoMwdpUo5bylmY/m4N tIzy1JnSZubbJVIxoeCp7nC4Eeq3YRaIMP3+cqmT8ogu9KDBQuwpNLSk/gW65OIO 9Og69K7gIvkrudCo5j/Vd8ir+JxcbhA9Hw+gJdcySZwLItiTmpX/yi31/1+6TLr+ cokSG4OFKv1ZB2izKi46 =y2DP -----END PGP SIGNATURE-----

July 5, 2014

Re: [4/9] wined3d: replace vendor specific callbacks with generic code that uses vendor specific renderer string tables

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-07-04 00:40, schrieb Andrei Slăvoiu: > +/* See http://developer.amd.com/drivers/pc_vendor_id/Pages/default.aspx > + * > + * Beware: renderer string do not match exact card model, > + * eg HD 4800 is returned for multiple cards, even for RV790 based ones. */ This link is dead. I recommend to remove it. > static const struct gl_vendor_selection > { > enum wined3d_gl_vendor gl_vendor; > const char *description; /* Description of the card selector i.e. Apple OS/X Intel */ > - enum wined3d_pci_device (*select_card)(const char *gl_renderer); > + const struct > + { > + const char *renderer; > + enum wined3d_pci_device id; > + } *cards; /* To be used as cards[], pointer to the first member in an array */ > + size_t nr_cards; /* Number of entries in the array above */ I think it would be nicer to give the structure a name instead of declaring it twice. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTt8jBAAoJEN0/YqbEcdMwhskQAIV3GnqWmcBsxdq8rIGHUw/r lIP7nIxp65wxXSykylXJsPZDgyDGkQzb62u8StS1TBm+yjNy0sLR/A4vqHiZyUeN Kv6AAp/3xtSfykYLNw7dJKmSjhaMdXDo6tx8pB3r1KT1bygNu3tGEMmSjAnRDk94 wJPCsl1Gkl1VIPo6aNnEfaKSVAbLxCtGK1SxCZc9SznGSJLNDhNdPiqC2+s/8JUZ 2/+uSPpilHEQVyBf+pi1fnq+RXwZ23S2+Qc7IkYPegX4z75M/BP0IKo+8eXYmOP5 KLL0C6TyVOp06Q6cNUCqOVpoSu+7Mnm4aS423QUb5hlfcDTV67mgyrVYkQTwkn9h L9lxMldW/DzGMsY3GceVOZ7tm3VgTziT06FQjKcXuMknfhgPiXab2iHZYHgz7YJF hCbGA9WSeYd9UuNKu8AmeGGFuAg+IuFLfnbVSG1idF1yFT/wlaiyLnA8Vc7//cI/ PRrn8UuiUS94cNLp5lSyl8cS8kzk3hW3Nf5mkRCqSJQXvJb2mLq38Hr9VR98rCQr 9L3aIOG5HIn1Uzwng4KywtGvyNbySsgiUPJgQqQMwS3HgwAGprPt7lF0b6fTMQym v7l9/gx73pQQEpBAjBpIJPt9CAaUrhziPdciMojT/cBRhmBBDoDZJTtxe0LZorNL Yz7Iw8f+i5Pag4QlZrxF =Xnv/ -----END PGP SIGNATURE-----

July 5, 2014

Re: [2/9] wined3d: Make the card selection for binary drivers use arrays only

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-07-04 00:40, schrieb Andrei Slăvoiu: > + /* Radeon R5xx */ > + {"X1950", CARD_AMD_RADEON_X1600}, > + {"X1900", CARD_AMD_RADEON_X1600}, > + {"X1800", CARD_AMD_RADEON_X1600}, > + {"X1650", CARD_AMD_RADEON_X1600}, > + {"X1600", CARD_AMD_RADEON_X1600}, > + /* Radeon R4xx + X1300/X1400/X1450/X1550/X2300/X2500/HD2300 (lowend R5xx) > + * Note X2300/X2500/HD2300 are R5xx GPUs with a 2xxx naming but they are still DX9-only */ > + {"HD 2300", CARD_AMD_RADEON_X700}, > + {"X2500", CARD_AMD_RADEON_X700}, > + {"X2300", CARD_AMD_RADEON_X700}, > + {"X1550", CARD_AMD_RADEON_X700}, > + {"X1450", CARD_AMD_RADEON_X700}, > + {"X1400", CARD_AMD_RADEON_X700}, > + {"X1300", CARD_AMD_RADEON_X700}, > + {"X850", CARD_AMD_RADEON_X700}, > + {"X800", CARD_AMD_RADEON_X700}, > + {"X700", CARD_AMD_RADEON_X700}, > + /* Radeon Xpress Series - onboard, DX9b, Shader 2.0, 300-400 MHz */ > + {"Radeon Xpress", CARD_AMD_RADEON_XPRESS_200M}, The last version of the binary driver that supports those cards is more than 5 years old. Unlike the Nvidia counterpart it has never been updated for newer kernels or X servers. I think it is safe to remove these cards from the binary driver handler. I guess its also safe to keep them in there though in case we have one or two users left who use ancient distros. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTt8d3AAoJEN0/YqbEcdMwQxAP/A0itG/ma629yvacZntEzfiR GjxZnCDWcxOB/q0i32QaM7iClpJq8imVUv9ZZbu7niK7JFwDvxNR8NLLHvheKY5G VaQQvH5Ueg3dUx29J4Ri+JZCgTJQGPBkYFEi2/Ba4TwxPr4ZDjMSXqH0JLcuxA0D r79RS8nFqD/8hcxfEGiv9YMoE9iJgZOjL4v67ErBL/ob0Q2S+qWf0Y9+NIhQB+3z F3JhPyuG6szBn4iVN42wCGl9eg+4/iC+OuDvmLFe4Nsu+Ggb6CyxntOZcDPDpGIa PA99942HIoiEtr3MboV7xMuMlPo6aPm5IcbKOWQMi2djqf8RnbM+rAqsK30tRwFi zqnW9vrctY+JubADF4uRcxMt5insjv6mURH8FmHEo2snmbRv93HSzSeG28Ylp4ND /2ltZHdxnAo2IoGjZX0QjBHS6giBF9DQ6WLxZcJUVbCj2oBh5+iXiSnnrsYxGv92 CRkHtySd8iSCibseyi9EwpnMzK5BIbWVz1L7fs8eM0ITGFOfatS5guWvirxT0g15 B/hf8py1gQiC/tmZQW828n/nGAmtqzwNl4PBPX1TRZz1jwxR6mg3hHIuGL13vwZB +8GEJFgRZLMRz4l2YkiuFeEohaCNq6wQ5Tlc+n3Fs/GkWoaDASd/+OZ9pc55/Mof pbXvrhc7BUFxMWoPjHH/ =1c47 -----END PGP SIGNATURE-----

July 5, 2014

Re: [PATCH 3/3] winecoreaudio.drv: Use AUHAL API instead of AudioQueue

by Francois Gouget

On Fri, 27 Jun 2014, Andrew Eikum wrote: [...] > + if(This->wrap_bufsize_frames < *nframes){ > + free(This->wrap_buffer); > + This->wrap_buffer = malloc(data->mBuffers[0].mDataByteSize); > + This->wrap_bufsize_frames = *nframes; Does the AUHAL API require that we use malloc() / free() here (and in the other locations dealing with wrap_buffer) or could this be switched to HeapAlloc() / HeapFree()? If we're free to use the latter doing so would be more consistent with the rest of Wine. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Sufficently advanced incompetence is indistinguishable from malice.

July 5, 2014

Re: [PATCH 4/4] vbscript/tests: Added tests for the subtype of TypeName(try 2)

by Marvin

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 https://testbot.winehq.org/JobDetails.pl?Key=7857 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

July 4, 2014

Re: [PATCH 3/4] vbscript: Implemented Abs(try 6)

by Marvin

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 https://testbot.winehq.org/JobDetails.pl?Key=7856 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

July 4, 2014