July 2017 - Wine-Devel - list.winehq.org

Re: [PATCH] gdiplus: Add stub for GdipGraphicsSetAbort

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > +static void test_GdipGraphicsSetAbort(void) > +{ > + HDC hdc = GetDC(hwnd); > + GpStatus status; > + GpGraphics *graphics; > + > + if (!pGdipGraphicsSetAbort) > + { > + win_skip("GdipGraphicsSetAbort() is not supported.\n"); > + return; hdc is leaked. > + } > + > + status = GdipCreateFromHDC(hdc, &graphics); > + expect(Ok, status); > + > + status = pGdipGraphicsSetAbort(NULL, NULL); > + expect(InvalidParameter, status); > + > + status = pGdipGraphicsSetAbort(graphics, NULL); > + expect(Ok, status); > + > + ReleaseDC(hwnd, hdc); > +} graphics is leaked. Also, it would be useful to test not invalid input as well. -- Dmitry.

July 27, 2017

Re: [PATCH 2/7] regedit: Use a helper function to allocate memory and check for a valid pointer

by Hugh McMaster

On Thursday, 27 July 2017 2:41 AM, Alexandre Julliard wrote: > That's not the standard heap_alloc(), so a different name would be > preferable. I'd suggest heap_xalloc by analogy with xmalloc. "Standard" would be a function just returning HeapAlloc(...), right? And you did mention the 'x' prefix a few days ago. Totally missed that in the patch. By the way, regedit should exit(0), but perhaps exit(1) - as in the patch - is still more appropriate for allocation failure? Thanks for the help.

July 27, 2017

Re: [PATCH] winmm: Load MCI drivers from MCI32 key.

by Zebediah Figura

On 07/26/2017 08:03 AM, Andrew Eikum wrote: > This looks good, but could you add some tests showing something that > was wrong before but is now fixed? > > Andrew > The application overwrites the value of MCI/avivideo in system.ini (to 16-bit mciavi.drv). Is this appropriate for a test?

July 26, 2017

Re: [PATCH 2/7] regedit: Use a helper function to allocate memory and check for a valid pointer

by Alexandre Julliard

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > +static void *heap_alloc(size_t size) > +{ > + void *buf; > + > + if (!(buf = HeapAlloc(GetProcessHeap(), 0, size))) > + { > + ERR("Out of memory!\n"); > + exit(1); > + } > + > + return buf; > +} That's not the standard heap_alloc(), so a different name would be preferable. I'd suggest heap_xalloc by analogy with xmalloc. -- Alexandre Julliard julliard(a)winehq.org

July 26, 2017

Re: Wine Stickers coming soon!

by Josh DuBois

That's great looking! I made myself a sweatshirt a while back with the existing logo on the back and the address of the winehq git repository on the front, and I thought it came out well. The thing attached to your email looks great also. Maybe I should make another sweatshirt with that :) I think it looks good. On 7/26/17 10:40 AM, Aric Stewart wrote: > Hello Everyone! > > Long time not update. Been a busy, busy time but Jana and I have had a chance to circle back to the swag with the goal of having a stack ready for WineConf. > > The poll concluded with the sideways bottle, Though some of the suggestions where good so we made a few tweaks and attached is the sticker we have come up with. > > We are looking into the best way to produce the sticker and it is all very excited. > > The idea is that we want people who go to events, talks, trade shows or anywhere promoting WINE to be able to have a stack of these to give away to help promote the project. > > We don't have a good distribution plan yet other than a box of stickers in my office and people e-mailing me when they need a supply. That does involve ongoing shipping costs that will have to be covered. If we have a volunteer in Europe to also have a stash then that would likely be a better plan for European people. > > There where a few questions around re-design of the Logo and such. I personally think a graphics/logo update of our web site would be awesome but I am not volunteering as I am not a graphic designer. All of Jana's designs that used the existing wine glass just did not work as well as the bottle ones we had up on the poll so we decided to be a big adventurous and go with this. > > > Finally, the idea is for this to be sort of step 1 in swag/promotion process. We want to get people reaching out, tabling, doing talks and all that sort of thing and having swag helps raise the project's status. This is of course a discussion for WineConf, but want to keep the thoughts bubbling. > > -aric > >

July 26, 2017

Wine Stickers coming soon!

by Aric Stewart

