Re: msvcrt: Implement _mbctombb.
Hi David,
David Hedberg wrote:
On Wed, Feb 24, 2010 at 7:12 AM, Maarten Lankhorst
wrote:
Hi David,
Hi Maarten,
David Hedberg wrote:
+/* Maps multibyte cp932 punctuation marks to single byte equivalents */
+static unsigned int mbctombb_932_punct[] = {
+
0x20,0xa4,0xa1,0x2c,0x2e,0xa5,0x3a,0x3b,0x3f,0x21,0xde,0xdf,0x00,0x00,0x00,0x5e,
+
0x7e,0x5f,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xb0,0x00,0x00,0x2f,0x00,
+
0x00,0x00,0x7c,0x00,0x00,0x60,0x27,0x00,0x22,0x28,0x29,0x00,0x00,0x5b,0x5d,0x7b,
+
0x7d,0x00,0x00,0x00,0x00,0xa2,0xa3,0x00,0x00,0x00,0x00,0x2b,0x2d,0x00,0x00,0x00,
+
0x00,0x3d,0x00,0x3c,0x3e,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x5c,
+ 0x24,0x00,0x00,0x25,0x23,0x26,0x2a,0x40};
+
+/* Maps multibyte cp932 hiragana/katakana to single-byte equivalents */
+static unsigned int mbctombb_932_kana[] = {
+
0xa7,0xb1,0xa8,0xb2,0xa9,0xb3,0xaa,0xb4,0xab,0xb5,0xb6,0xb6,0xb7,0xb7,0xb8,0xb8,
+
0xb9,0xb9,0xba,0xba,0xbb,0xbb,0xbc,0xbc,0xbd,0xbd,0xbe,0xbe,0xbf,0xbf,0xc0,0xc0,
+
0xc1,0xc1,0xaf,0xc2,0xc2,0xc3,0xc3,0xc4,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xca,
+
0xca,0xcb,0xcb,0xcb,0xcc,0xcc,0xcc,0xcd,0xcd,0xcd,0xce,0xce,0xce,0xcf,0xd0,0xd1,
+
0xd2,0xd3,0xac,0xd4,0xad,0xd5,0xae,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xdc,0xb2,
+ 0xb4,0xa6,0xdd,0xb3,0xb6,0xb9};
You're hardcoding this for a single code page? Are you sure you cannot use a
more generic function instead of hardcoding a table?
I haven't found anything that might handle it. The function in
question maps the characters in a somewhat "irregular fashion", and
only makes sense for code page 932. There's a static function
"han2zen" in dlls/mlang/mlang.c that appears to be the "inverse" (to
the extent this function is reversible), that one too is implemented
with a couple of tables.
Well, it seems msdn says the function used to be called zentohan, so if
the function only makes sense for cp 932 then adding the table is
harmless, I was afraid that more locales would need that function, in
which case a more generic solution would have been preferred.
Cheers,
Maarten.
PS: Use 'reply all' so wine-devel gets cc'd.
Re: msvcrt: Implement _mbctombb.
Hi David,
David Hedberg wrote:
+/* Maps multibyte cp932 punctuation marks to single byte equivalents */
+static unsigned int mbctombb_932_punct[] = {
+
0x20,0xa4,0xa1,0x2c,0x2e,0xa5,0x3a,0x3b,0x3f,0x21,0xde,0xdf,0x00,0x00,0x00,0x5e,
+
0x7e,0x5f,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xb0,0x00,0x00,0x2f,0x00,
+
0x00,0x00,0x7c,0x00,0x00,0x60,0x27,0x00,0x22,0x28,0x29,0x00,0x00,0x5b,0x5d,0x7b,
+
0x7d,0x00,0x00,0x00,0x00,0xa2,0xa3,0x00,0x00,0x00,0x00,0x2b,0x2d,0x00,0x00,0x00,
+
0x00,0x3d,0x00,0x3c,0x3e,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x5c,
+ 0x24,0x00,0x00,0x25,0x23,0x26,0x2a,0x40};
+
+/* Maps multibyte cp932 hiragana/katakana to single-byte equivalents */
+static unsigned int mbctombb_932_kana[] = {
+
0xa7,0xb1,0xa8,0xb2,0xa9,0xb3,0xaa,0xb4,0xab,0xb5,0xb6,0xb6,0xb7,0xb7,0xb8,0xb8,
+
0xb9,0xb9,0xba,0xba,0xbb,0xbb,0xbc,0xbc,0xbd,0xbd,0xbe,0xbe,0xbf,0xbf,0xc0,0xc0,
+
0xc1,0xc1,0xaf,0xc2,0xc2,0xc3,0xc3,0xc4,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xca,
+
0xca,0xcb,0xcb,0xcb,0xcc,0xcc,0xcc,0xcd,0xcd,0xcd,0xce,0xce,0xce,0xcf,0xd0,0xd1,
+
0xd2,0xd3,0xac,0xd4,0xad,0xd5,0xae,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xdc,0xb2,
+ 0xb4,0xa6,0xdd,0xb3,0xb6,0xb9};
You're hardcoding this for a single code page? Are you sure you cannot
use a more generic function instead of hardcoding a table?
Cheers,
Maarten.
Re: "make distclean" failing?
On Tue, Feb 23, 2010 at 10:54 PM, Dan Kegel wrote: > James McKenzie wrote: >> Dan Kegel wrote: >>> "make distclean" failed for me today... >> >> I usually use just plain make clean. Is this before/after today's commits? > > After. > > And I saw a similar error today in the valgrind continuous build, > which only does clean and testclean. Works fine here...ubuntu karmic x86_64/gcc 4.4.1/GNU make 3.8.1 -- -Austin
Re: "make distclean" failing?
James McKenzie wrote: > Dan Kegel wrote: >> "make distclean" failed for me today... > > I usually use just plain make clean. Is this before/after today's commits? After. And I saw a similar error today in the valgrind continuous build, which only does clean and testclean.
Re: [PATCH 1/2] gdiplus/test: Add GdipGetNearestColor test [try 2]
You should probably use a Bitmap object rather than the display for
this, since the pixel format is important. That should make it
possible to test other depths, even though they can't yet be
implemented properly in Wine.
Also, you should mark tests that fail in wine with todo_wine and
remove the todo_wine in any subsequent patches that fix them.
On Tue, Feb 23, 2010 at 8:56 PM, Justin Chevrier wrote:
> ---
> dlls/gdiplus/tests/graphics.c | 45
> +
> 1 files changed, 45 insertions(+), 0 deletions(-)
>
> diff --git a/dlls/gdiplus/tests/graphics.c b/dlls/gdiplus/tests/graphics.c
> index 45bd9f7..97c520d 100644
> --- a/dlls/gdiplus/tests/graphics.c
> +++ b/dlls/gdiplus/tests/graphics.c
> @@ -21,6 +21,7 @@
> #include "windows.h"
> #include "gdiplus.h"
> #include "wingdi.h"
> +#include "winuser.h"
> #include "wine/test.h"
> #include
>
> @@ -2270,6 +2271,49 @@ static void test_GdipIsVisibleRect(void)
> ReleaseDC(0, hdc);
> }
>
> +static void test_GdipGetNearestColor(void)
> +{
> + GpStatus status;
> + GpGraphics *graphics = NULL;
> + ARGB color = 0xdeadbeef;
> + HDC hdc = GetDC(0);
> + DEVMODEA dmA;
> + BOOL ret;
> +
> + /* create a graphics object */
> + ok(hdc != NULL, "Expected HDC to be initialized\n");
> +
> + status = GdipCreateFromHDC(hdc, &graphics);
> + expect(Ok, status);
> + ok(graphics != NULL, "Expected graphics to be initialized\n");
> +
> + status = GdipGetNearestColor(graphics, NULL);
> + expect(InvalidParameter, status);
> +
> + status = GdipGetNearestColor(NULL, &color);
> + expect(InvalidParameter, status);
> +
> + ret = EnumDisplaySettingsA(NULL, ENUM_CURRENT_SETTINGS, &dmA);
> + if (!ret)
> + {
> + skip("Could not determine color depth\n");
> + goto end;
> + }
> +
> + if (dmA.dmBitsPerPel >= 24)
> + {
> + status = GdipGetNearestColor(graphics, &color);
> + expect(Ok, status);
> + ok(color == 0xdeadbeef, "expected 0xdeadbeef, got: 0x%08x\n", color);
> + }
> + else
> + skip("Color depth less than 24bpp.\n");
> +
> + end:
> + GdipDeleteGraphics(graphics);
> + ReleaseDC(0, hdc);
> +}
> +
> START_TEST(graphics)
> {
> struct GdiplusStartupInput gdiplusStartupInput;
> @@ -2296,6 +2340,7 @@ START_TEST(graphics)
> test_GdipDrawLineI();
> test_GdipDrawLinesI();
> test_GdipDrawString();
> + test_GdipGetNearestColor();
> test_GdipGetVisibleClipBounds();
> test_GdipIsVisiblePoint();
> test_GdipIsVisibleRect();
> --
> 1.6.5.rc1
>
>
>
>
"make distclean" failing?
"make distclean" failed for me today... after cleaning lots of stuff, it started trying to *build* something: ... make[1]: Leaving directory `/home/dank/wine-git/tools' config.status: creating tools/widl/Makefile make[1]: Entering directory `/home/dank/wine-git/tools/widl' ../../tools/makedep -C. -S../.. -T../.. client.c expr.c hash.c header.c proxy.c server.c typegen.c typelib.c typetree.c utils.c widl.c write_msft.c parser.y parser.l make[1]: ../../tools/makedep: Command not found make[1]: *** [depend] Error 127 make[1]: Leaving directory `/home/dank/wine-git/tools/widl' make: *** [tools/widl/Makefile] Error 2 Alexandre changed the build system today a bit, I wonder if that did it.
Re: dns-sd dll implementation -- Needs work
On Tue, Feb 23, 2010 at 18:57, Steven Edwards wrote: > Do you really want to run the Windows version of VLC on OS X? I > believe there is a better case to be made with Safari/Quicktime/iTunes > as I believe they also install Bonjour services on Windows. If you > wanted to validate/compare how the native service works verses say a > wrapper then it would be of use. Pidgin might be another example... What I really meant is that it should at least be evaluated... (I didn't realize at the time that Bonjour for Windows has a seperate installer available...) It might have a valid use if conflicts exist between Windows Bonjour under Wine and native bonjour / other Zeroconf implementations... (such as listening on the same port) (If such a confilct exists, it should be possible to run either a ZeroConf implementation natively or to run it under Wine, but not both. This can be problematic, since two of Wine's largest platforms, Ubuntu and OS X installs ZeroConf implementations by default) (I'm not familiar enough with Bonjour / ZeroConf to really understand which parts of it is wrapped by this DLL) (It seems that DNS Service Discovery is able to function without mDNS) Just a note: According to Wikipedia, Photoshop CS3 is among the applications using Bonjour under Windows: http://blogs.adobe.com/jnack/2007/01/cs3_doesnt_inst.html Gert
Re: [PATCH 9/9] oleaut32/tests: Added more typelib creation tests
Hi, On 02/23/10 19:38, Paul Vriens wrote: This one crashes on NT4 with just SP6a and W2K with just SP4 (tested Win98 just now and it crashes as well). Should we just "if (0)" this one? I'll remove this test. I was testing the function with incorrect parameter, probably it's not validated on some (all?) systems. Thanks, Piotr
Re: [PATCH 9/9] oleaut32/tests: Added more typelib creation tests
On 02/22/2010 11:16 PM, Piotr Caban wrote: + +hres = ITypeInfo_GetRefTypeInfo(interface1, 16,&ti); +ok(hres == E_FAIL, "got %08x\n", hres); + Hi Piotr, This one crashes on NT4 with just SP6a and W2K with just SP4 (tested Win98 just now and it crashes as well). Should we just "if (0)" this one? (Winetestbot would have shown btw). -- Cheers, Paul.
Re: [PATCH] include: Don't accidentally redefine a member in struct _IRP (LLVM/Clang).
Disregard this patch, it breaks ntoskrnl. New patch forthcoming. Chip
Re: dns-sd dll implementation -- Needs work
On Tue, Feb 23, 2010 at 7:08 AM, Gert van den Berg wrote: > On OS X, it would also eliminate the need to install the Windows > version of Apple applications bundled with OS X in order to run things > that uses a single library provided by them. (e.g. Bonjour support in > VLC) Do you really want to run the Windows version of VLC on OS X? I believe there is a better case to be made with Safari/Quicktime/iTunes as I believe they also install Bonjour services on Windows. If you wanted to validate/compare how the native service works verses say a wrapper then it would be of use. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: Summer of code idea: make tiny game demos to expose problems in Wine
2010/2/23 Alexander Nicolaysen Sørnes : > Maybe someone can work on implementing dxdiag.exe in Wine? We could add some > extra tests compared to the Windows versions, and the small games could be a > part of that. Yeah, I've updated my proposal to mention that possibility, and to refer to http://wiki.winehq.org/SummerOfCode#head-bbaefe0a459986254d1cad93ccc51ef915f19dbd which talks about reviving the improved dxdiag. (Although I've been told since that AJ frowns on people reviving other people's dead code?) - Dan
Re: Summer of code idea: make tiny game demos to expose problems in Wine
On Tue, Feb 23, 2010 at 5:29 AM, Francois Gouget wrote: >> http://wiki.winehq.org/SummerOfCode#head-5cdc861e4369f94f0af19d09710d33d76b1f5c64 >> Current text: >> ... >> Let's try making the smallest possible demo games that show problems >> in Wine, and file bugs for what we find (along with the source for the >> games/demos)." > > This does not seem related to Wine to me, except in a very round-about > way. IMHO a better way would be to improve the conformance tests as > running them is already automated and they are even clearer about what > is being tested. OK, next draft: http://wiki.winehq.org/SummerOfCode#head-8d0895f237c9c3579ffe4282412bbbf2c8cd019b Current text: "Direct3D - Conformance / Performance / Interactive tests Possible Mentors: DanKegel Even small demos show interesting problems in Wine (see e.g. http://bugs.winehq.org/buglist.cgi?quicksearch=3drad, http://bugs.winehq.org/show_bug.cgi?id=21817 ) There are lots of tools (see http://wiki.winehq.org/GameEngines ) that make developing tiny games easy; they often come with tutorials or examples that might let you isolate problems We would like to capture the problems these expose by writing conformace tests (possibly WINETEST_INTERACTIVE ones, if they can't be automated) or performance test tools (as part of programs/dxtest, perhaps), or at the very least bug reports It'd be nice to also fix some of the problems, too." Is that closer?
Re: Summer of code idea: make tiny game demos to expose problems in Wine
Alexander Nicolaysen Sørnes wrote: Maybe someone can work on implementing dxdiag.exe in Wine? We could add some extra tests compared to the Windows versions, and the small games could be a part of that. I'd say Wine's dxdiag should mainly run the existing DirectX tests and report any failure to the user. This may also help with making the current (graphics) driver bugs Wine is hitting with more prominent.
Re: Summer of code idea: make tiny game demos to expose problems in Wine
Tirsdag 23 februar 2010 14:51:09 skrev Roderick Colenbrander : > On Tue, Feb 23, 2010 at 2:29 PM, Francois Gouget wrote: > > On Sun, 21 Feb 2010, Dan Kegel wrote: > >> I've just added > >> http://wiki.winehq.org/SummerOfCode#head-5cdc861e4369f94f0af19d09710d33d > >>76b1f5c64 Current text: > >> "Big games are hard to debug. > >> Small demo games show interesting problems in Wine (see e.g. > >> http://bugs.winehq.org/buglist.cgi?quicksearch=3drad ) > >> There are lots of tools (see http://wiki.winehq.org/GameEngines ) that > >> make developing tiny games easy > >> Let's try making the smallest possible demo games that show problems > >> in Wine, and file bugs for what we find (along with the source for the > >> games/demos)." > > > > This does not seem related to Wine to me, except in a very round-about > > way. IMHO a better way would be to improve the conformance tests as > > running them is already automated and they are even clearer about what > > is being tested. > > I'm also not convinced about this project. Something better (although > I'm not sure if that would really belong in Wine either) is some sort > of performance measuring framework. In case of 3d stuff, Nvidia (and > others as well) has a tool called nvperfhud. It can provide detailed > information on how busy certain stages of the gpu are. Perhaps it is > useful to integrate something like that into Wine. Or perhaps create > something more generic e.g. some 'wrapper' around windows dlls which > we can use to profile Windows apps and Wine apps, so that we can > compare performance. > > Roderick > Maybe someone can work on implementing dxdiag.exe in Wine? We could add some extra tests compared to the Windows versions, and the small games could be a part of that. Alexander N. Sørnes
Re: Summer of code idea: make tiny game demos to expose problems in Wine
On Tue, Feb 23, 2010 at 2:29 PM, Francois Gouget wrote: > On Sun, 21 Feb 2010, Dan Kegel wrote: > >> I've just added >> http://wiki.winehq.org/SummerOfCode#head-5cdc861e4369f94f0af19d09710d33d76b1f5c64 >> Current text: >> "Big games are hard to debug. >> Small demo games show interesting problems in Wine (see e.g. >> http://bugs.winehq.org/buglist.cgi?quicksearch=3drad ) >> There are lots of tools (see http://wiki.winehq.org/GameEngines ) that >> make developing tiny games easy >> Let's try making the smallest possible demo games that show problems >> in Wine, and file bugs for what we find (along with the source for the >> games/demos)." > > This does not seem related to Wine to me, except in a very round-about > way. IMHO a better way would be to improve the conformance tests as > running them is already automated and they are even clearer about what > is being tested. I'm also not convinced about this project. Something better (although I'm not sure if that would really belong in Wine either) is some sort of performance measuring framework. In case of 3d stuff, Nvidia (and others as well) has a tool called nvperfhud. It can provide detailed information on how busy certain stages of the gpu are. Perhaps it is useful to integrate something like that into Wine. Or perhaps create something more generic e.g. some 'wrapper' around windows dlls which we can use to profile Windows apps and Wine apps, so that we can compare performance. Roderick
Re: [2/5] WineD3D: Add an internal event query finish function
On 16 February 2010 14:59, Stefan Dösinger wrote:
>
Patch 1:
> if (!pData || !dwSize) return S_OK;
...
> +if (data)
This should be unnecessary, since you already checked "pData" above.
Otherwise the patch looks reasonable.
Patch 4:
> +GLenum gl_ret = GL_EXTCALL(glClientWaitSync(query->object.sync,
> GL_SYNC_FLUSH_COMMANDS_BIT, ~0U));
...
> +/* We don't expect a timeout for a ~584 year wait */
Actually, ~0U would be slightly more than 4 seconds.
Patch 7:
> +for(i = 0; i < This->num_buffer_queries; i++)
> +{
> +wined3d_event_query_issue(This->buffer_queries[i], This);
> +}
You should do this before the flush, otherwise the query might never
finish if it's in a different context.
> Concerning GL_SYNC_FLUSH_COMMANDS:
>> You certainly need to flush, but that's not the point. Using
>> GL_SYNC_FLUSH_COMMANDS is either unnecessary if you already flush
>> after glFenceSync(), or doesn't solve the problem for fences in
>> different contexts if you don't. Note that the existing code doesn't
>> have to flush after glFenceSync() because we use a 0 timeout in
>> GetData().
> The existing code has to honor D3DGETDATA_FLUSH if the app passes it. The 0
> timeout doesn't help us if the app does something like this
>
> BOOL data;
> do
> {
> IWineD3DQuery_GetData(event_query, D3DGETDATA_FLUSH, &data);
> } while(!data);
>
> in a single threaded environment.
>
Sure, but if you want queries to work reliably across contexts you
need to flush after issuing them.
Re: Summer of code idea: make tiny game demos to expose problems in Wine
On Sun, 21 Feb 2010, Dan Kegel wrote: > I've just added > http://wiki.winehq.org/SummerOfCode#head-5cdc861e4369f94f0af19d09710d33d76b1f5c64 > Current text: > "Big games are hard to debug. > Small demo games show interesting problems in Wine (see e.g. > http://bugs.winehq.org/buglist.cgi?quicksearch=3drad ) > There are lots of tools (see http://wiki.winehq.org/GameEngines ) that > make developing tiny games easy > Let's try making the smallest possible demo games that show problems > in Wine, and file bugs for what we find (along with the source for the > games/demos)." This does not seem related to Wine to me, except in a very round-about way. IMHO a better way would be to improve the conformance tests as running them is already automated and they are even clearer about what is being tested. -- Francois Gouget http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U
Re: include[1/2]: add a strcmpW-equivalent function usable in tests.
On 02/23/2010 01:26 PM, Alexandre Julliard wrote: Paul Vriens writes: hi Alexandre, Is the idea to now use this function instead of all those different ones currently present in the tests? Sure. I'll keep that in mind when touching those files. -- Cheers, Paul.
Re: include[1/2]: add a strcmpW-equivalent function usable in tests.
Paul Vriens writes: > hi Alexandre, > > Is the idea to now use this function instead of all those different > ones currently present in the tests? Sure. -- Alexandre Julliard julli...@winehq.org
Re: dns-sd dll implementation -- Needs work
On Tue, Feb 23, 2010 at 09:37, Dmitry Timoshkov wrote: > "C.W. Betts" wrote: > >> What do you guys think? it's a wrapper for multicast DNS, aka Bonjour®. > > Looks like this is not a part of Windows or PSDK Neither is OpenAL It might provide functionality as part of Wine that might be hard to implement on top of Wine? On OS X, it would also eliminate the need to install the Windows version of Apple applications bundled with OS X in order to run things that uses a single library provided by them. (e.g. Bonjour support in VLC) Gert
Re: include[1/2]: add a strcmpW-equivalent function usable in tests.
On 02/20/2010 10:52 PM, Mikołaj Zalewski wrote: As I've learned, lstrcmpW doesn't work under Windows 9x, thus it is not a good choice to test functionality that existed in these version of Windows. On the other hand, strcmpW is not available on standalone builds on Windows. However, this function is so simple, that we can duplicate the implementation. Hi Alexandre, Is the idea to use this function instead of all those different ones currently present in the tests (and where needed replace lstrcmpW)? -- Cheers, Paul.
Re: include[1/2]: add a strcmpW-equivalent function usable in tests.
On 02/20/2010 10:52 PM, Mikołaj Zalewski wrote: As I've learned, lstrcmpW doesn't work under Windows 9x, thus it is not a good choice to test functionality that existed in these version of Windows. On the other hand, strcmpW is not available on standalone builds on Windows. However, this function is so simple, that we can duplicate the implementation. hi Alexandre, Is the idea to now use this function instead of all those different ones currently present in the tests? -- Cheers, Paul.
Re: [PATCH] ole32: ignore HighPart in the Seek method HGLOBAL streams.
Reece Dunn writes: > @@ -395,9 +395,11 @@ static HRESULT WINAPI HGLOBALStreamImpl_Seek( > * If the file pointer ends-up after the end of the stream, the next Write > operation will > * make the file larger. This is how it is documented. > */ > - if (dlibMove.QuadPart < 0 && newPosition.QuadPart < -dlibMove.QuadPart) > return STG_E_INVALIDFUNCTION; > + if (dlibMove.u.LowPart < 0 && newPosition.u.LowPart < -dlibMove.u.LowPart) > +return STG_E_INVALIDFUNCTION; This doesn't make sense, LowPart is unsigned. -- Alexandre Julliard julli...@winehq.org
Re: ptrace regression in Linux 2.6.33-rcX breaking Wine
Hello! On 02/11/2010 05:54 PM, Michael Stefaniuc wrote: in case you have a Wine app that stopped working on Linux and you use 2.6.33-rcX kernels please give 2.6.32 a whirl. I finally sat down to track why the ntdll exception tests started to fail on my machines but not on other Fedora boxes. Turns out to be a regression in the Linux kernel: http://bugzilla.kernel.org/show_bug.cgi?id=15273 The two regressions (it was a double regression) are now fixed and upstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=84d710926797a6e317e7e94654a3ccd771cfd8a3 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=326264a02448b0ac51f78f178b78e830aa077a0b Thanks to Frederic Weisbecker for fixing the problems and following through to get those patches accepted upstream before the final 2.6.33 is cut. bye michael
Re: PeekMsg/MsgWaitForMultipleObjects question
writes: > hopefully somebody familiar with messaging can immediately spot what's wrong > with the code below. > > The winmm/midi tests currently in git, using PeekMsg, show that the messages > (from CALLBACK_WINDOW) are almost always immediately available. > > Yet the code below, based on MsgWaitFor... times out multiple times > during each test run. Why? Message waiting functions only return for new input. You need to make sure the queue is empty before waiting. -- Alexandre Julliard julli...@winehq.org
PeekMsg/MsgWaitForMultipleObjects question
Hi,
hopefully somebody familiar with messaging can immediately spot what's wrong
with the code below.
The winmm/midi tests currently in git, using PeekMsg, show that the messages
(from CALLBACK_WINDOW) are almost always immediately available.
Yet the code below, based on MsgWaitFor... times out multiple times
during each test run. Why?
This seems to affect only the messages 3c9/3ca (MOM_DONE and MOM_CALLBACK).
"Bad wait 102 0": 0x102 is WAIT_TIMEOUT. That should never happen.
diff --git a/dlls/winmm/tests/midi.c b/dlls/winmm/tests/midi.c
index 15e02e2..a23fa19 100644
--- a/dlls/winmm/tests/midi.c
+++ b/dlls/winmm/tests/midi.c
@@ -67,8 +67,27 @@ static void test_notification(HWND hwnd, const char*
command, UINT m1, DWORD_PTR
if (hwnd) {
/* msg.wParam is hmidiout, msg.lParam is the mhdr (or 0) */
BOOL seen;
+#if 0
do { seen = PeekMessageA(&msg, hwnd, 0, 0, PM_REMOVE); }
while(seen && spurious_message(&msg));
+#else
+ seen=0;
+if (m1 && !seen) {
+ /* We observe intermittent delayed notification. Perhaps
+ * the OS preempts the player thread after setting MHDR_DONE
+ * or clearing INQUEUE, before calling DriverCallback. */
+ DWORD x;
+ trace("Waiting for delayed message %x from %s\n", m1, command);
+ SetLastError(0xDEADBEEF);
+#if 0
+ x=MsgWaitForMultipleObjects(0, NULL, FALSE, , QS_POSTMESSAGE);
+#else
+ x=MsgWaitForMultipleObjects(0, NULL, FALSE, /*INFINITE*/,
QS_ALLINPUT);
+#endif
+ ok(x==WAIT_OBJECT_0,"Bad wait %x %d\n",x, GetLastError());
+ seen = PeekMessageA(&msg, hwnd, 0, 0, PM_REMOVE);
+}
+#endif
if (seen) {
trace("Message %x, wParam=%lx, lParam=%lx from %s\n",
msg.message, msg.wParam, msg.lParam, command);
Thanks for your help,
Jörg Höhle
Re: Another aspiring GSoC applicant..
David Hedberg pisze: > I've also looked a bit at implementing support for IFileDialog, and > the Explorer, but I have yet to dig too deep into either of them. Are > there currently any known applications out there that uses IFileDialog > explicitly? I've looked a bit, probably not enough, but I haven't been > able to find anything except example code. Also, are there any > applications that fail to run because explorer is missing > functionality, or would the end-result of that suggested project > function mainly as an end-user utility? > In older version of Gnome, Gnome was not using the freedesktop.org standard trash directory, what caused files deleted under Wine not to show up in Gnome Trash. As we have in Wine a Trash virtual folder, I was thinking about fixing it by implementing a IShellBrowser (single explorer window) to show it to the users. However, as this is fixed in newer Gnomes, this is probably not that useful anymore. Still, if anyone is interested, I attach the skeleton code I have written (written under Windows XP x64, to be ported to Wine once finished possibly fixing some bugs) that does some logging and may be useful as a starting point. Apart from the 'shellbrowser' folder, I also put the 'shellfolder' one that I've used when implementing the recycle bin folder that may be useful if one needs logs from "the other side" (i.e. from a custom folder inside the true Explorer). Mikołaj > Thanks, > David > > > shell.tar.bz2 Description: application/bzip
