Re: [PATCH 1/2] msvcp90: Free memory allocated by _get_current_locale function
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 http://testbot.winehq.org/JobDetails.pl?Key=22858 Your paranoid android. === WVISTAADM (32 bit misc) === misc: unhandled exception c005 at 77496739 === W2K8SE (32 bit misc) === misc: unhandled exception c005 at 778A59C3 === W7PRO (32 bit misc) === misc: unhandled exception c005 at 772D1FFE === W7PROX64 (32 bit misc) === misc: unhandled exception c005 at 77DFE23E === TEST64_W7SP1 (32 bit misc) === misc: unhandled exception c005 at 7758E39E === W7PROX64 (64 bit misc) === Timeout === TEST64_W7SP1 (64 bit misc) === Timeout
Any advice please... Console input issue
Hello,
I've been looking at a patch which sorts out NUL and CON handling in a part
of the command shell, and have stumbled upon a problem I am not sure how to
fix because I really dont understand the underlying console handling, and
would appreciate someone pointing me in a direction.
For simplicity sake I've cut this down to a tiny test program, which works
on windows and fails on wine which does the following:
Opens the device ("\\.\CON") with CreateFile with GENERIC_READ rights
(which internally opens a CONIN$ device with the same access rights)
Reads from the device with ReadFile
- Because its a console device, this drops through to ReadConsoleW, which
creates a CONOUT$ and then waits on a keystroke
- Once the key is pressed (WCEL_Get) the key is 'inserted' into the input
buffer by calling WriteConsoleInputW
The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the
CON device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try
to open it with GENERIC_WRITE). CreateFile("CONIN$"...) will let me open in
GENERIC_READ/GENERIC_WRITE mode and the program works on both windows and
wine, but if you open CONIN$ GENERIC_READ only then it fails on wine and
works on windows, with the same issue.
Now on windows, this works... the question is how to make it work on
wine...
My gut feeling, with nothing backing this at all, is that WCEL_Get should
not use WriteConsoleInputW to inject the values into the input buffer,
instead making the server call directly, but passing through to the server
call something to indicate that it is ok to add the data to the buffer, but
I'm fast getting out of my depth!
Thanks for any help! I'll file a bug with my analysis and testcase, but
would rather fix the thing!
Jason
Missing dependencies on static libraries
strmbase is a static library which is used by amstream, qcap, quartz and others. This means functions defined in strmbase end up being included in amstream.dll.so and other places. However modifying the strmbase code does not result in a relink of the dlls that depend on it. Note that this is true even if running make from the top-level directory. That makes it very painful to work with it. Note that the same issue could happen with other static libraries like dxguid, uuid, etc, though those don't contain code and have little reason to change so that that's probably why the problem did not surface until now. How should we fix this? Having amstream recusively run make in strmbase would break parallel builds (the top-level Makefile enforces ordering by having __builddeps__ depend on dlls/strmbase). Would somthing like the patch below be acceptable? Should it be generalized to all the dependencies on uuid, dxguid, etc? commit 0a6764918f743912a1f76ca004ec6d9f0d679b2a Author: Francois Gouget Date: Fri Nov 9 19:45:21 2012 +0100 strmbase: Relink the dlls that depend on the strmbase static library when it changes. diff --git a/dlls/amstream/Makefile.in b/dlls/amstream/Makefile.in index 35cfae1..5e96f1a 100644 --- a/dlls/amstream/Makefile.in +++ b/dlls/amstream/Makefile.in @@ -12,4 +12,8 @@ IDL_R_SRCS = amstream_classes.idl RC_SRCS = version.rc +$(MODULE).so: $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ diff --git a/dlls/qcap/Makefile.in b/dlls/qcap/Makefile.in index 3abc295..5f4078d 100644 --- a/dlls/qcap/Makefile.in +++ b/dlls/qcap/Makefile.in @@ -11,4 +11,8 @@ C_SRCS = \ RC_SRCS = version.rc +$(MODULE).so: $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ diff --git a/dlls/quartz/Makefile.in b/dlls/quartz/Makefile.in index 24be02e..2cbcfe6 100644 --- a/dlls/quartz/Makefile.in +++ b/dlls/quartz/Makefile.in @@ -36,4 +36,9 @@ IDL_TLB_SRCS = control_tlb.idl EXTRA_OBJS = dlldata.o +$(MODULE).so: $(top_builddir)/dlls/dxguid/libdxguid.a \ + $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ diff --git a/dlls/winegstreamer/Makefile.in b/dlls/winegstreamer/Makefile.in index f6695be..cbf1986 100644 --- a/dlls/winegstreamer/Makefile.in +++ b/dlls/winegstreamer/Makefile.in @@ -12,4 +12,8 @@ C_SRCS = \ RC_SRCS = \ rsrc.rc +$(MODULE).so: $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ diff --git a/dlls/wineqtdecoder/Makefile.in b/dlls/wineqtdecoder/Makefile.in index 52ee03b..762f837 100644 --- a/dlls/wineqtdecoder/Makefile.in +++ b/dlls/wineqtdecoder/Makefile.in @@ -12,4 +12,8 @@ C_SRCS = \ RC_SRCS = \ rsrc.rc +$(MODULE).so: $(top_builddir)/dlls/strmbase/libstrmbase.a \ + $(top_builddir)/dlls/strmiids/libstrmiids.a \ + $(top_builddir)/dlls/uuid/libuuid.a + @MAKE_DLL_RULES@ -- Francois Gouget http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".
Re: The EFF is asking for our help explaining why APIs should not be copyrightable
On 11/09/2012 06:29 PM, Scott Ritchie wrote: https://www.eff.org/deeplinks/2012/11/no-copyrights-apis-help-us-make-case There are court cases pending that are very, very relevant to what we do here. It would help the EFF very much if a few engineers could send them a short email statement explaining how Wine's reimplementation of the API is good for interoperability and competition. Thanks, Scott Ritchie I thought the "Google vs Oracle Java API" case made it clear that API are not copyrightable but apparently, that's not the case. (See http://law.justia.com/cases/federal/district-courts/california/candce/3:2010cv03561/231846/1202) I can't comment further as I'm neither a lawer nor american. I only hope EFF will definitly close this debate.
The EFF is asking for our help explaining why APIs should not be copyrightable
https://www.eff.org/deeplinks/2012/11/no-copyrights-apis-help-us-make-case There are court cases pending that are very, very relevant to what we do here. It would help the EFF very much if a few engineers could send them a short email statement explaining how Wine's reimplementation of the API is good for interoperability and competition. Thanks, Scott Ritchie
[PATCH 1/2] winmm/tests: Add more mmioSeek tests. (try 2)
Hi again, More comments about your tests #2: +DeleteFileA(test_file); +[...] +has_test_file = create_test_file(test_file); Why do you recreate an identical file between test group 2 and 3? +has_test_file = create_test_file(test_file); +ok(has_test_file, "failed to create test file\n"); This is redundant and thus superfluous because your create_test_file ensures an ok() failure prior to every "return FALSE". (perhaps add one ok check to CloseHandle?) It's not always that easy to avoid correlated error messages, I mean to try and produce only one error message per cause. This will ease the job of people looking at failures on test.winehq.org. +char temp_path[MAX_PATH-14]; +ret = GetTempPath(sizeof(temp_path), temp_path); +ret = GetTempFileName(temp_path, "mmio", 0, temp_file); This is bogus. I believe you should use: +char temp_path[MAX_PATH]; +ret = GetTempPath(sizeof(temp_path), temp_path); +ret = GetTempFileName(temp_path, "mmio", 0, temp_file); and leave the -14 test to the implementation of GetTempFileName. Regards, Jörg Höhle
Re: [PATCH 1/2] gdi32: Ignore contours containing one point in get_glyph_outline function
Please ignore this patches for now, the tests are broken.
Re: [PATCH 2/2] gdi32: Added GetGlyphOutlineW tests on glyph that contains empty contour
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 http://testbot.winehq.org/JobDetails.pl?Key=22852 Your paranoid android. === WVISTAADM (32 bit font) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation
Re: [PATCH 1/2] user32: Add tests for MapWindowPoints, ClientToScreen and ScreenToClient.
Christian Costa writes: > 2012/11/9 Alexandre Julliard > Testing last error on success is not useful. Also please use > MAKELONG > and related macros instead of doing it by hand. > > I can't use LOWORD as the signed bit is not propagated with & 0x. You could always add a cast, but you don't really need it here. Printing fancy error messages is not useful anyway, they are not supposed to happen. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/2] user32: Add tests for MapWindowPoints, ClientToScreen and ScreenToClient.
2012/11/9 Alexandre Julliard > Christian Costa writes: > > > +SetLastError(0xdeadbeef); > > +n = MapWindowPoints(wnd, NULL, NULL, 0); > > +err = GetLastError(); > > +ok(n == ((window_rect.top << 16) | window_rect.left), "Got %x (%d, > %d), expected %x (%d, %d)\n", > > + n, (n << 16) >> 16, n >> 16, window_rect.left, window_rect.top, > (window_rect.top << 16) | window_rect.left); > > +ok(err == 0xdeadbeef, "Got %x, expected %x\n", err, 0xdeadbeef); > > + > > +SetLastError(0xdeadbeef); > > +n = MapWindowPoints(NULL, wnd, NULL, 0); > > +err = GetLastError(); > > +ok(n == ((-window_rect.top << 16) | (-window_rect.left & 0x)), > "Got %x (%d, %d), expected %x (%d, %d)\n", > > + n, (n << 16) >> 16, n >> 16, (-window_rect.top << 16) | > (-window_rect.left & 0x), -window_rect.left, -window_rect.top); > > +ok(err == 0xdeadbeef, "Got %x, expected %x\n", err, 0xdeadbeef); > > Testing last error on success is not useful. Also please use MAKELONG > and related macros instead of doing it by hand. > > > I can't use LOWORD as the signed bit is not propagated with & 0x.
Add data members to interface data structures?
Would a patch that allows data members to be hacked into interface data structures be acceptable? Specifically, this would add sequences that follow this template: #ifdef _IFACE_DATA _IFACE_DATA #endif /* _IFACE_DATA defined */ for each inherited interface, in order.
Re: [PATCH 1/2] user32: Add tests for MapWindowPoints, ClientToScreen and ScreenToClient.
Christian Costa writes: > +SetLastError(0xdeadbeef); > +n = MapWindowPoints(wnd, NULL, NULL, 0); > +err = GetLastError(); > +ok(n == ((window_rect.top << 16) | window_rect.left), "Got %x (%d, %d), > expected %x (%d, %d)\n", > + n, (n << 16) >> 16, n >> 16, window_rect.left, window_rect.top, > (window_rect.top << 16) | window_rect.left); > +ok(err == 0xdeadbeef, "Got %x, expected %x\n", err, 0xdeadbeef); > + > +SetLastError(0xdeadbeef); > +n = MapWindowPoints(NULL, wnd, NULL, 0); > +err = GetLastError(); > +ok(n == ((-window_rect.top << 16) | (-window_rect.left & 0x)), "Got > %x (%d, %d), expected %x (%d, %d)\n", > + n, (n << 16) >> 16, n >> 16, (-window_rect.top << 16) | > (-window_rect.left & 0x), -window_rect.left, -window_rect.top); > +ok(err == 0xdeadbeef, "Got %x, expected %x\n", err, 0xdeadbeef); Testing last error on success is not useful. Also please use MAKELONG and related macros instead of doing it by hand. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 1/3] dmloader: COM cleanup of IDirectMusicLoader object.
> > > > > > Henri said the other. It seems there is no consensus. ;) > Of course there is consensus. The consensus is: > - "It depends on the situation" > - "There are acceptable naming conventions" > - "IDirectMusicLoaderImpl_IDirectMusicLoader_QueryInterface is not one > of the acceptable solutions" > :) > > > Yea ! :) I think I will use IDirectMusicLoaderImpl_Method.