Hello Everyone! Long time not update. Been a busy, busy time but Jana and I have had a chance to circle back to the swag with the goal of having a stack ready for WineConf. The poll concluded with the sideways bottle, Though some of the suggestions where good so we made a few tweaks and attached is the sticker we have come up with. We are looking into the best way to produce the sticker and it is all very excited. The idea is that we want people who go to events, talks, trade shows or anywhere promoting WINE to be able to have a stack of these to give away to help promote the project. We don't have a good distribution plan yet other than a box of stickers in my office and people e-mailing me when they need a supply. That does involve ongoing shipping costs that will have to be covered. If we have a volunteer in Europe to also have a stash then that would likely be a better plan for European people. There where a few questions around re-design of the Logo and such. I personally think a graphics/logo update of our web site would be awesome but I am not volunteering as I am not a graphic designer. All of Jana's designs that used the existing wine glass just did not work as well as the bottle ones we had up on the poll so we decided to be a big adventurous and go with this. Finally, the idea is for this to be sort of step 1 in swag/promotion process. We want to get people reaching out, tabling, doing talks and all that sort of thing and having swag helps raise the project's status. This is of course a discussion for WineConf, but want to keep the thoughts bubbling. -aric

July 26, 2017

Re: [PATCH] winmm: Load MCI drivers from MCI32 key.

by Andrew Eikum

This looks good, but could you add some tests showing something that was wrong before but is now fixed? Andrew On Tue, Jul 25, 2017 at 09:18:15PM -0500, Zebediah Figura wrote: > MCI key/section is for 16-bit drivers, which can't be loaded by > 32-bit winmm. > > Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> > --- > dlls/winmm/mci.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/winmm/mci.c b/dlls/winmm/mci.c > index 56a537d..d770f6d 100644 > --- a/dlls/winmm/mci.c > +++ b/dlls/winmm/mci.c > @@ -66,10 +66,10 @@ WINE_DEFAULT_DEBUG_CHANNEL(mci); > #define MCI_MAGIC 0x0001 > > /* MCI settings */ > -static const WCHAR wszHklmMci [] = {'S','o','f','t','w','a','r','e','\\','M','i','c','r','o','s','o','f','t','\\','W','i','n','d','o','w','s',' ','N','T','\\','C','u','r','r','e','n','t','V','e','r','s','i','o','n','\\','M','C','I',0}; > +static const WCHAR wszHklmMci [] = {'S','o','f','t','w','a','r','e','\\','M','i','c','r','o','s','o','f','t','\\','W','i','n','d','o','w','s',' ','N','T','\\','C','u','r','r','e','n','t','V','e','r','s','i','o','n','\\','M','C','I','3','2',0}; > static const WCHAR wszNull [] = {0}; > static const WCHAR wszAll [] = {'A','L','L',0}; > -static const WCHAR wszMci [] = {'M','C','I',0}; > +static const WCHAR wszMci [] = {'M','C','I','3','2',0}; > static const WCHAR wszOpen [] = {'o','p','e','n',0}; > static const WCHAR wszSystemIni[] = {'s','y','s','t','e','m','.','i','n','i',0}; > > -- > 2.7.4 > > >

July 26, 2017

Re: Unicode normalization for Wine

by Aric Stewart

Hello, On 7/25/17 4:33 PM, Artur Świgoń wrote: > Dear All, > > My name is Artur and I'm participating in Google Summer of Code 2017 for Wine. > Under Nikolay's supervision, I'm working on implementation of Unicode > normalization. I probably should have introduced myself some time ago to share > results of my research and my ideas, but I also wanted to wait until I could > illustrate my points with some code. > Very cool! This is a problem I ran into with Japanese unicode string comparisons a while ago so it is great it will be addressed! Then we will have to investigate the CompareStringW, and family, behavior. > - Mappings for characters above 0xFFFF are encoded as UTF-16 (using surrogate > pairs), but a single codepoint (UTF-32 if you like) is used for table > indexing. Setting $utflim in make_unicode to 65536 is the simplest way to > disable support for such characters, but supporting surrogate pairs should > not affect any text-related Wine component in a negative way. > There is some super basic work on non-BMP unicode glyphs and surrogate pairs in Uniscribe (usp10). I wrote a quick decode_surrogate_pair() function to help get a DWORD unicode value for the surrogate pair. So you can look at that if you are interested! Thanks! -aric

