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

Compiling with GCC 5.0
by Michael Cronenworth 19 Mar '15

19 Mar '15

Has anyone given GCC 5.0 a shot? It breaks x86_64 for me and other Fedora 22+ users (22 and up use 5.0). Running wine as pure 32-bit does not exhibit issues. We're using 1.7.36 with wine-staging applied. In 64-bit mode it will not create a valid wine-prefix so I cannot run winedbg and nothing eventful happens with gdb attached to wine. Any ideas on how to debug this further? Here is the terminal output when a fresh prefix is attempted to be made: http://fpaste.org/187377/25868142/ Regards, Michael

3 9

My Ideas for GSoC 2015
by Zhenbo Li 12 Mar '15

12 Mar '15

Hello, everyone I'm Zhenbo Li, a college student who participated in GSoC 2014 for mshtml.dll. Here are some ideas for GSoC 2015. 1. IDropTargetHelper ================== This interface is to display images [1]. I'm sure that it is necessary for VPT[2], and I guess implementing this interface will contribute to programs like 7zip. Although IDropTargetHelper is a useful interface, I haven't found a proper demo(most demos depend on MFC). So I'm writing a simple demo for this interface[3], with no MFC or .NET code. 2. IXMLHttpRequest ================== XMLHttpRequest is used heavily in AJAX programming.[4] Wine has implemented most of it in msxml component, but it's a stub in mshtml. Most js code doesn't treat wine IE as IE6 or earlier, so they will not choost ActiveX[5] to work around it(like Firebug Lite[6]) 3. sessionStorage =============== IHTMLStorage[7] is used widely, including Firebug Lite[6]. A well-implemented IHTMLStorage interface should support both sessionStorage and localStorage. I tried to write a hack, but found that it may be necessary to adjust wine-gecko code to support that(Thank Jacek). Therefore, implementing sessionStorage can be the first step of implementing localStorage, and it can be an example for WebIDL binding for further development. These are my humble ideas for GSoC 2015, and I'm glad to choose one of them as my proposal, if they meet the criteria for GSoC. Also, it is my honor if my ideas make a positive effect on other GSoC students. Thank you for reading this mail. I'm looking forward to your feedback. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/bb762028%28v=vs.85… [2]: http://virtualplaytable.com/ [3]: https://gitcafe.com/endle/IDrop_Helper_Example [4]: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest [5]: http://en.wikipedia.org/wiki/XMLHttpRequest#Support_in_Internet_Explorer_ve… [6]: https://getfirebug.com/firebuglite [7]: https://msdn.microsoft.com/en-us/library/cc288313%28v=vs.85%29.aspx

1 1

Re: msvcrt: Use Dragon4 algorithm to fix inconsistent rounding behaviour for sprintf and add tests. (try 2)
by Dmitry Timoshkov 04 Mar '15

04 Mar '15

YongHao Hu <christopherwuy(a)gmail.com> wrote: > +typedef int int32_t; > +typedef unsigned char uint8_t; > +typedef unsigned long uint32_t; > +typedef unsigned long long uint64_t; Please use appropriate win32 types instead. Besides using 'typedef unsigned long uint32_t' is wrong. -- Dmitry.

2 1

Help with testing new Gecko downloader
by Jacek Caban 04 Mar '15

04 Mar '15

Hi all, My today patch [1] together with changes in Wine code from yesterday changed the way we interact with SourceForge for downloading Gecko. It's a risky change that could use wider testing from different locations. If you'd like to help, you need to: - Remove wine_gecko-2.36*.msi if you already have it. If you used downloader to get it, it's most likely in ~/.cache/wine. If you downloaded it manually, you know where to find it. - Create new wineprefix The most important thing is to ensure that downloading and installing Gecko still works. The expected difference is shorter connection time and faster downloads (or better said, no slow downloads). I appreciate any feedback on this. Thanks, Jacek [1] http://source.winehq.org/patches/data/109462

2 2

