- wine-devel - winehq.org

Re: [PATCH] user32: use InvalidateRect to repaint buttons
by Dmitry Timoshkov 11 Feb '15

11 Feb '15

Mark Harmstone <hellas(a)burntcomma.com> wrote: > At present, whenever a button needs to be redrawn user32 calls its own > internal function. This causes problems if the button is subclassed, as > the superclass then won't receive the WM_PAINT message - this is why > themed buttons lose their theme when you click on them. This patch changes > it to instead call InvalidateRect, which will force a WM_PAINT message > to be sent to the topmost class. Did you run 'make test' with your changes? -- Dmitry.

1 0

Re: [PATCH 3/5] wined3d: Set the surface pitch for user-memory surfaces.
by Henri Verbeet 10 Feb '15

10 Feb '15

On 10 February 2015 at 20:14, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + { > surface->resource.size = wined3d_format_calculate_size(texture_resource->format, > texture_resource->device->surface_alignment, width, height, 1); > + surface->pitch = wined3d_format_calculate_pitch(texture_resource->format, width); > + } > A small comment mentioning that user memory surfaces don't have the regular surface alignment probably wouldn't hurt.

1 0

Re: connect: add IsInternetConnectedStub
by Bruno Jesus 10 Feb '15

10 Feb '15

On Tue, Feb 10, 2015 at 4:03 PM, Austin English <austinenglish(a)gmail.com> wrote: > > https://bugs.winehq.org/show_bug.cgi?id=26759 Isn't it better to simply add a note like "faking success" and return S_OK? Because returning false will probably not have a useful effect in the application. I didn't test the application though. > -- > -Austin > Best regards, Bruno

2 1

Re: vbscript: Added InStrRev implementation.
by Marvin 10 Feb '15

10 Feb '15

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=11485 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

1 0

Re: [PATCH 2/6] dxgi: Add interface for IDXGISurface1 [try 2]
by Jacek Caban 10 Feb '15

10 Feb '15

On 02/10/15 13:11, Martell Malone wrote: > Before I resubmit 4 and 6 however I need to know if I should have > "include:" or "dxgi:" + "d3d11:" in them as these create new files We already have both variants in Git history and there was never a problem with it. If you ask me, use whatever you prefer. Jacek

3 2

Re: mshtml: Fix fire BeforeNavigate event for app: protocol
by Jacek Caban 10 Feb '15

10 Feb '15

On 02/09/15 07:08, Changhui Liu wrote: > - if(window->doc_obj && window->doc_obj->webbrowser && window == window->doc_obj->basedoc.window) { > + if(window->doc_obj && window->doc_obj->webbrowser && > + ((window == window->doc_obj->basedoc.window) || (window->parent == window->doc_obj->basedoc.window))) { > DWORD post_data_len = request_data ? request_data->post_data_len : 0; > void *post_data = post_data_len ? request_data->post_data : NULL; > const WCHAR *headers = request_data ? request_data->headers : NULL; The change on its own is wrong. There is nothing special about direct child of top HTML window. Ideally, we should call FireBeforeNavigate2 for all HTML windows, but use super_navigate only for the main one. This means that the if you change should not check which window we're in at all. However, for other windows, we need to pass proper frame name there. Let me know if you need more details. Cheers, Jacek

1 0

Re: [2/6] dxgi: Add interface for IDXGISurface1
by Stefan Dösinger 10 Feb '15

10 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Martell, There are a few things in Henri's list of fixes that are still missing here: Am 2015-02-09 um 10:28 schrieb Martell Malone: > Subject: [PATCH 2/6] dxgi: Add interface for IDXGISurface1 "include:" instead of "dxgi". > + uuid( 4ae63092-6327-4c1b-80ae-bfe12ea32b86), You have an extra space here. > + [out] HDC* hdc HDC *hdc, or even better HDC *dc. We avoid the Hungarian notification Microsoft once used, e.g. things like DWORD dwNumber. HDC hdc is the same kind of thing, although it's a bit of a special case. Patch 3: > +typedef struct DXGI_OUTDUPL_MOVE_RECT { > + POINT SourcePoint; > + RECT DestinationRect; > +} DXGI_OUTDUPL_MOVE_RECT; { placement . You also have FOO* bar; vs FOO *bar; issues in this patch. > + [in] IUnknown* pDevice, > + [in] IUnknown* pWindow, > + [in] const DXGI_SWAP_CHAIN_DESC1* pDesc, pStuff The same things also occur in patches 4, 5, and 6. Patch 4: > + [size_is(count_levels)] const D3D_FEATURE_LEVEL* levels, > + UINT count_levels, You are mixing count_* and *_count in patches 4, 5 and 6. For consistency's sake please make this *_count consistently. Patch 6: > +} > \ No newline at end of file Is this intentional? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU2eMXAAoJEN0/YqbEcdMwUmYP/A8I/1UBVqcynhIJ5qIvVTl4 sf3XQcWTmgI40JurL4D1mIaQMH+VeulQ7Jeroo9L9/WhIw1RRJ7R0jFULxZIu9tP VX5AyTVjd555jbt9DvlbmkaAicb0UuX7xSO5OelkkdwtdfuDCKnDq2+LxzXA2fXw y98vlT98meapIP5BzERMyAAyM0AkvpAMaxkBabE9w9Mj6IJUWteHQEwa2iavu0HR wBr/KotHXu/nqVD41PTYnAsyQoWeBNPBghg4RyqI42YKiOnDxuApOT9nAgewwHPA VghOW/hdlZahCZc+/Vst01pD7Sa7vS/Nuq4iDfJJVofSsXgwIdl5KT63eAOzR4Dl MefDKrEBmdTh44K/JeyCey1Rb4o6fNtPCQJV6lqXQkiHVeE/8IW8qPLectwuGPVd UtC7Fy38iR4UpDJBmPGypdZaFJzS2ZF1hO+mA/jJhOnefyL31vCeFWU+bf5ISuwo TDEGu7G/8yBpY+HKHr+++IwJlJKkEngf98ksjnyRC1PpIner05XHUDeu1PIll/FS T3aveyW5lWsyVGCyyovHLQIxfkaV6JPqR/AsuTuhDmhZu4ZQPoGLH5kpfrAhgVMA TeLGoR6RtTMOyFLob4sRI9nBR89H/UiEQ++fGbp/YXsOLnOZBJvn6y8AYh6zaeD5 6smvq4QiqsuQQS3tSC+f =CmBk -----END PGP SIGNATURE-----

2 3

Problem in compiling wine on 64 bit system
by Ali Aminian 10 Feb '15

10 Feb '15

Hello wine community I have some difficulty compiling wine on 64 bit ubuntu 14.04. I'm following the guide in http://wiki.winehq.org/Wine64 which i also replicate here: cd $HOME mkdir wine64 cd wine64 ../wine-git/configure --enable-win64 make > make.log 2>&1 cd .. mkdir wine32 cd wine32 ../wine-git/configure --with-wine64=../wine64 make > make.log 2>&1 #make install #cd ../wine64 #make install I can build the wine64 without any difficulty except that after configuration it prompts me that i don't have libhal, but i just ignored that. But when i get into win32 it gives me numerous warning that 32-bit development files not found, and some option will be disabled. for example: ************************************************************************************************** configure: OpenCL 32-bit development files not found, OpenCL won't be supported. configure: pcap 32-bit development files not found, wpcap won't be supported. configure: libdbus 32-bit development files not found, no dynamic device support. configure: lib(n)curses 32-bit development files not found, curses won't be supported. configure: libsane 32-bit development files not found, scanners won't be supported. configure: liblcms2 32-bit development files not found, Color Management won't be supported. configure: libz 32-bit development files not found, data compression won't be supported. configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled configure: libcapi20 32-bit development files not found, ISDN won't be supported. configure: libcups 32-bit development files not found, CUPS won't be supported. configure: fontconfig 32-bit development files not found, fontconfig won't be supported. configure: libgsm 32-bit development files not found, gsm 06.10 codec won't be supported. configure: libtiff 32-bit development files not found, TIFF won't be supported. configure: libmpg123 32-bit development files not found (or too old), mp3 codec won't be supported. configure: libopenal 32-bit development files not found (or too old), OpenAL won't be supported. configure: libldap (OpenLDAP) 32-bit development files not found, LDAP won't be supported. ******************************************************************************************************** [important] and when i try to install 32 bit version of these libraries using aptitude (since using apt-get just says unmet dependencies and exits) it tries to remove my 64 bit version of the same library. for example: ***************************************************************************************************** ali@ali-Vostro-1520:~/other_drive/wine32$ sudo aptitude install libxi-dev:i386 The following NEW packages will be installed: libxi-dev:i386{b} 0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 204 kB of archives. After unpacking 638 kB will be used. The following packages have unmet dependencies: libxi-dev : Conflicts: libxi-dev:i386 but 2:1.7.1.901-1ubuntu1 is to be installed. libxi-dev:i386 : Conflicts: libxi-dev but 2:1.7.1.901-1ubuntu1 is installed. The following actions will resolve these dependencies: Remove the following packages: 1) libatspi2.0-dev 2) libgtk2.0-dev 3) libxi-dev 4) libxtst-dev Accept this solution? [Y/n/q/?] y ******************************************************************************************************** [important] In one of these 32 bit installation aptitude removed my wine1.7 package and now i can't even install wine from official wine repository. so my questions are: 1_how you guys setup your environment for wine development? 2_how you deal with package managers when it acts weird?

