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

Re: [2/6] dxgi: Add interface for IDXGISurface1
by Jacek Caban Feb. 10, 2015

Feb. 10, 2015

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 Feb. 9, 2015

Feb. 9, 2015

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 Feb. 9, 2015

Feb. 9, 2015

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(a)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 Feb. 9, 2015

Feb. 9, 2015

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 Feb. 9, 2015

Feb. 9, 2015

> > 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 Feb. 8, 2015

Feb. 8, 2015

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 Feb. 7, 2015

Feb. 7, 2015

This one is clearly broken regarding critical section usage.

1 0

Re: setupapi: Implement SetupOpenLog(), SetupLogErrorA(), SetupLogErrorW(), SetupCloseLog()
by Nikolay Sivov Feb. 7, 2015

Feb. 7, 2015

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 Feb. 7, 2015

Feb. 7, 2015

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 Feb. 6, 2015

Feb. 6, 2015

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 Feb. 6, 2015

Feb. 6, 2015

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 Feb. 6, 2015

Feb. 6, 2015

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 Feb. 6, 2015

Feb. 6, 2015

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 Feb. 6, 2015

Feb. 6, 2015

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 Feb. 5, 2015

Feb. 5, 2015

> 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 Feb. 5, 2015

Feb. 5, 2015

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 Feb. 5, 2015

Feb. 5, 2015

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 Feb. 5, 2015

Feb. 5, 2015

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 Feb. 5, 2015

Feb. 5, 2015

-----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 Feb. 5, 2015

Feb. 5, 2015

-----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 Feb. 4, 2015

Feb. 4, 2015

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 Feb. 4, 2015

Feb. 4, 2015

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 Feb. 4, 2015

Feb. 4, 2015

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 Feb. 4, 2015

Feb. 4, 2015

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 Feb. 4, 2015

Feb. 4, 2015

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