advapi32 redefines SECURITY_INFORMATION
by Francois Gouget 28 Feb '15

28 Feb '15

--- So svcctl.idl needs the SECURITY_INFORMATION definition and it's not available from any other idl file. This results in this type being defined twice when compiling dlls/advapi32/service.c: once in winnt.h and then again in dlls/advapi32/svcctl.h. We normally avoid this type of situation. An easy fix is to introduce the usual _XXX_DEFINED macro check but this seems to be a first in an idl file. Is there a better way? include/wine/svcctl.idl | 3 +++ include/winnt.h | 3 +++ 2 files changed, 6 insertions(+) diff --git a/include/wine/svcctl.idl b/include/wine/svcctl.idl index e8463b5..1c3d22f 100644 --- a/include/wine/svcctl.idl +++ b/include/wine/svcctl.idl @@ -65,7 +65,10 @@ interface svcctl typedef [context_handle] void *SC_RPC_LOCK; typedef [context_handle] void *SC_NOTIFY_RPC_HANDLE; + cpp_quote("#ifndef _SECURITY_INFORMATION_DEFINED") + cpp_quote("#define _SECURITY_INFORMATION_DEFINED") typedef DWORD SECURITY_INFORMATION; + cpp_quote("#endif") /* undocumented access rights */ cpp_quote("#define SERVICE_SET_STATUS 0x8000") diff --git a/include/winnt.h b/include/winnt.h index 4b06b2c..0a4185d 100644 --- a/include/winnt.h +++ b/include/winnt.h @@ -3971,7 +3971,10 @@ static const WCHAR SE_CREATE_GLOBAL_NAME[] = { 'S','e','C','r','e','a','t','e',' #define SE_RM_CONTROL_VALID 0x00004000 #define SE_SELF_RELATIVE 0x00008000 +#ifndef _SECURITY_INFORMATION_DEFINED +#define _SECURITY_INFORMATION_DEFINED typedef DWORD SECURITY_INFORMATION, *PSECURITY_INFORMATION; +#endif typedef WORD SECURITY_DESCRIPTOR_CONTROL, *PSECURITY_DESCRIPTOR_CONTROL; /* The security descriptor structure */ -- 2.1.4

2 1

Re: [PATCH 1/2] d3d9/tests: Extend the FPU setup test.
by Henri Verbeet 27 Feb '15

27 Feb '15

Not that I would terribly mind if this got comitted, but I have to wonder if this really has a lot of value as a regression test?

3 3

Re: [PATCH] [shell32] Implement SHRunControlPanel using ShellExecute
by Nikolay Sivov 27 Feb '15

27 Feb '15

On 26.02.2015 17:01, Robert Naumann wrote: > --- > dlls/shell32/shellord.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/dlls/shell32/shellord.c b/dlls/shell32/shellord.c > index 914dc5a..9ea3d62 100644 > --- a/dlls/shell32/shellord.c > +++ b/dlls/shell32/shellord.c > @@ -1129,8 +1129,10 @@ HRESULT WINAPI SHWinHelp (DWORD v, DWORD w, DWORD x, DWORD z) > */ > BOOL WINAPI SHRunControlPanel (LPCWSTR commandLine, HWND parent) > { > - FIXME("(%s, %p): stub\n", debugstr_w(commandLine), parent); > - return FALSE; > + if((int)ShellExecute(parent,NULL,commandLine,NULL,NULL,SW_NORMAL)>32) > + return TRUE; > + else > + return FALSE; > } Why 32? Also please don't remove tracing line.

2 2

Re: msvcrt: Use Dragon4 algorithm to fix inconsistent rounding behaviour for sprintf and add tests.
by Zhenbo Li 27 Feb '15

27 Feb '15