2 1

Re: [PATCH 3/5] opengl32: Introduce wrappers for glGetIntegerv and glGetStringi. (v2)
by Alexandre Julliard 10 Feb '15

10 Feb '15

Matteo Bruni <mbruni(a)codeweavers.com> writes: > @@ -834,6 +849,9 @@ PROC WINAPI wglGetProcAddress( LPCSTR name ) > *func_ptr = driver_func; > } > > + if (!strcmp(name, "glGetStringi")) > + return (void *)glGetStringi; It seems to me you could handle this one through the extension table instead of special casing it. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] winecfg: Double click in dlls list to edit overides; fix indent. (try 2)
by Andrew Eikum 10 Feb '15

10 Feb '15

On Fri, Feb 06, 2015 at 10:23:15AM +0800, Hao Peng wrote: > Add a feature to winecfg. User can double click in dlls list to edit overides of selected item. > > the indent of code here mixed with tabs, 4 spaces and 8 space. I formated it to match the style of the rest code. > Usually we don't take patches that change nothing except formatting. I think your first patch was rejected because it adds even more inconsistent formatting. The indent is too small. The "case CBN_DBLCLK" line should be indented the same as the "case LBN_SELCHANGE" line. Instead it's indented 8 spaces when it should be indented 16 spaces. Andrew

1 0

Re: [2/6] dxgi: Add interface for IDXGISurface1
by Jacek Caban 10 Feb '15

10 Feb '15

Hi Martell, On 02/09/15 10:28, Martell Malone wrote: > + uuid( 4ae63092-6327-4c1b-80ae-bfe12ea32b86), > + local, > + pointer_default(unique) > +] > +interface IDXGISurface1 : IDXGISurface Once again, please make sure that your patches builds before sending patches. ../tools/widl/widl -o dxgi.h -m32 -I. -I../include -D__WINESRC__ dxgi.idl dxgi.idl:175: error: syntax error, unexpected aKNOWNTYPE, expecting tIMPORT Jacek

2 1

Re: rpcrt4: add a stub for I_RpcBindingInqLocalClientPID
by Dmitry Timoshkov 10 Feb '15

10 Feb '15

Austin English <austinenglish(a)gmail.com> wrote: > +RPC_STATUS WINAPI I_RpcBindingInqLocalClientPID(RPC_BINDING_HANDLE ClientBinding, unsigned long *ClientPID) > +{ > + FIXME("%p %p: stub\n", ClientBinding, ClientPID); > + return RPC_S_INVALID_BINDING; > +} This can't work under all platforms for obvious reasons. -- Dmitry.

2 1

Problem in compiling wine on 64 bit system
by Ali Aminian 10 Feb '15

10 Feb '15

