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

Re: Directx 11.2 idl's created

by Martell Malone

Apologies for the spam. This will be my last one Just like the dxgi 1.3 idl I added all the missing functions structs etc from the dxgi 1.2. I also reformatted it to have the same structure and naming as dxgi.idl for existing code. So this along with the other patches completes all functions and structs needed for dx11 through dx11.2. Again I'm sorry if this all seems sloppy and I didn't name them 1-5 as patches. I wasn't expecting to have to add more. Kind Regards Martell On Tue, Feb 3, 2015 at 6:26 PM, Martell Malone <martellmalone(a)gmail.com> wrote: > Hi again, > > I just realized that wine does not have a winapifamily header. > So I added one in a new patch for this. > > By default wine will want all api's so I have it set to DESKTOP + APP api's > Technically all app api's are desktop api's anyway so this is the default. > > This leaves room for adding WinRT app support in the future if needed. > If not needed then the header is still valid and would help have more > accurate idl's > > The project in mind for this is mingw-w64 which has WinRT support. > This project shares its dx11 idl's with wine so we would very much like > this to be accepted :) > > Kind Regards > Martell > > On Tue, Feb 3, 2015 at 5:47 PM, Martell Malone <martellmalone(a)gmail.com> > wrote: > >> Hi guys, >> >> I create 2 patches that I posted to win-patches. >> [1/2] Directx 11.2 idl's dxgi1_3.idl >> and >> [2/2] Directx 11.2 idl's d3d11_2.idl >> >> I can update the commit msg to "wind3d: Added x idl" >> As Bruno explained to me this is the structure. >> >> Other than that however does anyone have any feedback ? >> >> Kind Regards >> Martell >> > >

Feb. 3, 2015

Re: Directx 11.2 idl's created

by Martell Malone

Hi again, I just realized that wine does not have a winapifamily header. So I added one in a new patch for this. By default wine will want all api's so I have it set to DESKTOP + APP api's Technically all app api's are desktop api's anyway so this is the default. This leaves room for adding WinRT app support in the future if needed. If not needed then the header is still valid and would help have more accurate idl's The project in mind for this is mingw-w64 which has WinRT support. This project shares its dx11 idl's with wine so we would very much like this to be accepted :) Kind Regards Martell On Tue, Feb 3, 2015 at 5:47 PM, Martell Malone <martellmalone(a)gmail.com> wrote: > Hi guys, > > I create 2 patches that I posted to win-patches. > [1/2] Directx 11.2 idl's dxgi1_3.idl > and > [2/2] Directx 11.2 idl's d3d11_2.idl > > I can update the commit msg to "wind3d: Added x idl" > As Bruno explained to me this is the structure. > > Other than that however does anyone have any feedback ? > > Kind Regards > Martell >

Feb. 3, 2015

Directx 11.2 idl's created

by Martell Malone

Hi guys, I create 2 patches that I posted to win-patches. [1/2] Directx 11.2 idl's dxgi1_3.idl and [2/2] Directx 11.2 idl's d3d11_2.idl I can update the commit msg to "wind3d: Added x idl" As Bruno explained to me this is the structure. Other than that however does anyone have any feedback ? Kind Regards Martell

Feb. 3, 2015

Re: Add d3d11_CreateDeviceAndSwapChain

by Martell Malone