Hi, YongHao, Quite a huge patch lol I tried your patch. $ patch -p1 <0012-msvcrt-Use-Dragon4-algorithm-to-fix-inconsistent-round.txt (Stripping trailing CRs from patch; use --binary to disable.) patching file dlls/msvcrt/dragon4.h (Stripping trailing CRs from patch; use --binary to disable.) patching file dlls/msvcrt/printf.h (Stripping trailing CRs from patch; use --binary to disable.) patching file dlls/msvcrt/tests/printf.c (Stripping trailing CRs from patch; use --binary to disable.) patching file dlls/msvcrt/wine_printfloat.h Is this critical? Also, your patch failed to compile on my computer. dragon4.h:10:0: error: unterminated #ifndef #ifndef __WINE_STDIO_H Why is it necessary here? And then, wine_printfloat.h:26:15: error: unknown type name 'uint32_t' It seems that you're using C99 types? It is not allowed in wine code[1] Finally, you've created two files with ZLIB license. Is it better to move all the ZLIB license code to one file? I'm not sure about that. Could someone have a check to avoid legal problems? [1]: wiki.winehq.org/Developers-Hints 2015-02-26 23:13 GMT+08:00 YongHao Hu <christopherwuy(a)gmail.com>: > Fix bug https://bugs.winehq.org/show_bug.cgi?id=37913 . > The Dragon4 algorithm implementation is based on > http://www.ryanjuckett.com/programming/printing-floating-point-numbers/. > > --- > dlls/msvcrt/dragon4.h | 670 > ++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/printf.h | 43 +-- > dlls/msvcrt/tests/printf.c | 83 +++++- > dlls/msvcrt/wine_printfloat.h | 248 ++++++++++++++++ > 4 files changed, 1026 insertions(+), 18 deletions(-) > create mode 100644 dlls/msvcrt/dragon4.h > create mode 100644 dlls/msvcrt/wine_printfloat.h > > > > > -- Have a nice day! Zhenbo Li

2 1

Re: [PATCH 1/1] handling sysex midi messages in winecoreaudio
by Andrew Eikum 26 Feb '15

26 Feb '15