Hello wine community I have some difficulty compiling wine on 64 bit ubuntu 14.04. I'm following the guide in http://wiki.winehq.org/Wine64 which i also replicate here: cd $HOME mkdir wine64 cd wine64 ../wine-git/configure --enable-win64 make > make.log 2>&1 cd .. mkdir wine32 cd wine32 ../wine-git/configure --with-wine64=../wine64 make > make.log 2>&1 #make install #cd ../wine64 #make install I can build the wine64 without any difficulty except that after configuration it prompts me that i don't have libhal, but i just ignored that. But when i get into win32 it gives me numerous warning that 32-bit development files not found, and some option will be disabled. for example: ************************************************************************************************** configure: OpenCL 32-bit development files not found, OpenCL won't be supported. configure: pcap 32-bit development files not found, wpcap won't be supported. configure: libdbus 32-bit development files not found, no dynamic device support. configure: lib(n)curses 32-bit development files not found, curses won't be supported. configure: libsane 32-bit development files not found, scanners won't be supported. configure: liblcms2 32-bit development files not found, Color Management won't be supported. configure: libz 32-bit development files not found, data compression won't be supported. configure: gstreamer-0.10 base plugins 32-bit development files not found, gstreamer support disabled configure: libcapi20 32-bit development files not found, ISDN won't be supported. configure: libcups 32-bit development files not found, CUPS won't be supported. configure: fontconfig 32-bit development files not found, fontconfig won't be supported. configure: libgsm 32-bit development files not found, gsm 06.10 codec won't be supported. configure: libtiff 32-bit development files not found, TIFF won't be supported. configure: libmpg123 32-bit development files not found (or too old), mp3 codec won't be supported. configure: libopenal 32-bit development files not found (or too old), OpenAL won't be supported. configure: libldap (OpenLDAP) 32-bit development files not found, LDAP won't be supported. ******************************************************************************************************** [important] and when i try to install 32 bit version of these libraries using aptitude (since using apt-get just says unmet dependencies and exits) it tries to remove my 64 bit version of the same library. for example: ***************************************************************************************************** ali@ali-Vostro-1520:~/other_drive/wine32$ sudo aptitude install libxi-dev:i386 The following NEW packages will be installed: libxi-dev:i386{b} 0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 204 kB of archives. After unpacking 638 kB will be used. The following packages have unmet dependencies: libxi-dev : Conflicts: libxi-dev:i386 but 2:1.7.1.901-1ubuntu1 is to be installed. libxi-dev:i386 : Conflicts: libxi-dev but 2:1.7.1.901-1ubuntu1 is installed. The following actions will resolve these dependencies: Remove the following packages: 1) libatspi2.0-dev 2) libgtk2.0-dev 3) libxi-dev 4) libxtst-dev Accept this solution? [Y/n/q/?] y ******************************************************************************************************** [important] In one of these 32 bit installation aptitude removed my wine1.7 package and now i can't even install wine from official wine repository. so my questions are: 1_how you guys setup your environment for wine development? 2_how you deal with package managers when it acts weird?

1 0

(no subject)
by The Cheese 09 Feb '15

09 Feb '15

Hi, I'm a newbie. I would really like to help with the development of Wine in any capacity I can. The thing is, I looked over the bugzilla and various ways to get the stacktrace, etc. However, finding the cause simply by looking at address calls and returns eludes me. Is there something which might help me get there faster, for eg: reading up on instruction sets on x86 chipsets etc? I've already looked over the winedev-guide. Thanks for any help.

2 1

Re: [PATCH 1/4] wine-headers: add a winapifamily header
by Martell Malone 09 Feb '15

09 Feb '15

> > First, the 1/4 patch is really something you'll have to convince > Alexandre of it's the right thing to do. The easiest way is probably > to ask him about it on IRC. The amount of advice I can give on that > one is limited, but it would probably help if you could show why Wine > needs the winapifamily mechanism. The best way to do that may very > well just be to show that applications need e.g. the > WINAPI_FAMILY_DESKTOP_APP constant to compile against the Wine > headers. > I will ask him on IRC. Yes well it would be more correct to have the header in the case where a program uses that ifdef So this would match the official instructions from MS on using different api's I could also imagine that you'll be asked to partition the > other Wine headers as well if we're going to have this mechanism in > Wine. I.e., I don't think it makes a lot of sense to only do this for > a couple of dxgi headers, but not for anything else. The prefix for > the subject should be "include:". I'd move this patch to the end of > the series. > Initially I would have only done the dx stuff because mingw-w64 shares those headers. Essentially they Jacek Caban pulls in the d3d11 headers and idls from wine in to mingw-w64 to update. I could update the mingw-w64 project with the changes but I didn't want to leave wine out of the loop. I do understand that all headers would need to be partitioned to support this eventually. I was hoping the start would be with directx > The comment is pretty superfluous. > I can take it out. In patch 2/4, you have unrelated style changes for e.g. > IDXGIDevice2::OfferResources() > . I happen to like the new style better, > but please don't do that. First add the new stuff, then send a patch > to make the existing stuff consistent with dxgi.idl at the end of the > series. > Sure I can do that Some general style stuff: > - I think "{" on the same line for enum/struct/interface declarations is > ugly. > - Use "DXGI_OUTDUPL_DESC *desc" instead of "DXGI_OUTDUPL_DESC* desc", > etc. > - There are a couple of parameter naming issues. e.g. "pDevice", > "colorSpace", "pStats", "Data", etc. > - I prefer the order of things to be macros/constants, enums, > structs, interfaces, functions instead of having those interleaved > through the header. > - "FLOAT" -> "float", "LPCWSTR" -> "const WCHAR *" > - "num_*" -> "*_count" > > The prefix for the dxgi IDL patches should be "dxgi:", for the d3d11 > one it should be "d3d11:". > Seems easy enough to follow :) On Fri, Feb 6, 2015 at 1:05 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > I had a look at this series, and have a couple of comments. > > First, the 1/4 patch is really something you'll have to convince > Alexandre of it's the right thing to do. The easiest way is probably > to ask him about it on IRC. The amount of advice I can give on that > one is limited, but it would probably help if you could show why Wine > needs the winapifamily mechanism. The best way to do that may very > well just be to show that applications need e.g. the > WINAPI_FAMILY_DESKTOP_APP constant to compile against the Wine > headers. I could also imagine that you'll be asked to partition the > other Wine headers as well if we're going to have this mechanism in > Wine. I.e., I don't think it makes a lot of sense to only do this for > a couple of dxgi headers, but not for anything else. The prefix for > the subject should be "include:". I'd move this patch to the end of > the series. > > > +/* wine wants all the api's by default so we set to desktop + app */ > > +#ifndef WINAPI_FAMILY > > +#define WINAPI_FAMILY WINAPI_FAMILY_DESKTOP_APP > > +#endif > The comment is pretty superfluous. > > In patch 2/4, you have unrelated style changes for e.g. > IDXGIDevice2::OfferResources(). I happen to like the new style better, > but please don't do that. First add the new stuff, then send a patch > to make the existing stuff consistent with dxgi.idl at the end of the > series. > > Some general style stuff: > - I think "{" on the same line for enum/struct/interface declarations is > ugly. > - Use "DXGI_OUTDUPL_DESC *desc" instead of "DXGI_OUTDUPL_DESC* desc", > etc. > - There are a couple of parameter naming issues. e.g. "pDevice", > "colorSpace", "pStats", "Data", etc. > - I prefer the order of things to be macros/constants, enums, > structs, interfaces, functions instead of having those interleaved > through the header. > - "FLOAT" -> "float", "LPCWSTR" -> "const WCHAR *" > - "num_*" -> "*_count" > > The prefix for the dxgi IDL patches should be "dxgi:", for the d3d11 > one it should be "d3d11:". >

3 5