Hi guys, I updated the patch on wine-patches to reflect bruno's input on the commit message and I changed the %d to %u. Thanks guys Martell On Tue, Feb 3, 2015 at 5:28 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Hi, this is just a hint. You are not following the standards for the > patch subject. If you see http://wiki.winehq.org/SubmittingPatches > There is: > > If you are fixing a specific component or part, write the component's > name followed by a colon: > > [1/2] msvcrt: First change... > [2/2] msvcrt: Second change... > wined3d: Separate change... > > Take a look at the patches list and you will see what I'm saying: > http://source.winehq.org/patches/ > > Best regards, > Bruno > > On Tue, Feb 3, 2015 at 3:22 PM, Martell Malone <martellmalone(a)gmail.com> > wrote: > > D3D11CreateDevice also has "sdk_version %d" > > I used that as a reference. > > Does this mean that the other stub is wrong also ?? > > > > On Tue, Feb 3, 2015 at 8:13 AM, Stefan Dösinger < > stefandoesinger(a)gmail.com> > > wrote: > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Am 2015-02-02 um 20:24 schrieb Martell Malone: > >> > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags > >> > %#x, feature_levels %p, levels %#x, sdk_version %d, " > >> You're still printing sdk_version as a signed value. Please use %u > >> instead of %d. > >> > >> Otherwise this looks good to me. > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v2 > >> > >> iQIcBAEBAgAGBQJU0IM3AAoJEN0/YqbEcdMw5v8P/3A5kt9fIPCVCTgXfM0A6uKS > >> 8cCXPITuKmeub7obw7EiEhsQH/4pw80bKOhmFKZvpK0knrKeU7wZvojbP18n39j1 > >> vVqpqvtzbkfsBwLZ/Z0AeC/evVACfMmw1Al3BMBTDhxFb+uv+rVI9spG06XRPx8P > >> e3pWlzoGniaZG8YP6TguA0gfrcMcGWEOWT59nstWW0HXlMFdsE1OoMM5Wd+XrpB+ > >> AuEHGNFiHacgNxVfpnk6wQw5TK2uXW79ZbjX2wnrDiXkYvUZBts34Xo5cTdXNMXp > >> DugbwLQtoC3Yu4rHxymjZTNbJLDY0bAOgBo4YwMCVnfLj7zbwvNABqtEIKtVs5Mx > >> XsovTKzLD5sPmWnCxMtC5Qmz/aQebOYWF9bB3vYju876h69J5aJt4OjGU0HfLd4g > >> 26uQEWgT+UbU0Lavofn3w9jcO4qEBl3NbmTs4egsw8n5Ry5f+N58BX1OdaOSdkmy > >> a3Io6NgV48I/FjbxdlqpMz10I+06VlWiMdlmQSKxWTN1t5AxTm8/dTHLMC4+D7nn > >> FOeWvOr3Wy4ocBWoOpT94etIBxut8IMfSHzEKsoll7kib3daYVDPv97pAbKdV3fT > >> tZhzhWif+sqneVpk9QnCqhd9v9Kd29axqTBy7JiZ9t8TYxFTrXu50ZgC5oX/zKBV > >> 4jVGoA2kY+Gtv9KR6SH0 > >> =R0+9 > >> -----END PGP SIGNATURE----- > > > > > > > > > > >

Feb. 3, 2015

Re: [PATCH 1/2] ntdll: Support 64-bit Mac OS.

by cdavis5x＠gmail.com

> On Feb 3, 2015, at 4:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Charles Davis <cdavis5x(a)gmail.com> writes: > >> diff --git a/dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec >> index 51de6e7..acd0271 100644 >> --- a/dlls/ntdll/ntdll.spec >> +++ b/dlls/ntdll/ntdll.spec >> @@ -1429,6 +1429,7 @@ >> >> # signal handling >> @ cdecl __wine_set_signal_handler(long ptr) >> +@ cdecl -arch=x86_64 __wine_current_teb() > > That's not better than exporting NtCurrentTeb. Are you sure? The NtCurrentTeb() function isn’t exported from x64 ntdll. If we export it from ours, then we have to export it on every x86-64 platform, because AFAICT there’s no way to say “Only export this function on Mac OS x86-64”. Like I explained in the other thread, I’m just afraid that some program out there depends on NtCurrentTeb() not being exported from ntdll on x86-64. (Then again, if it depends on that, it probably depends on the TEB being accessible through %gs...) Chip

Feb. 3, 2015

Re: Add d3d11_CreateDeviceAndSwapChain

by Martell Malone