July 26, 2017

Unicode normalization for Wine - new patch

by Artur Świgoń

I'm not sure whether I've sent the updated patch in my previous email. This one is the one that passes the number of tests I described in my previous message. Sorry for confusion. Artur

July 26, 2017

Re: [PATCH] wmvcore/tests: add tests for WMReader methods

by Jefferson Carpenter

BTW, I've got a busy day tomorrow but I'll get those changes made by Thursday. On Tue, Jul 25, 2017 at 6:01 PM, Jefferson Carpenter < jeffersoncarpenter2(a)gmail.com> wrote: > Hello, > > On Tue, Jul 25, 2017 at 5:48 PM, Alistair Leslie-Hughes < > leslie_alistair(a)hotmail.com> wrote: > >> Hi Jefferson, >> > >> > +typedef struct { >> > + IWMReaderCallback IWMReaderCallback_iface; >> > + LONG ref; >> > + HRESULT (*onStatusCallback)(WMT_STATUS, HRESULT, >> WMT_ATTR_DATATYPE, BYTE*, void*, void*); >> > + HRESULT (*onSampleCallback)(DWORD, QWORD, QWORD, DWORD, >> INSSBuffer*, void*, void*); >> > + void *pvCallbackContext; >> > +} TestWMReaderCallback; >> >> I'm still a little confused as to why you need this structure when the >> IWMReaderCallbackVtbl with a few globals would work just as well. >> > > Well, I it could be useful to only implement QueryInterface, AddRef, and > Release once, and use dependency injection to supply the other methods to > the vtable. I wasn't sure whether I was over-engineering that, however. > > >> >> > +static HRESULT onStatus_test_wmreader_play_wma( >> > + WMT_STATUS status, >> > + HRESULT hr, >> > + WMT_ATTR_DATATYPE dwType, >> > + BYTE *pValue, >> > + void *pvContext, >> > + void *pvCallbackContext) >> > +{ >> > + struct callback_context_test_wmreader_play_wma *pTestContext = >> > + (struct callback_context_test_wmreader >> _play_wma*)pvCallbackContext; >> > + DWORD *dwordValue; >> > + >> > + CHECK_EXPECT(onStatus); >> > + ok(status == onStatus_expected_statuses_tes >> t_wmreader_play_wma[pTestContext->onStatus_call_count], >> > + "onStatus called with unexpected status: %d\n", status); >> > + if (status == WMT_OPENED) { >> > + ok(pvContext == pTestContext->pvContextOpen, >> > + "onStatus was not passed pvContext: expected %p, actual >> %p\n", pTestContext->pvContextOpen, pvContext); >> > + } >> > + else /* status == WMT_STARTED, or later */ { >> > + ok(pvContext == pTestContext->pvContextStart, >> > + "onStatus was not passed pvContext: expected %p, actual >> %p\n", pTestContext->pvContextStart, pvContext); >> > + } >> > + switch (status) { >> > + case WMT_STARTED: >> > + // MSDN says dwType is a QWORD, but it is actually a DWORD >> > + ok(dwType == WMT_TYPE_DWORD, "onStatus pValue not >> WMT_TYPE_QWORD (%d), but %d\n", (int)WMT_TYPE_DWORD, dwType); >> WMT_TYPE_QWORD typo? >> >> > + dwordValue = (DWORD*)pValue; >> > + ok(*dwordValue == 0, "onStatus call for WMT_STARTED not passed >> correct starting timestamp: %u\n", *dwordValue); >> > + SET_EXPECT(onSample); >> > + break; >> > + default: >> > + break; >> > + } >> The switch and if could be merged >> > > Very well. > > >> >> > + /* Get format count. */ >> > + formatCount = 0; >> > + hr = IWMReader_GetOutputFormatCount(reader, 0, &formatCount); >> > + todo_wine ok(hr == S_OK, "Failed to get output format count: >> 0x%08x\n", hr); >> formatCount should be checked >> >> > Okay - I'll have the test check that formatCount is equal to 37. That's > the format count that I get on my windows machine. The number 37 seems > oddly specific; I'm not sure how much wiggle room wmvcore implementations > have to provide varying sets of formats. However it would be best if > wine's were identical to the Windows behavior, obviously. > > >> Best Regards >> Alistair Leslie-Hughes >> > >

July 26, 2017