January 2016 - Wine-Devel - list.winehq.org

Re: [resend v2 4/4] ddraw: Do refcounting only through wined3d_texture_{inc, dec}ref().
by Henri Verbeet Jan. 3, 2016

Jan. 3, 2016

On 22 December 2015 at 22:43, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > @@ -1227,6 +1221,7 @@ static HRESULT WINAPI DECLSPEC_HOTPATCH ddraw_surface7_Flip(IDirectDrawSurface7 > struct wined3d_texture *texture; > IDirectDrawSurface7 *current; > struct wined3d_surface *tmp; > + unsigned int tmp_idx; You shouldn't need that. Flippable surfaces aren't supposed to be textures, and only textures should have mip-levels. It should be enough to validate the sub-resource index is 0 and print an ERR if it somehow isn't. I don't think we enforce that DDSCAPS_MIPMAP needs DDSCAPS_TEXTURE. That would be a bug and needs tests. > @@ -6286,8 +6287,10 @@ void ddraw_surface_init(struct ddraw_surface *surface, struct ddraw *ddraw, stru > } > desc->lpSurface = NULL; > > - wined3d_surface_incref(wined3d_surface); > + wined3d_texture_incref(wined3d_texture); > surface->wined3d_surface = wined3d_surface; > + surface->wined3d_texture = wined3d_texture; The reference counting here is odd. You'd normally increment the reference count right before or after storing the pointer. You also store wined3d_surface without increasing the reference count, although that's probably ok because it's protected by the one from the texture. Still, it would probably be nicer to just get rid of the wined3d_surface field first.

3 5

Re: [PATCH 1/5] wined3d: Regenerate FFP replacement VS on changes to the normal attribute in the vertex declaration.
by Henri Verbeet Jan. 3, 2016

Jan. 3, 2016

On 15 December 2015 at 11:58, Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > I signed of on this (117257) a while ago, but notice it's still marked as "Assigned".

1 0

Re: [PATCH 3/6] d3d11/tests: Add test for SM4 sample_l instruction.
by Henri Verbeet Jan. 3, 2016

Jan. 3, 2016

There seems to be a good amount of overlap between this test and test_texture(). Would it make sense to merge them? Also, I assume you'll add a d3d10core version of the test as well? On 1 January 2016 at 18:08, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + float miplevel[4] = {0}; A struct vec4 would perhaps be more appropriate. IIRC MSVC gets a bit unhappy about initializing floating-point variables with anything other than floating-point constants, so it would perhaps be better to use 0.0f here. However, ... > + buffer_desc.ByteWidth = sizeof(miplevel); > + buffer_desc.BindFlags = D3D11_BIND_CONSTANT_BUFFER; > + > + resource_data[0].pSysMem = &miplevel; > + > + hr = ID3D11Device_CreateBuffer(device, &buffer_desc, resource_data, &cb); > + ok(SUCCEEDED(hr), "Failed to create constant buffer, hr %#x.\n", hr); ... > + *miplevel = test->miplevel; > + ID3D11DeviceContext_UpdateSubresource(context, (ID3D11Resource *)cb, 0, NULL, miplevel, 0, 0); ... I don't think you should need to pass in initial data in the first place.

1 0

Re: [PATCH v3] user32: Add MOUSEHOOKSTRUCTEX to fix mouse wheel support for JA2 1.13 and other apps which use it
by Nikolay Sivov Jan. 3, 2016

Jan. 3, 2016

Hello again. > +typedef struct > +{ > + MOUSEHOOKSTRUCT MOUSEHOOKSTRUCT; > + DWORD mouseData; > +} MOUSEHOOKSTRUCTEX, *PMOUSEHOOKSTRUCTEX, *LPMOUSEHOOKSTRUCTEX; Apparently that's not how Windows SDK defines it. For some obscure reason they didn't define EX struct simply as non-EX + extra field, but used cpp style, kind of. Older versions don't even have field name for MOUSEHOOKSTRUCT portion, only type, but this won't work, not with gcc at least. SDK 10 uses DUMMYSTRUCTNAME as a field name, which resolves to 's', if NONAMELESSSTRUCT is defined. I guess we have to follow version 10 definition.

3 4

Re: user32/tests: Add message tests for EM_SETSEL when getting/losing focus in combo boxes (v2)
by Marvin Jan. 3, 2016

Jan. 3, 2016

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=19336 Your paranoid android. === w7u (32 bit msg) === msg.c:4644: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088 === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

2 1

Fedora source packages
by Jeffrey Smith Jan. 2, 2016

Jan. 2, 2016

For the builddep commands in http://wiki.winehq.org/Fedora to work as intended, there needs to be a repository containing the source rpms. The binary rpms do NOT provide the _build_ dependency information needed for the builddep commands to do their job. Otherwise, the instructions need to be redone, as the builddep commands are not really doing anything useful as things stand. Jeff

4 4

Shared WoW64 on Mac OS X via Homebrew
by kaazoo Jan. 2, 2016

Jan. 2, 2016

Hello, I modified the existing Homebrew formular for Wine in order to make shared WoW64 (32bit and 64bit Wine together) possible: https://github.com/kaazoo/homebrew/commit/cd0f1db42e0a8228740fce347604d1cfe… The changes are not yet upstream, so you'll need to overwrite /usr/local/Library/Formula/wine.rb with my version. The upcoming LLVM 3.8 release is a dependency for the 64bit build: brew install llvm --with-clang --with-clang-extra-tools --with-compiler-rt --with-libcxx --with-lld --with-rtti --HEAD After that Wine 1.9.0 can be installed via: brew install wine --with-win64 --without-x11 --devel Regards, kaazoo

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 7).
by Stefan Dösinger Jan. 2, 2016