D3D11CreateDevice also has "sdk_version %d" I used that as a reference. Does this mean that the other stub is wrong also ?? On Tue, Feb 3, 2015 at 8:13 AM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-02-02 um 20:24 schrieb Martell Malone: > > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags > > %#x, feature_levels %p, levels %#x, sdk_version %d, " > You're still printing sdk_version as a signed value. Please use %u > instead of %d. > > Otherwise this looks good to me. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJU0IM3AAoJEN0/YqbEcdMw5v8P/3A5kt9fIPCVCTgXfM0A6uKS > 8cCXPITuKmeub7obw7EiEhsQH/4pw80bKOhmFKZvpK0knrKeU7wZvojbP18n39j1 > vVqpqvtzbkfsBwLZ/Z0AeC/evVACfMmw1Al3BMBTDhxFb+uv+rVI9spG06XRPx8P > e3pWlzoGniaZG8YP6TguA0gfrcMcGWEOWT59nstWW0HXlMFdsE1OoMM5Wd+XrpB+ > AuEHGNFiHacgNxVfpnk6wQw5TK2uXW79ZbjX2wnrDiXkYvUZBts34Xo5cTdXNMXp > DugbwLQtoC3Yu4rHxymjZTNbJLDY0bAOgBo4YwMCVnfLj7zbwvNABqtEIKtVs5Mx > XsovTKzLD5sPmWnCxMtC5Qmz/aQebOYWF9bB3vYju876h69J5aJt4OjGU0HfLd4g > 26uQEWgT+UbU0Lavofn3w9jcO4qEBl3NbmTs4egsw8n5Ry5f+N58BX1OdaOSdkmy > a3Io6NgV48I/FjbxdlqpMz10I+06VlWiMdlmQSKxWTN1t5AxTm8/dTHLMC4+D7nn > FOeWvOr3Wy4ocBWoOpT94etIBxut8IMfSHzEKsoll7kib3daYVDPv97pAbKdV3fT > tZhzhWif+sqneVpk9QnCqhd9v9Kd29axqTBy7JiZ9t8TYxFTrXu50ZgC5oX/zKBV > 4jVGoA2kY+Gtv9KR6SH0 > =R0+9 > -----END PGP SIGNATURE----- >

Feb. 3, 2015

Re: Any interest for SOE Landmark?

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Am 2015-02-03 um 15:03 schrieb Joni Larsen-Haikarainen: > I realize that it must be very hard to try to solve a problem that > occurs in a software one might not have. Landmark is still closed > beta, so one needs to pay to get access. Thanks for the offer! Unfortunately I (and I suspect Matteo and Henri too) have to decline it. Getting access to games usually isn't much of an issue for us in general. The core issue is available time. Right now the 3 of us are pretty much busy with d3d10/11. That said, the crash of the game isn't necessarily d3d related. Maybe someone else is willing to have a look. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0OS8AAoJEN0/YqbEcdMwh0IQAJVqvxmSh5IXJzDOuITqkTYR r3nOyPgk3+3AtfmtH6cv81z0xXkDjKfJAf4oTuuFci0hqG5oe4nHCNUH2A4w+n0b 7MpWD0Ovso9cMxPZKyN2wv+xf+QnF1fI1GaoebCv79hcuacGsz6eVzn93MB4nqXb lnxs95aop0zQo4l4sSQo3qFwK4rgfqOe+k314dc/69nEk2uW8j8ZvjdqVYsC+eG7 FIN/R3kdHYOGhlIOC3yX+iWc4l8H2XLKzjrpgsLFLlRJVAiYpOyKibwVCxDcXiuj tQZ4/7aq5u+hqYJoFgX+9Mi2hWesbja7I023ekWqzRpgUSXYPGbhGY1oMGA7R/6b EWuasnxrwIA3AQkX2AwDkNEjGYh6PixlQnouWEdIrgV/o7PjDNaBsqpgUAO5CQZn wTJLfJgCJiFU+JhiVyVN8UVb7fvFI0hrnsIAGjIKkFzlKz3r5Uy4AnRYrGe2NPYO gRuvhupfeFwQALlAv3SQ0itPCb1MtLg0jWiftPbjHiCEMbpmnaEIS5CdkQTzakoz VvkdZipBFyFUy2wX3gKxvPIHiL7peX1VnRL/9J9AvCUsZ8uoSIr1esjP2ahW5a5y TD/KQoUuUs0QA3DLme7IAXbIvswwI9LW60z03S9ckb7tsJg35ZOdBgIZaPjN2hJr 8V/FaA5TKM0urRxEblQb =PILI -----END PGP SIGNATURE-----