On Wed, Feb 25, 2015 at 09:58:41PM +0100, tinez wrote: > Hi, > > this patch fixes handling sysex midi messages in winecoreaudio > driver. The code was based on winealsa driver implementation. > I've tested it using external midi hardware + midi monitoring tools > (MidiOX). My motivation was to fix Nord Modular Editor software > which is needed to control Nord Modular G1 hardware synthetizer. > After applying the patch it works without problems. > I've also sent out patch to electro-music.com for other people to > test and it was received well (you can see the thread here > electro-music.com/forum/viewtopic.php?t=62683) > Thanks, looks mostly good. A few Wine style notes in-line below. > regards, tinez > > --- > dlls/winecoreaudio.drv/midi.c | 66 > ++++++++++++++++++++++++++++++------------- > 1 file changed, 47 insertions(+), 19 deletions(-) > From e18b1c9876730d9557b97f3e16249b20eae4e875 Mon Sep 17 00:00:00 2001 > From: tinez <tinez(a)tlen.pl> Wine requires full, real names for patches. > Date: Thu, 21 Aug 2014 23:13:31 +0200 > Subject: [PATCH 1/1] handling sysex midi messages in winecoreaudio > > --- > dlls/winecoreaudio.drv/midi.c | 66 ++++++++++++++++++++++++++++++------------- > 1 file changed, 47 insertions(+), 19 deletions(-) > > diff --git a/dlls/winecoreaudio.drv/midi.c b/dlls/winecoreaudio.drv/midi.c > index 8593e9c..c7a1ded 100644 > --- a/dlls/winecoreaudio.drv/midi.c > +++ b/dlls/winecoreaudio.drv/midi.c > @@ -437,9 +437,9 @@ static DWORD MIDIOut_LongData(WORD wDevID, LPMIDIHDR lpMidiHdr, DWORD dwSize) > return MMSYSERR_ERROR; > } > } > - else > + else if (destinations[wDevID].caps.wTechnology == MOD_MIDIPORT) > { > - FIXME("MOD_MIDIPORT\n"); > + MIDIOut_Send(MIDIOutPort, destinations[wDevID].dest, lpData, lpMidiHdr->dwBufferLength); > } > > lpMidiHdr->dwFlags &= ~MHDR_INQUEUE; > @@ -836,26 +836,55 @@ static CFDataRef MIDIIn_MessageHandler(CFMessagePortRef local, SInt32 msgid, CFD > if (src->state < 1) > { > TRACE("input not started, thrown away\n"); > - goto done; > - } > - /* FIXME skipping SysEx */ > - if (msg->data[0] == 0xF0) > - { > - FIXME("Starting System Exclusive\n"); > - src->state |= 2; > + return NULL; > } > - if (src->state & 2) > - { > - for (i = 0; i < msg->length; ++i) > - { > - if (msg->data[i] == 0xF7) > - { > - FIXME("Ending System Exclusive\n"); > - src->state &= ~2; > + > + bool sysexStart = (msg->data[0] == 0xF0); > + Wine uses C89, so we don't have 'bool'. You could change this to a BOOL instead. > + if (sysexStart || src->state & 2) { > + if (sysexStart) { > + TRACE("Receiving sysex message\n"); > + src->state |= 2; > + } > + > + int pos = 0; > + int len = msg->length; > + C89 also doesn't let you declare new variables in the middle of a block. They must be declared at the start of a block. > + EnterCriticalSection(&midiInLock); > + currentTime = GetTickCount() - src->startTime; > + > + while (len) { > + LPMIDIHDR lpMidiHdr = src->lpQueueHdr; > + > + if (lpMidiHdr != NULL) { > + int copylen = min(len, lpMidiHdr->dwBufferLength - lpMidiHdr->dwBytesRecorded); > + memcpy(lpMidiHdr->lpData + lpMidiHdr->dwBytesRecorded, msg->data + pos, copylen); > + lpMidiHdr->dwBytesRecorded += copylen; > + len -= copylen; > + pos += copylen; > + > + TRACE("Copied %d bytes of sysex message\n", copylen); > + > + if ((lpMidiHdr->dwBytesRecorded == lpMidiHdr->dwBufferLength) || > + (*(BYTE*)(lpMidiHdr->lpData + lpMidiHdr->dwBytesRecorded - 1) == 0xF7)) { > + TRACE("Sysex message complete (or buffer limit reached), dispatching %d bytes\n", lpMidiHdr->dwBytesRecorded); Tabs should be spaces, for consistency with the rest of your code. > + src->lpQueueHdr = lpMidiHdr->lpNext; > + lpMidiHdr->dwFlags &= ~MHDR_INQUEUE; > + lpMidiHdr->dwFlags |= MHDR_DONE; > + MIDI_NotifyClient(msg->devID, MIM_LONGDATA, (DWORD_PTR)lpMidiHdr, currentTime); > + src->state &= ~2; > + } > + } > + else { Here, too. > + FIXME("Sysex data received but no buffer to store it!\n"); > + break; > } > } > - goto done; > + > + LeaveCriticalSection(&midiInLock); > + return NULL; > } > + > EnterCriticalSection(&midiInLock); > currentTime = GetTickCount() - src->startTime; > > @@ -889,7 +918,6 @@ static CFDataRef MIDIIn_MessageHandler(CFMessagePortRef local, SInt32 msgid, CFD > CFRunLoopStop(CFRunLoopGetCurrent()); > break; > } > -done: > return NULL; > } > > -- > 1.9.3 (Apple Git-50)

2 2

Re: [PATCH try2] urlmon: Added IInternetBindInfo implementation to BindStatusCallback object.
by Marvin 26 Feb '15

26 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=11751 Your paranoid android. === w7u (32 bit url) === url.c:3632: Test failed: expected OnProgress_DOWNLOADINGDATA === wvistau64 (64 bit url) === url.c:3632: Test failed: expected OnProgress_DOWNLOADINGDATA

2 1