Jan. 2, 2016

> Am 02.01.2016 um 07:24 schrieb Aaryaman Vasishta <jem456.vasishta(a)gmail.com>: > > + size = w * h * (bpp / 8); > + /* Saving pixels by directly accessing bitmap buffer is faster than using SetPixel */ > + for (i = 0, j = 0; i < size;) > + { > + if (palettized) > + { > + buffer[i++] = j; > + buffer[i++] = j; > + buffer[i++] = j++; > + j %= 256; > + } > + else > + { > + buffer[i] = i % 256; > + i++; > + buffer[i] = j % 256; > + i++; > + j = (j % w) + 1; > + } > + } This is different from earlier patch versions afair. Whats the reason for the change? I guess this gets the job done, but it feels a bit odd to initialize 2/3rds of a rgb pixel or 3 palletized pixels per iteration. It can also cause trouble with writing past the end if size isn't a multiple of 2 or 3 respectively. (with 24 bit rgb even a multiple of 2 isn't guaranteed) Also I think you can get rid of the DIB section and just use a HeapAlloced blob.

2 1

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture (try 6).
by Stefan Dösinger Jan. 2, 2016

Jan. 2, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-01-01 um 18:15 schrieb Aaryaman Vasishta: > + expected = (info_header.biWidth + 3) & ~3; > + ok(expected == img->bytes_per_line, "Expected bytes per line == %d, got %d.\n", expected, img->bytes_per_line); > + if (depth == 8) > + { > + for (i = 0; i < h; i++) > + { > + offset = upside_down ? (img->bytes_per_line * (h - i - 1)) : (img->bytes_per_line * i); > + for (j = 0; j < img->bytes_per_line; j++) > + { > + if (buffer1[k++] != buffer2[offset++]) > + return FALSE; > + } You want j < img->width here, otherwise you compare the padded bytes against the next line of the input image. (You'll then also compare the follow-up lines incorrectly and read past the input buffer). It works here because you pass an image with a width that's a multiple of 4 when this codepath is used. So iterate over width pixels, but advance the read offset / pointer by bytes_per_line bytes after processing one line. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWhs9jAAoJEN0/YqbEcdMwx6kP/RXJJdivWRU1ouvEP32VWNRA O/tOZxGNJnXw0Rz40QQz1rtckN3GGAe54pwilQbaPAqrZeIDAEWfk4gWMKIvHvUw Vdg3w7dfQv6fpKK16EWWb83gdaQU9X3Nc7bFzHx4XwvkjHgV/ztsk/t6cqkAOv2Y cWul6MpQcWvehGyEv+vk1siMxO5zFjLvBpT7jgFh+7Ehzbk8ziZWdBYGjV18PnAQ 4eT5MrsNbaA99wKj7ibhz9I4GsKLf8oQQAFFqcVTutCOLeQh7zvHkQ4Z4glXSEYu VvNRmLdMYNSYho+Z9lZEABNvaw9lkxJ6/r1OYd3tP2A0TZzKur732iUYwTo1RnFB Hlv6K/PKzTTMN1m9GZ8UiltnjsEq5G+05nkaywsh7pkr9bGU2pfSEihZ8BSX1/4a zG+vLJipg/rdHalQKfCflxWpKcHiIFjm5E/+Bdtgzb3sSksPh2bfmdVDW/bl3lvD OMXD2FgHB4BE+lexisBV7+qlQhlv8vEPgWryoJ8xomfyAc0ZHioOgTrq0XSMrTdC 19oNGDWZd/8P1guTTC3eRlBFA3jYt/yvjzINRYG1h9L5DbYISuMbp0oUSFx3412o YB7HTHjbyxcWhZFEXc9oDHoMzfIEyJI1QOa8fCNkisucCc/idN7Zrqz+3wYJhHCu PjleVblBVMqsSN/Qw2OE =ftwX -----END PGP SIGNATURE-----

2 1

Mac OS X beta packages!
by Michael Müller Jan. 2, 2016

Jan. 2, 2016

Hi, we are happy to announce an initial version of our Mac OS X >= 10.8 builds. So far the packages have not yet received that much testing, so please give them a try, and report any issues you encounter. The packages are available at: https://dl.winehq.org/wine-builds/macosx (Some mirrors don't show all files yet, just append random arguments to the url like ?whereismypackage to trick the cache) For unexperienced users, it is recommended to install Wine using the *.pkg files. Just double-click on the package, and the usual Mac OS X installer wizard should open. As pointed out by Austin, I am not a registered Apple Developer and therefore the packages aren't signed. This will result in an error if you configured gate keeper to block unsigned packages. The installation itself should be self-explaining, so I will not go into too much detail here. It is possible to install the package either for all users (needs administrator privileges), or just for your current user. If you haven't installed XQuartz >= 2.7.7 yet (our package supports the x11drv as well as the macdrv), the installer will complain. Just install the missing dependency, and restart the installation, if this is the case. After the installation is finished, you should find an entry "Wine Staging" or "Wine Devel" in your Launchpad. By clicking on it, a new Terminal window opens with a short introduction into some important wine commands. You can now directly start wine/winecfg/... from the Terminal, as the PATH variable is set correctly. For user convenience, the package also associates itself with all *.exe files, which means you can run windows executables just by double-clicking on them. This might not work for all executables though, since OS X doesn't seem to pass the current working directory to the "Open With" handler. Some experienced users on the other hand might prefer a raw wine version without those gimmicks, so we also provide tarball archives. They basically contain the same files (except packaging related stuff), and can be unpacked in any directory. There is no need to set DYLD_* environment variables, all paths are relative, so it should work as long as the directory structure is preserved (you can skip the /usr prefix though using --strip-components 1). Also make sure to install XQuartz >= 2.7.7 in this case. For those who are wondering, here a couple more technical aspects: -------- Dependencies -------- The following dependencies are shipped as precompiled *.dylib-libraries directly with Wine: * libjpeg-turbo * liblcms2 * liblzma * libopenal-soft * libtiff * libxml2 * libxslt * [libtxc-dxtn-s2tc] This is the patent free implementation of dxtn as used by many linux distros. Only included in Wine Staging. -------- Scripts -------- You can find all scripts and build files at https://github.com/wine-compholio/wine-packaging/tree/master/macosx Those files allow you to build the packages on Debian Jessie as host system, starting from a patched clang compiler (to support ms_hook_prologue), tools necessary to create OS X packages, cross compilation of the Wine build dependencies and finally cross compiles Wine itself. You only have to provide MacOSX10.8.sdk.tar.xz and xquartz-2.7.7.tar.xz, everything else is built from source. However, the generated scripts are meant to be run inside our build VMs, so realistically speaking it requires some effort to setup such a system and is not suitable for an average user. ------------------------ There are also some features I am planning to implement in the future (depending on how much time I have): -------- Auto updater -------- There is no common system to provide automatic updates for packages besides the Store, so I think it would be good to come up with some solution for this problem. Especially if the user installed the package into his home directory, he could easily update it without entering a password. I don't have much knowledge about objective-c or cocoa, so if someone else wants to implement this, I am more then glad to add it as an optional feature to the installer. -------- Desktop integration -------- So far Wine does not create desktop entries that are shown in Launchpad, but instead creates useless entries at ~/.local/share/applications/. I think it shouldn't be too hard to dynamically create a proper entry at ~/Applications/ using a wrapper like I did for the main wine executable. -------- Package signing? -------- This is basically something I could fix in 5 minutes, but I don't feel like paying 99$/year if I basically don't use Mac OS X myself. ------------------------ Happy new year and happy testing! :) Best regards, Michael

3 5