Feb. 3, 2015

Re: Any interest for SOE Landmark?

by David Quintana (gigaherz)

Note that Sony jsut recently sold off the SOE studios to Columbus Nova. It's now called "Daybreak Game Company". With that name, I have to wonder the future of EverQuest Next and Landmark. On 3 February 2015 at 15:03, Joni Larsen-Haikarainen <jonilh(a)gmail.com> wrote: > Hi > > Question to the Wine developer community will follow. > But first some background info: > I bought in to the EverQuest Next Landmark Alpha just cus I wanted to > support it. > Did not expect it to run at all under Wine until long after official > launch. > But to my surprise the game ran just fine when it was in Alpha. > (Videos of me running it can be found on Youtube under the Channel "Let's > Play on Linux") > > After the game went in to closed beta I could only run the game on Low > graphical settings. > And after an update to the game late summer of 2014 I can not get in to > the world at all. > (See bug: http://bugs.winehq.org/show_bug.cgi?id=37853 ) > > The scroll wheel on my mouse would not work at all in game, but that's > something I learned to live with. (See bug: > http://bugs.winehq.org/show_bug.cgi?id=35542 ) > > Now to the question! > I realize that it must be very hard to try to solve a problem that occurs > in a software one might not have. Landmark is still closed beta, so one > needs to pay to get access. > > Now, I really love Landmark. So I wonder is there any Wine developer that > has any interest in trying to solve the problems with running it in Wine, > IF you had Free (as in beer) access to it? > > If someone actually have an interest in the game, but doesn't want to buy > in to the closed beta. > I would consider gifting you a Closed Beta access. > > I'm not rich, so can't do this for many people. But one or two that find > the game interesting I could do. > > Regards. > Joni > > > > >

Feb. 3, 2015

Any interest for SOE Landmark?

by Joni Larsen-Haikarainen

Hi Question to the Wine developer community will follow. But first some background info: I bought in to the EverQuest Next Landmark Alpha just cus I wanted to support it. Did not expect it to run at all under Wine until long after official launch. But to my surprise the game ran just fine when it was in Alpha. (Videos of me running it can be found on Youtube under the Channel "Let's Play on Linux") After the game went in to closed beta I could only run the game on Low graphical settings. And after an update to the game late summer of 2014 I can not get in to the world at all. (See bug: http://bugs.winehq.org/show_bug.cgi?id=37853 ) The scroll wheel on my mouse would not work at all in game, but that's something I learned to live with. (See bug: http://bugs.winehq.org/show_bug.cgi?id=35542 ) Now to the question! I realize that it must be very hard to try to solve a problem that occurs in a software one might not have. Landmark is still closed beta, so one needs to pay to get access. Now, I really love Landmark. So I wonder is there any Wine developer that has any interest in trying to solve the problems with running it in Wine, IF you had Free (as in beer) access to it? If someone actually have an interest in the game, but doesn't want to buy in to the closed beta. I would consider gifting you a Closed Beta access. I'm not rich, so can't do this for many people. But one or two that find the game interesting I could do. Regards. Joni

Feb. 3, 2015

Re: wintrust: Add more spec entries

by Alexandre Julliard

Andrey Gusev <andrey.goosev(a)gmail.com> writes: > @@ -9,6 +9,7 @@ > @ stdcall CryptCATAdminReleaseContext(long long) > @ stdcall CryptCATAdminRemoveCatalog(ptr wstr long) > @ stdcall CryptCATAdminResolveCatalogPath(ptr wstr ptr long) > +@ stub CryptCATAllocSortedMemberInfo > @ stdcall CryptCATCDFClose(ptr) > @ stub CryptCATCDFEnumAttributes > @ stub CryptCATCDFEnumAttributesWithCDFTag That's not a good idea. You should only add things that are needed by applications, or else add them commented out. -- Alexandre Julliard julliard(a)winehq.org

Feb. 3, 2015