Re: setupapi: fix string conversion in SetupGetInfInformationA()
by Jacek Caban 08 Feb '15

08 Feb '15

Hi Pierre, On 02/08/15 19:59, Pierre Schweitzer wrote: > inf = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + if (!inf) > + { > + SetLastError(ERROR_NOT_ENOUGH_MEMORY); > + return FALSE; You don't need to call SetLastError here. It's already set by HeapAlloc on failure. Jacek

2 2

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog() (try 2)
by Nikolay Sivov 07 Feb '15

07 Feb '15

This one is clearly broken regarding critical section usage.

1 0

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog()
by Nikolay Sivov 07 Feb '15

07 Feb '15

Hi, Pierre. Some comments for your patch. > --- a/dlls/setupapi/Makefile.in > +++ b/dlls/setupapi/Makefile.in > @@ -11,6 +11,7 @@ C_SRCS = \ > diskspace.c \ > fakedll.c \ > install.c \ > + log.c \ > misc.c \ > parser.c \ > query.c \ I'm not sure you need a new file for that. It depends on how much will be possibly added in the future, but general rule I think is to try to find a room in existing files. > +#include "wine/debug.h" > +#include "windef.h" > +#include "winbase.h" > +#include "winuser.h" > +#include "winreg.h" > +#include "setupapi.h" > +#include "winnls.h" Looks like you don't need all of those. > +HANDLE setupact = INVALID_HANDLE_VALUE; > +HANDLE setuperr = INVALID_HANDLE_VALUE; Should be static. > + LPWSTR msg = (LPWSTR)MessageString; I see what you want to do, but it's a bit ugly imho. > + if (MessageString) > + { > + len = lstrlenA(MessageString) + 1; > + msg = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > + MultiByteToWideChar(CP_ACP, 0, MessageString, -1, msg, len); > + } Please check for memory allocation failure. > + ret = WriteFile(setupact, MessageString, lstrlenW(MessageString) * sizeof(WCHAR), NULL, NULL); > + ret = WriteFile(setuperr, MessageString, lstrlenW(MessageString) * sizeof(WCHAR), NULL, NULL); You can probably do strlenW() once. > + GetWindowsDirectoryW(path, MAX_PATH); Same, you need to get this path once. > + if (setupact != INVALID_HANDLE_VALUE) > + { > + CloseHandle(setupact); > + setupact = INVALID_HANDLE_VALUE; > + } > + > + if (setuperr != INVALID_HANDLE_VALUE) > + { > + CloseHandle(setuperr); > + setuperr = INVALID_HANDLE_VALUE; > + } You can just CloseHandle() unconditionally. I think it also makes sense to SetupCloseLog() on PROCESS_DETACH, but that's easy to test. Another thing to test is to see what happens in multithreaded case, if it works correctly on windows you need to protect those handles in SetupOpenLog/SetupCloseLog, maybe somewhere else too.

2 1

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog()
by Marvin 07 Feb '15

07 Feb '15

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=11472 Your paranoid android. === wvistau64 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w2008s64 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w7u (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w8 (32 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === wvistau64 (64 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87 === w2008s64 (64 bit log) === log.c:57: Test failed: SetupLogError succeeded log.c:58: Test failed: got wrong error: 87

1 0

Re: server: Filter WM_QUIT message in PeekMessage call if PM_QS_POSTMESSAGE was not specified
by Marvin 06 Feb '15

06 Feb '15

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=11458 Your paranoid android. === w7u (32 bit msg) === msg.c:12112: Test failed: unexpected hwnd 0017014A msg.c:12134: Test failed: bad time 309ee/309fe

2 1

Re: ntdll load_dll broken WoW behavior
by Patrick Rudolph 06 Feb '15

06 Feb '15

Am 2015-02-06 12:07, schrieb Nikolay Sivov: > On 06.02.2015 14:02, Patrick Rudolph wrote: >> Am 2015-02-06 09:22, schrieb Nikolay Sivov: >>> On 06.02.2015 11:12, Patrick Rudolph wrote: >>>> Hi guys, >>>> I tried WoW as it seems to be in a good shape, but run into same >>>> issues. >>>> I hope you can clarify. >>>> I've got an game that has two executables, 32bit and 64bit. It >>>> places a >>>> 32bit version of xinput1_3.dll in the same folder on startup. >>>> Trying to start the 32bit version works fine, however starting the >>>> 64bit >>>> version doesn't work. >>>> For me it looks like the ntdll load_dll is the fault. >>>> It searches for builtin xinput1_3 and finds the 32bit dll in the >>>> game >>>> folder. It fails to open it (wrong ARCH) and that's it. >>>> Instead of trying other directories it tries to load native. >>>> Again it opens the first file found in the given path, it's the same >>>> file again, it fails to open it and the application terminates. >>>> >>>> Why doesn't it check for correct ARCH ? >>>> Why doesn't it walk all directories / all path given, instead of >>>> just >>>> using the first file found ? >>> >>> What do you mean by that? It doesn't check usual System32 dir for 64 >>> bit dll, is that what you expect? >>> >> Why doesn't it check for files in syswow64 ? > > Because syswow64 is a directory for 32bit system dlls/exes. So for > 64bit process it doesn't make much sense to look for dependencies > there. So system32 contains 64bit libraries and syswow64 32bit libraries... OK. then why doesn't it look into system32 for the correct dll ? > >>> >>>> Does Windows 64bits behave the same ? >>> >>> Does this game work in Windows with same conditions? Or any minimal >>> test case for that matter, like 64bit exe + 32bit dll with >>> appropriate >>> name, is that what you see? >>> >> I guess it is working, why should a vendor release a non functional >> game ? >> But I cannot test it, as I do not own a Windows. > > Maybe you just need 64bit version of xinput then? I can't place it in the same folder as there's already a 32bit version. Why doesn't it take the 64bit version in system32. > >>> >>>> Regards >>>> >>>> >>

3 2

Re: ntdll load_dll broken WoW behavior
by Patrick Rudolph 06 Feb '15

06 Feb '15

Am 2015-02-06 09:22, schrieb Nikolay Sivov: > On 06.02.2015 11:12, Patrick Rudolph wrote: >> Hi guys, >> I tried WoW as it seems to be in a good shape, but run into same >> issues. >> I hope you can clarify. >> I've got an game that has two executables, 32bit and 64bit. It places >> a >> 32bit version of xinput1_3.dll in the same folder on startup. >> Trying to start the 32bit version works fine, however starting the >> 64bit >> version doesn't work. >> For me it looks like the ntdll load_dll is the fault. >> It searches for builtin xinput1_3 and finds the 32bit dll in the game >> folder. It fails to open it (wrong ARCH) and that's it. >> Instead of trying other directories it tries to load native. >> Again it opens the first file found in the given path, it's the same >> file again, it fails to open it and the application terminates. >> >> Why doesn't it check for correct ARCH ? >> Why doesn't it walk all directories / all path given, instead of just >> using the first file found ? > > What do you mean by that? It doesn't check usual System32 dir for 64 > bit dll, is that what you expect? > Why doesn't it check for files in syswow64 ? > >> Does Windows 64bits behave the same ? > > Does this game work in Windows with same conditions? Or any minimal > test case for that matter, like 64bit exe + 32bit dll with appropriate > name, is that what you see? > I guess it is working, why should a vendor release a non functional game ? But I cannot test it, as I do not own a Windows. > >> Regards >> >>

2 1

How WINE implements BitBlt function?
by John Found 06 Feb '15

06 Feb '15

This question arouse when I have made some tests in assembly language. I have wrote a program that to allocate some memory bitmap, fill it with some image and then draw it on a window. The in-memory processing is pretty fast so the main time consuming operation is the drawing of the bitmap on the window. The code is the same for the Windows and Linux version of the program and only the code that draws the bitmap on the window differs. In the Windows version it uses DIB and BitBlt function and in the Linux version it uses XImage bitmap and XPutImage function from XLib. I expected to have some similar performance of both programs, but was surprised, that in WINE, the Windows version performs approximately by 50% faster (150fps) than the Linux version (90..100fps) and the Linux version loads the CPU much higher than the Windows one. So, the question: How in WINE is implemented BitBlt function in order to have so high performance and so low CPU load? -- John Found <johnfound(a)asm32.info>

4 11

ntdll load_dll broken WoW behavior
by Patrick Rudolph 06 Feb '15

06 Feb '15

Hi guys, I tried WoW as it seems to be in a good shape, but run into same issues. I hope you can clarify. I've got an game that has two executables, 32bit and 64bit. It places a 32bit version of xinput1_3.dll in the same folder on startup. Trying to start the 32bit version works fine, however starting the 64bit version doesn't work. For me it looks like the ntdll load_dll is the fault. It searches for builtin xinput1_3 and finds the 32bit dll in the game folder. It fails to open it (wrong ARCH) and that's it. Instead of trying other directories it tries to load native. Again it opens the first file found in the given path, it's the same file again, it fails to open it and the application terminates. Why doesn't it check for correct ARCH ? Why doesn't it walk all directories / all path given, instead of just using the first file found ? Does Windows 64bits behave the same ? Regards

2 1

Re: include: add msasn1.h
by Charles Davis 05 Feb '15

05 Feb '15

> On Feb 5, 2015, at 1:20 PM, Austin English <austinenglish(a)gmail.com> wrote: > +typedef unsigned long ASN1uint32_t; > +typedef signed long ASN1int32_t; This won’t do what you (apparently) expect on 64-bit. At the very least, you should use ULONG/DWORD and LONG here. > +#ifndef WINAPI > +#define WINAPI __stdcall > +#endif This is most certainly wrong for Wine. I think you should include “windef.h” if you need WINAPI. I’m beginning to wonder if you copied this header (as well as <hidpi.h>) directly from Microsoft’s SDKs. You’ve been around long enough to know that that’s a big no-no around here. Chip

2 3

Re: [PATCH] dsound/tests: Add a test for SetFX.
by Marvin 05 Feb '15

05 Feb '15

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=11445 Your paranoid android. === w2000pro (32 bit dsound8) === dsound8.c:1282: Test failed: IDirectSoundBuffer8_Play() failed: 88780046 === wxppro (32 bit dsound8) === dsound8.c:1282: Test failed: IDirectSoundBuffer8_Play() failed: 88780046 === wvistau64 (32 bit dsound8) === dsound8.c:1187: Test failed: DirectSoundCreate8() failed: 88780078 === w2008s64 (32 bit dsound8) === dsound8.c:1187: Test failed: DirectSoundCreate8() failed: 88780078 === w7u (32 bit dsound8) === dsound8.c:1282: Test failed: IDirectSoundBuffer8_Play() failed: 88780046 === w8 (32 bit dsound8) === dsound8.c:1282: Test failed: IDirectSoundBuffer8_Play() failed: 88780046 === wvistau64 (64 bit dsound8) === dsound8.c:1187: Test failed: DirectSoundCreate8() failed: 88780078 === w2008s64 (64 bit dsound8) === dsound8.c:1187: Test failed: DirectSoundCreate8() failed: 88780078

1 0

Re: [PATCH 1/2] ntdll: Support 64-bit Mac OS. (try 2)
by Alexandre Julliard 05 Feb '15

05 Feb '15

Charles Davis <cdavis5x(a)gmail.com> writes: > +/********************************************************************** > + * NtCurrentTeb (NTDLL.@) > + * > + * FIXME: This isn't exported from NTDLL on real NT. This should be > + * removed if and when we can set the GSBASE MSR on Mac OS X. > + */ > +TEB * WINAPI NtCurrentTeb(void) > +{ > +#ifdef __APPLE__ > + return pthread_getspecific( teb_key ); > +#elif defined(__GNUC__) > + struct _TEB *teb; > + __asm__(".byte 0x65\n\tmovq (0x30),%0" : "=r" (teb)); > + return teb; > +#else > +# error Please define retrieving the current TEB for your platform > +#endif > +} You can't do it that way: ../../../wine/dlls/ntdll/signal_x86_64.c:3481:31: error: redefinition of ‘NtCurrentTeb’ In file included from ../../../wine/include/windef.h:258:0, from ../../../wine/dlls/ntdll/signal_x86_64.c:59: ../../../wine/include/winnt.h:2288:84: note: previous definition of ‘NtCurrentTeb’ was here -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/3] jscript: Don't use builtin property for a few more constructors.
by Marvin 05 Feb '15

05 Feb '15

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=11440 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

1 0

Re: [PATCH 1/4] wine-headers: add a winapifamily header
by Stefan Dösinger 05 Feb '15

05 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, These patches are much more readable than the previous submissions! Am 2015-02-05 um 11:48 schrieb Martell Malone: > +#define WINAPI_PARTITION_DESKTOP 0x1 > +#define WINAPI_PARTITION_APP 0x2 > + > +#define WINAPI_FAMILY_APP WINAPI_PARTITION_APP > +#define WINAPI_FAMILY_DESKTOP_APP (WINAPI_PARTITION_DESKTOP \ > + | WINAPI_PARTITION_APP) This matches the definition of the Windows Kit 8.0 headers. In Windows Kit 8.1 this header looks quite different. Do you know what the intention of this is? Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU01O3AAoJEN0/YqbEcdMwJp4P+QHvB3snnXN2MC17+ZZxsjIz ZyUB28KCTlZJnXhQKEA/VOAOLrgGZOYWLd/qkW7gfRt1BSyiSS7hkuJAsdSkH43C AvXtY+HOumbewEkLl/MHfdk2yUgyzrgmv629jimeb83HnlzQG++b77WFSOQsYe4n T0kSibogJteL0TMgfHI1W5KtRJe95z8JpxBtIiPHGMlSSZHKLPEBDN8Tv8xSpkcw rHFW/HBxqeWLSpaz/YUAcMNDYNrIMY7DzgPW0MQRBewmQxRFc3hotyV2fnv7nUyZ nhlFruERczDBVOVYG1WIZ+28zawqMC9G93n+Emjl6szWRr4I/JtuB+ewHejr8HF4 8H35Ein5kQHSgkIeKPEarp9JwgbWpGOaWInLi8Y6K597oGJknzSv2snhenbOvx2T OUfbdmTgcwlIDsCN1dFzlVoAMV7UExDvx10H7rmdM7Ls0nhsL5TO0/jT25nbKMJa 5pyag4LISSQmKqLXTy24gRk27NplpiTwXNi37BQSw5BV0HJndSMxXfZgWE4jxQrL 9xYPvtEgaHofqdL3eo1M3FDownTmj7RJ4OAVuqgdAqfl7PfTKukgXXPuz9pQUuHL VHJ8CaUYcT41pdspys3iEZWGUMAui0kCzoisOKJPQpoTQ499r0uQysBkwNBeqPyh qfVxUc/oUsQlGkQtaA/N =OVYb -----END PGP SIGNATURE-----

2 2

Re: d3dx9_36: add D3DXDisassembleShader stub (try 2)
by Stefan Dösinger 05 Feb '15

05 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-02-05 um 05:14 schrieb Austin English: > +HRESULT WINAPI D3DXDisassembleShader(const DWORD *shader, BOOL > colorcode, LPCSTR comments, LPD3DXBUFFER *disassembly) Please no LPCRAP: LPCSTR -> const char * LPD3DXBUFFER * -> ID3DXBuffer ** It is even written this way in our header. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0yySAAoJEN0/YqbEcdMwXNsP/RgpIfaoj7Xhc0QXmCfH4Idh 9A9ohj99ZYAgK4QRaxXwNU9Uoys4TpJVxTDZ31C8WgnSosY+RUPt5hHx64Qe7LY+ wCwDC4wGJGZGVdPmlmTdahhQi9G8BauTs9uHcVvMZThllgfhgGHPOjn90muzcSyx PcXd2cOVnzJwaUNmJ7BrFt1luzqdRUW+v0xu31a8wsFFeIMQGA99DEeDu2ZOiu6/ UWArtccpb0QrDP/A4C5+YAuMcQHeQvWbGMrsCnrm3DBCJN46AIlLcQzw73Leq17Q aY3g6uct8SpCXD8p+KNXfe6FU/qe52QFHjI6yVS9FgjYuHwkjUuIH2CN4au7Dq22 WMt9NZI/fys+MZ5ThKmd6W10kMUpbcHHQxWbDf2zbzaGOxWX+vULNVQhMoCppCF6 0PsYhz+A5HadKgbkk28bhoIVDLefEevw/ov4X1veXEwO/0Xyb/YeLF5XiykM2LQG q6cIAik1kpawJ+YIZYILSZUjgxFmR2q5UF+qotucNdQhbNwfai0MdMMxFZMtxeUD OWwEpILVCp8JLPnTaXYt7D231TPsvLdh0hWMUy6Sk0pOsi8wVf5tO21UO3UT9Vas 7GDaW04KyzKBfD6ArONETOKHGYeozvghmPCmTrA/c8JZ69JBCuA+qk4KdjJ4RvKB rTs9Aao9URRAA9Q4PBM/ =c5KR -----END PGP SIGNATURE-----

2 3

Re: d3dx9_36: add a stub for D3DXDisassembleShader
by Dmitry Timoshkov 05 Feb '15

05 Feb '15

Austin English <austinenglish(a)gmail.com> wrote: > +@ stdcall D3DXDisassembleShader(ptr long ptr ptr) ... > +HRESULT WINAPI D3DXDisassembleShader(const DWORD *shader, BOOL colorcode, LPCSTR comments, LPD3DXBUFFER *disassembly) LPCSTR -> spec -> str -- Dmitry.

2 1

Re: ieframe:add app: protocol support to make mshtml trigger BeforeNavigate2 event when handle app: hyperlink
by Jacek Caban 05 Feb '15

05 Feb '15

Hi Changhui, On 01/15/15 02:39, Changhui Liu wrote: > Hi, this verify test need the user click the app: hyperlink in browser, > so it is hard to write a test in dlls/ieframe/tests. > > I upload the test html file and a test exe here: > http://www.imakevideo.com/app.html > http://www.imakevideo.com/mfc_web.zip > > To run the test, extract mfc_web.zip, then run the mfc_web.exe, click > the Go button; > A message "BeforeNavigate2 app:xxx" will popup when click the > app: hyperlink > if the BeforeNavigate2 event was triggered as like IE in windows, or > nothing. It doesn't seem right. There is nothing special about app: protocol handling, BeforeNavigate2 should be called in this case the same way as for any other protocol. You need to find the real reason why it's not called instead of calling it in an error case. The bug is likely to be in mshtml. Jacek

2 4

Re: jscript: Don't use builtin property for exposing Boolean constructor.
by Marvin 04 Feb '15

04 Feb '15

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=11427 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

1 0

Re: [PATCH 3/3] dwrite/tests: Fix couple of leaks when creating test font instance (resent)
by Marvin 04 Feb '15

04 Feb '15

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=11425 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/3] dwrite: No need for return value in collection_find_family()
by Alexandre Julliard 04 Feb '15

04 Feb '15

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -1424,11 +1424,14 @@ static HRESULT WINAPI dwritefontcollection_GetFontFamily(IDWriteFontCollection * > return create_fontfamily(This->family_data[index], iface, family); > } > > -static HRESULT collection_find_family(struct dwrite_fontcollection *collection, const WCHAR *name, UINT32 *index, BOOL *exists) > +static void collection_find_family(struct dwrite_fontcollection *collection, const WCHAR *name, UINT32 *index, BOOL *exists) Returning the index instead would probably make the code cleaner. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] dwrite/tests: Fix couple of leaks when creating test font instance
by Marvin 04 Feb '15

04 Feb '15

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=11424 Your paranoid android. === build (build) === Patch failed to apply

2 1

Re: [1/1] wine3d3: dxgi 1.2 add missing functions and structs to the idl
by Stefan Dösinger 04 Feb '15

04 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 02/04/15 11:11, Martell Malone wrote: > In terms of the order only the winapifamily.h patch needs to be > applied first. The rest can be applied in any order as they are > all independent of each other > > Is that okay of do you want me to resend them all with numbers ?? I'd say wait until tomorrow. Give Henri a chance to comment on what he wants regarding the code style inconsistencies, and give Alexandre a chance to state his opinion on winapifamily.h. Adding another copy of the patches to the list doesn't make it easier to follow them. If you have no reply by tomorrow resend them in a proper order and numbering. (Note that I haven't checked your header patches for correctness yet. I'll do that after I've retested the Marco d3d window minimization bug. It was a bit difficult to figure out which patches need review and which are outdated.) Also, please be careful about reply vs reply to list / all. You have dropped wine-devel from CC, that makes it impossible for others to follow the discussion. I've taken the liberty to re-add the CC. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU0fcJAAoJEN0/YqbEcdMwbtsP/RE6rtCtTF7uR4VOVjPwTjMz gV8NLhpBHuyin0vGR19l2f3FPm5SmRs2kXx9IWHofiOP//9fgPq6UhEXbLTHNvr8 YPodrahaRgryH2EcCRqZyNIVsA2JfYtEoweYUFPavHuOF+bQRdXrVYhEAhWye78o jjY0v6j7xd2vhJZ0yy3bNWNqetOHbH7HxOcBUVn2m0vIvEimONLidbCce5nh+51G 7xPP1dLbhvrFTWn9105z+TE1ewKCH1sbWkiJCcS4s+BBawhYEd4JUout0zNPG2A5 kOjEOXn3Zbu9mCoZMhg8VsbpVnyXTziZizfQmRGYOl8W9KRzQj155w/MZw4OvUa7 szVXkrDLTaVC6Qiv0UdxvgdlQKEG7C7iXaMK3jyIYo/NdwWQ4tP+3sv0ABUgQym4 UB1Fh5n72EZQULmjayRssUaj9pIv8mp+qQaPN37XE92ltoGvZvJ508ByhWln5ISH 65SixDTcvwkodOhNwPJyu63xYl/XHTt8vmp165H/KbMjPnaLwh1gjKSKmDSthLcq wcoKEgA2Pinu0Nbu4moR8GalA5LJPn9DgGsIIQSLvswnfcEd2YtAElijZYGnDysz DR2m8yBwpIqKmwPc0CJCK902RkbhtEu2YlQI6LEpwsAqnjVp+E7S3Yug3LmzHx8N becMTAgSQ0QabsodzW5K =YbZR -----END PGP SIGNATURE-----

1 0

Re: [1/1] wine3d3: dxgi 1.2 add missing functions and structs to the idl
by Stefan Dösinger 04 Feb '15

04 Feb '15

Am 03.02.2015 um 20:02 schrieb Martell Malone <martellmalone(a)gmail.com>: > wined3d and not win3d3 in the commit message Actually, the proper thing would be "include". Your d3d11 patch should state "d3d11: ...", but you don't have to resend because of this. Overall your patch submissions are difficult to follow. It isn't really clear to me in which order they should be applied, and which patch supersedes which. Generally, when a patch supersedes a previous patch please state so in the header line, e.g. "Include: Add missing dxgi 1.2 functions and structs to the idl (try 2)" . When patches depend on each other, like the dxgi and winapifamily patches, submit them in a series and mark them [1/3], [2/3] and [3/3]. git-send-email takes care of that if you use it, and git-format-patch will also create appropriate headers.

1 0

Re: Add d3d11_CreateDeviceAndSwapChain
by Stefan Dösinger 04 Feb '15

04 Feb '15

Hi, Am 03.02.2015 um 18:38 schrieb Martell Malone <martellmalone(a)gmail.com>: > 3rd Revision of the patch with input from both > Stefan and Bruno > Thanks Guys Looks good to me. I noticed that the d3d11_main.c file does not follow the general d3d code style. Bleh. I think it's best to commit your patch, then I'll send a patch tomorrow that fixes the other function and the function headers while the file is still small. Henri Verbeet has the final word on changes to d3d code. I'll wait for a word from him.

1 0

Re: wine.inf: Add substitution for font MS Serif
by Dmitry Timoshkov 04 Feb '15

04 Feb '15

Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > --- a/loader/wine.inf.in > +++ b/loader/wine.inf.in > @@ -562,6 +562,7 @@ HKLM,%FontSubStr%,"Courier New Greek,161",,"Courier New,161" > HKLM,%FontSubStr%,"Courier New TUR,162",,"Courier New,162" > HKLM,%FontSubStr%,"Helv",,"MS Sans Serif" > HKLM,%FontSubStr%,"Helvetica",,"Arial" > +HKLM,%FontSubStr%,"MS Serif",,"Liberation Serif" > HKLM,%FontSubStr%,"MS Shell Dlg 2",,"Tahoma" > HKLM,%FontSubStr%,"Times",,"Times New Roman" > HKLM,%FontSubStr%,"Times New Roman Baltic,186",,"Times New Roman,186" Font substitutions are supposed to replicate what Windows have there and therefore list only fonts available under Windows. There is Wine\Fonts\Replacements for host to Wine font mappings. -- Dmitry.

1 0

Re: [PATCH 1/2] ntdll: Support 64-bit Mac OS.
by Alexandre Julliard 04 Feb '15

04 Feb '15

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. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: Add d3d11_CreateDeviceAndSwapChain
by Stefan Dösinger 03 Feb '15

03 Feb '15

-----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-----

2 3

Directx 11.2 idl's created
by Martell Malone 03 Feb '15

03 Feb '15

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

1 2

Re: Add d3d11_CreateDeviceAndSwapChain
by Martell Malone 03 Feb '15

03 Feb '15

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----- > > > > > > > > > > >

1 0

Any interest for SOE Landmark?
by Joni Larsen-Haikarainen 03 Feb '15

03 Feb '15

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

3 2

Re: wintrust: Add more spec entries
by Alexandre Julliard 03 Feb '15

03 Feb '15

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

1 0

Re: [1/2] loader: FreeBSD requires pre_exec() on x86_64
by André Hentschel 03 Feb '15

03 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 02.02.2015 um 21:20 schrieb David Naylor: > Just as with i386, FreeBSD requires the maximum size of the data segment to be > extended on x86_64 for Wine to work correctly. > --- > loader/main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/loader/main.c b/loader/main.c > index ac67290..bb4f949 100644 > --- a/loader/main.c > +++ b/loader/main.c > @@ -181,7 +181,7 @@ static int pre_exec(void) > return 1; /* we have a preloader on x86-64 */ > } > > -#elif (defined(__FreeBSD__) || defined (__FreeBSD_kernel__) || defined(__DragonFly__)) && defined(__i386__) > +#elif (defined(__FreeBSD__) || defined (__FreeBSD_kernel__) || defined(__DragonFly__)) && (defined(__i386__) || defined(__x86_64__)) > > static int pre_exec(void) > { > > > > This is already fixed for a while, see: https://www.winehq.org/wwn/383#Wine64%20on%20FreeBSD -> https://bugs.winehq.org/show_bug.cgi?id=34330 -> https://source.winehq.org/git/wine.git/blobdiff/036670810c7e8bf55a5ee0e71e3… -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQGcBAEBAgAGBQJUz+qIAAoJEGm5GZTakYssKKEL/1kc5U/Um4TIfoIWFCZZoenL XhlZwjyJ90hJDicOZAHCKZxIcpu5J0fld52FIB5JunJZGSVcIXtcwmp1OwiA1BT4 5QPGR1WJ2bL4MU2lWw6+IEFZoL92Z7EsFkKjEM5l+u0l/APXp/5pq7Tj61qYvyoI HWhgauD7oWSK9PThWVdT7KiLmWFMLL5Rt3wB4coVExOhNah2jfGsJUDQUW08fX6B wKIB2r+O0h7xaR+zjnZSdB8iBqSTuCasUcaq0YcT8NccPQedlKJswnVu809Ygdg4 5PDn89Y1MGbSBIlcM8PjRtQrfU7bWLqOXmbY5bpaJbRbABz39UryrW0RleDTWC/G 8sJ3jtF7sO3YILQeFaaLUc0lyD64uGnwEoeGTJjB6n4khSVG5ZCsbn+twU6TwlT4 JYRfCNLgAv/fr9LnoI54HmBuyOscpP/1k9UO/6w2mQvugLe5k6TBQoiUMkk5le93 TbyOop4cFqHXR6DPfaIRuJ1czdrqVrZ1kZySKXubSg== =gd3v -----END PGP SIGNATURE-----

2 1

[2/2] Directx 11.2 idl's d3d11_2.idl
by Martell Malone 03 Feb '15

03 Feb '15

The second idl needed for dx11.2 function and structure compliance. Please review :)

1 1

Fwd: Add d3d11_CreateDeviceAndSwapChain
by Martell Malone 02 Feb '15

02 Feb '15

This is the explanation for the d3d11 patch I submitted to wine-patches. Stefan said Henri might have an interest so I should post the explanation here Comments are welcome :) ---------- Forwarded message ---------- From: Martell Malone <martellmalone(a)gmail.com> Date: Mon, Feb 2, 2015 at 7:12 PM Subject: Re: Add d3d11_CreateDeviceAndSwapChain To: Stefan Dösinger <stefandoesinger(a)gmail.com> Whoops that sent without my comments In the d3d code we use use 8 byte extran indentation for continued lines: > > void function() > { > <4> FIXME("bla long text bla\n", > <4> <8> param1, param2); > } > I have sent an updated patch to reflect this. I'm curious, does this improve the behavior of some application? E.g. game > X now falls back to d3d9 without crashing due to the stub? > My main focus for writing this was for the mingw-w64 project that imports the headers and libs from wine. We were just casually missing 1 of the 3 most important functions so I sent in this patch :) There are 2 ways to create a device and swapchain however. You can do them seperatly or this function does them both at once. I assume that this returns the correct error like CreateDevice so that if the application has a fallback it can use it. So thats highly possible. Kind Regards Martell On Mon, Feb 2, 2015 at 7:06 PM, Martell Malone <martellmalone(a)gmail.com> wrote: > Hi Stefan, > > On Mon, Feb 2, 2015 at 6:33 PM, Stefan Dösinger <stefandoesinger(a)gmail.com > > wrote: > >> Hi, >> >> I'm curious, does this improve the behavior of some application? E.g. >> game X now falls back to d3d9 without crashing due to the stub? >> >> > +HRESULT WINAPI D3D11CreateDeviceAndSwapChain(IDXGIAdapter *adapter, >> D3D_DRIVER_TYPE driver, HMODULE swrast, UINT flags, >> > + const D3D_FEATURE_LEVEL >> *feature_levels, UINT levels, UINT sdk_version, >> > + const >> DXGI_SWAP_CHAIN_DESC *swapchain_desc, IDXGISwapChain ** swapchain, >> > + ID3D11Device **device, >> D3D_FEATURE_LEVEL *feature_level, ID3D11DeviceContext **context) >> > +{ >> > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags %#x, >> feature_levels %p, levels %#x, sdk_version %d, " >> > + "swapchain_desc %p, swapchain %p, device %p, feature_level >> %p, context %p\n", adapter, debug_d3d_driver_type(driver_type), swrast, >> > + flags, feature_levels, levels, sdk_version, swapchain_desc, >> swapchain, device, feature_level, context); >> > + return E_OUTOFMEMORY; >> sdk_version is an UINT, you need to print it with %u. >> >> In the d3d code we use use 8 byte extran indentation for continued lines: >> >> void function() >> { >> <4> FIXME("bla long text bla\n", >> <4> <8> param1, param2); >> } >> >> Cheers, >> Stefan >> >> >

1 0

Re: Add d3d11_CreateDeviceAndSwapChain
by Stefan Dösinger 02 Feb '15

02 Feb '15

Hi, I'm curious, does this improve the behavior of some application? E.g. game X now falls back to d3d9 without crashing due to the stub? > +HRESULT WINAPI D3D11CreateDeviceAndSwapChain(IDXGIAdapter *adapter, D3D_DRIVER_TYPE driver, HMODULE swrast, UINT flags, > + const D3D_FEATURE_LEVEL *feature_levels, UINT levels, UINT sdk_version, > + const DXGI_SWAP_CHAIN_DESC *swapchain_desc, IDXGISwapChain ** swapchain, > + ID3D11Device **device, D3D_FEATURE_LEVEL *feature_level, ID3D11DeviceContext **context) > +{ > + FIXME("stub: adapter %p, driver_type %s, swrast %p, flags %#x, feature_levels %p, levels %#x, sdk_version %d, " > + "swapchain_desc %p, swapchain %p, device %p, feature_level %p, context %p\n", adapter, debug_d3d_driver_type(driver_type), swrast, > + flags, feature_levels, levels, sdk_version, swapchain_desc, swapchain, device, feature_level, context); > + return E_OUTOFMEMORY; sdk_version is an UINT, you need to print it with %u. In the d3d code we use use 8 byte extran indentation for continued lines: void function() { <4> FIXME("bla long text bla\n", <4> <8> param1, param2); } Cheers, Stefan

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel