Re: user32: Use the PostMessage() for WM_IME_KEY{DOWN|UP} message
ByeongSik Jeon [EMAIL PROTECTED] wrote: * MS Spi++ test result, PostMessage is right. * Message generation sequence: WM_IME_KEYDOWN - WM_KEYDOWN - WM_CHAR WM_CHAR is genetated in the TranslateMessage() when we use PostMessage() function. * Real case: MS IME 2002, MS IME 2003, Saenaru In the preedit mode, when we press the ENTER key, Korean Native IME generate the WM_IME_KEYDOWN(wParam==VK_RETURN) message. This message is translated to the WM_CHAR(wParam==VK_RETURN) message finally. You should add the tests to dlls/user32/tests/msg.c for the above changes. -- Dmitry.
Wine64?
Hi all, I'm interested in the current state of work towards Wine64, ie running Win64 binaries on x86_64 Linux machines. My needs are actually really simple and hence may be a good base functionality to work towards. I just need to run Win64 binaries that read stdin, write stdout/stderr and do file I/O using the standard windows CreateFile/ReadFile/WriteFile/CloseHandle/ SetFilePointer etc functions. I have found and read this: http://wiki.winehq.org/Wine64 but some of that stuff seems rather out-of-date. When I configure with --enable-win64 it configures fine but then errors out in widl generated code because of things like this: #if !defined(__RPC_WIN32__) #error Currently only Wine and WIN32 are supported. #endif So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list? Any way for me to get involved? Cheers, Erik -- - Erik de Castro Lopo - If you have one apple and I have one apple, if we exchange, each will have one apple. If you have one idea and i have one idea, if we exchange them, each will have two ideas! -- Attributed to George Bernard Shaw
Question about openning html document in new window
Hello, I have a question.
I make a patch, that fix problem with open html document in new window. I
tested it on MyIE 2 and it works. But I am not assured, whether it is
possible to solve a problem in this way.
What do you think about it?
--
Sinitsin Ivan
Index: dlls/shdocvw/navigate.c
===
RCS file: /home/wine/wine/dlls/shdocvw/navigate.c,v
retrieving revision 1.51
diff -u -p -u -r1.51 navigate.c
--- dlls/shdocvw/navigate.c 15 Mar 2008 10:55:26 - 1.51
+++ dlls/shdocvw/navigate.c 21 Apr 2008 06:45:56 -
@@ -844,8 +844,9 @@ static HRESULT WINAPI HlinkFrame_Navigat
/* Windows calls GetHlinkSite here */
if(grfHLNF HLNF_OPENINNEWWINDOW) {
-FIXME(Not supported HLNF_OPENINNEWWINDOW\n);
-return E_NOTIMPL;
+static const WCHAR wszBlank[] = {'_','b','l','a','n','k',0};
+IHlink_SetTargetFrameName(pihlNavigate, wszBlank);
+return IHlink_Navigate(pihlNavigate, grfHLNF, pbc, pibsc, phbc);
}
return navigate_hlink(This-doc_host, mon, pbc, pibsc);
Re: [PATCH 09/17] widl: Split the expr rule up into multiple rules to fix operator precedence.
Robert Shearman [EMAIL PROTECTED] writes: @@ -263,8 +263,14 @@ static void add_explicit_handle_if_necessary(func_t *func); %type attr attribute %type attr_list m_attributes attributes attrib_list %type str_list str_list -%type expr m_expr expr expr_const -%type expr_list m_exprs /* exprs expr_list */ expr_list_const +%type expr m_expr expr_const expression conditional_expression +%type expr conditional_expression logical_OR_expression logical_AND_expression +%type expr inclusive_OR_expression exclusive_OR_expression AND_expression +%type expr equality_expression relational_expression shift_expression +%type expr additive_expression additive_expression multiplicative_expression +%type expr cast_expression unary_expression postfix_expression +%type expr primary_expression +%type expr_list m_exprs expr_list_const %type array_dims array array_list %type ifinfo interfacehdr %type type inherit interface interfacedef interfacedec You shouldn't need that, the %left/%right declarations should define the correct precedence already. Why doesn't this work for you? -- Alexandre Julliard [EMAIL PROTECTED]
Re: winmm/tests: waveOutGetDevCaps called with invalid size
On Fri, 18 Apr 2008, Robert Reif wrote: -rc=waveOutGetDevCapsA(device,capsA,4); +/* Final call must succeed, capsA will be used below */ +rc=waveOutGetDevCapsA(device,capsA,sizeof(capsA)); ok(rc==MMSYSERR_NOERROR, waveOutGetDevCapsA(%s): MMSYSERR_NOERROR expected, got %s\n, dev_name(device),wave_out_error(rc)); - -rc=waveOutGetDevCapsW(device,capsW,4); -ok(rc==MMSYSERR_NOERROR || rc==MMSYSERR_NOTSUPPORTED, - waveOutGetDevCapsW(%s): MMSYSERR_NOERROR or MMSYSERR_NOTSUPPORTED - expected, got %s\n,dev_name(device),wave_out_error(rc)); +if (rc!=MMSYSERR_NOERROR) + return; That's the whole point of the test, to check what happens with an invalid argument. So what do you think *should* happen with an invalid argument? The result is different on different Windows platforms. The behaviour is not specified by MSDN. In any case, continuing and executing code that uses capsA even though the waveOutGetDevCapsA call failed is definitely wrong. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00
Re: MSIME support causing slow setup until explorer.exe paused?
Humm,
MSIMEService, MSIMEReconvertOptions, MSIMEMouseOperator, etc... those
are all Messages that Microsoft Office looks for and sends to the IME
during operations. For the most part all those messages are just stubbed.
The messages are Registered in Imm32/imm.c once per process, and also
registered in winex11.drv/ime.c also once per process. I am pretty sure
we do not send those messages somewhere. So I am not sure why they would
be taking up so much cpu time.
Do you know what is happening with the messages during the slow-down?
thanks,
-aric
Dan Kegel wrote:
I tried installing StarUML (after doing winetricks vcrun6 msxml3, as
required),
and the setup crept along very slowly... so I got curious and ran top.
Most of the cpu time was being used by Explorer and wineserver,
and interestingly, if I suspended Explorer by doing
strace -p pid of explorer
and then pressing ^S, the install ran awful darn fast.
So, what was explorer doing that was slowing things down so much?
writev(3, [{l\0\0\0\30\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
64}, {M\0S\0I\0M\0E\0S\0e\0r\0v\0i\0c\0e\0, 24}], 2) = 88
...
writev(3, [{l\0\0\0*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
64}, {M\0S\0I\0M\0E\0R\0e\0c\0o\0n\0v\0e\0r\0t\0O\0p\0..., 42}], 2)
= 106
...
writev(3, [{l\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
64}, {M\0S\0I\0M\0E\0M\0o\0u\0s\0e\0O\0p\0e\0r\0a\0t\0..., 38}], 2)
= 102
...
writev(3, [{l\0\0\0*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
64}, {M\0S\0I\0M\0E\0R\0e\0c\0o\0n\0v\0e\0r\0t\0R\0e\0..., 42}], 2)
= 106
...
This persisted in the app, too, not just in the installer.
So it kind of sounds like our msime support is hurting us performance-wise?
- Dan
Re: [PATCH 09/17] widl: Split the expr rule up into multiple rules to fix operator precedence.
Alexandre Julliard wrote:
You shouldn't need that, the %left/%right declarations should define the
correct precedence already. Why doesn't this work for you?
I was attempting to fix the attached case. The result of the expression
evaluation can be seen in the generated _c.c file by searching for /*
Corr desc: constant, val=.
I see that the issue is that the %left and %right declarations aren't in
the correct order (and some aren't grouped properly either).
So this bug can indeed be fixed without splitting up expr into multiple
rules.
--
Rob Shearman
[
uuid(7a98c250-6808-11cf-b73b-00aa00b677a7),
version(1.0)
]
interface Tests
{
struct s
{
[size_is(2 2 * 3)] char *array;
};
void Test([in] struct s *s);
}
Re: imm32: Fix a test that fails on all systems
On Mon, Apr 21, 2008 at 7:17 AM, Aric Stewart [EMAIL PROTECTED] wrote: Are this tests failing on windows? When I did my recent IME work I was working to make sure that these tests succeeded at that time. have they started failing on wine as well? Yes, they fail on all versions: http://test.winehq.org/data/200804191000/ Well, they 'pass' on wine, but that doesn't match the behavior of native windows. -- James Hawkins
Re: imm32: Fix a test that fails on all systems
Are this tests failing on windows? When I did my recent IME work I was working to make sure that these tests succeeded at that time. have they started failing on wine as well? thanks, -aric James Hawkins wrote: Hi, Changelog: * Fix a test that fails on all systems. dlls/imm32/tests/imm32.c | 30 +- 1 files changed, 21 insertions(+), 9 deletions(-)
Re: msxml3: Correct transformNode from failing on windows
Alistair Leslie-Hughes [EMAIL PROTECTED] writes: diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c index 6f790fe..b06e57e 100644 --- a/dlls/msxml3/tests/domdoc.c +++ b/dlls/msxml3/tests/domdoc.c @@ -143,7 +143,11 @@ static const CHAR szTransformSSXML[] = /xsl:stylesheet; static const CHAR szTransformOutput[] = -?xml version=\1.0\ encoding=\UTF-8\ standalone=\yes\?\n +html\r\nbody\r\nh1\r\n +Hello World\r\n +/h1\r\n/body\r\n/html\r\n; + +static const CHAR szTransformOutputWine[] = htmlbodyh1\n Hello World\n /h1/body/html\n; @@ -3193,7 +3197,8 @@ static void test_testTransforms(void) hr = IXMLDOMDocument_transformNode(doc, pNode, bOut); ok(hr == S_OK, ret %08x\n, hr ); -ok( !lstrcmpW( bOut, _bstr_(szTransformOutput) ), Stylesheet output not correct\n); +ok( !lstrcmpW( bOut, _bstr_(szTransformOutput)) || /* Windows */ +!lstrcmpW( bOut, _bstr_(szTransformOutputWine)) /* Wine */, Stylesheet output not correct\n); You shouldn't need a special case for Wine. What you need is a smarter comparison function that ignores EOL characters. -- Alexandre Julliard [EMAIL PROTECTED]
Re: gdi32: Make the bitmap test pass under Windows 2000
Dmitry Timoshkov [EMAIL PROTECTED] writes:
@@ -967,15 +970,19 @@ static void test_bitmap(void)
hdc = CreateCompatibleDC(0);
assert(hdc != 0);
+if (0)
+{ /* this test fails under Win2k */
SetLastError(0xdeadbeef);
hbmp = CreateBitmap(0x7ff, 1, 1, 1, NULL);
ok(hbmp != 0, CreateBitmap should not fail\n);
DeleteObject(hbmp);
+}
It would be better to find values that work on all platforms, instead of
disabling the test completely.
--
Alexandre Julliard
[EMAIL PROTECTED]
Some XDC update
Hi, Here's a short summary of the wine-related things that were going on on XDC: - Mouse input: Daniel Stone will take care of that. He says DGA would give us what we want, but recommends not to use it. He is working on extending XInput(or making a new XI2) which can report relative mouse movements. The X people want to phase out DGA. Some games use it for relative input, so they'll make a DGA emulation layered on the new XInput stuff. He will need debugging / testing help from us since Wine will most likely be the only App making use of that directly. Also we should not hold our breath, he has some other items on his TODO list, but the end of 2008 is a plausible ETA. - Tablets: Config issue is known and being worked on - Graphics, general: The Mesa and ATI people are willing to help out with our issues. I talked to Aaron Plattner and Pierre ? from Nvidia, and they know the issues and worked on some extensions for that internally some time ago, but then decided that they're not going to implement that for some reason they didn't tell me(I hope they re-consider that now that someone is asking for it though). The ATI guys warned me that it might take a while until any new extensions are available in production drivers, but that's something we have to put up with I guess. Also both the ATI and Mesa people like the idea of using our conformance tests for their driver testing and debugging. The Nvidia guys offered help with the multithreading crashes and the 32 vs 40 varying issue. (I also talked to Ben Byer from Apple, but he's not in charge of the graphics drivers) - Graphics: Flat shading: Picking that as a first case for working on an extension. Should be fairly easy to implement in Mesa since all cards have a specific register for exactly that issue. - Graphics, multithreading: general agreement that what we are doing is correct, and driver bugs need fixing. It looks like the crash in fglrx will be fixed soon(my test app worked in Matthew's development driver). For the Nvidia issues I'll file a bugreport as soon as I know if the glxSwapBuffers crash is a driver or Gentoo bug) - Graphics, sRGB blending: Everyone believes me that our emulation is slow(pow() - uh oh, don't use that, that's not parallelizeable[Keith Packard]). The nvidia people are aware of the issue, but a fix is also unlikely. The ATI people aren't sure if their dx9 hardware supports sRGB writing, maybe the windows driver is emulating things as well - have to check - Graphics, GLSL issues: MOVA and LIT, possibly extensions for that. - Graphics, Hacks: Both the ATI and Nvidia developers warned me that their Windows drivers have a huge per-application bug workaround database. Aaron was pretty impressed that Wine doesn't have any app-specific hacks. I am afraid we will need them, as some apps seem to expect different behavior that our d3d9 tests get. I think the best way is to fetch some information about the Windows driver hacks and write tests which trigger them to show that hl2.exe gets different driver behavior than d3d9_test.exe(or in whatever way things work)
Re: gdi32: Make the bitmap test pass under Windows 2000
Paul Vriens [EMAIL PROTECTED] wrote:
+if (0)
+{ /* this test fails under Win2k */
SetLastError(0xdeadbeef);
hbmp = CreateBitmap(0x7ff, 1, 1, 1, NULL);
ok(hbmp != 0, CreateBitmap should not fail\n);
DeleteObject(hbmp);
+}
It would be better to find values that work on all platforms, instead of
disabling the test completely.
Yes, it would be better, but unfortunately I don't have windows 2000
installed around.
If you need me to test something on a Win2K box (Vmware) just shout.
We need to know what bitmap size is acceptable for CreateBitmap, so
basically experimenting with first 2 parameters in the above test
should answer that.
--
Dmitry.
Re: gdi32: Make the bitmap test pass under Windows 2000
Alexandre Julliard [EMAIL PROTECTED] wrote:
@@ -967,15 +970,19 @@ static void test_bitmap(void)
hdc = CreateCompatibleDC(0);
assert(hdc != 0);
+if (0)
+{ /* this test fails under Win2k */
SetLastError(0xdeadbeef);
hbmp = CreateBitmap(0x7ff, 1, 1, 1, NULL);
ok(hbmp != 0, CreateBitmap should not fail\n);
DeleteObject(hbmp);
+}
It would be better to find values that work on all platforms, instead of
disabling the test completely.
Yes, it would be better, but unfortunately I don't have windows 2000
installed around.
--
Dmitry.
Re: gdi32: Make the bitmap test pass under Windows 2000
Dmitry Timoshkov wrote:
Paul Vriens [EMAIL PROTECTED] wrote:
+if (0)
+{ /* this test fails under Win2k */
SetLastError(0xdeadbeef);
hbmp = CreateBitmap(0x7ff, 1, 1, 1, NULL);
ok(hbmp != 0, CreateBitmap should not fail\n);
DeleteObject(hbmp);
+}
It would be better to find values that work on all platforms,
instead of
disabling the test completely.
Yes, it would be better, but unfortunately I don't have windows 2000
installed around.
If you need me to test something on a Win2K box (Vmware) just shout.
We need to know what bitmap size is acceptable for CreateBitmap, so
basically experimenting with first 2 parameters in the above test
should answer that.
OK, no problem but I can't do that right now. Will have to wait a few hours.
Is there a specific combination you are looking for? Huge width, small height?
Or the maximum size possible?
--
Cheers,
Paul.
Re: gdi32: Make the bitmap test pass under Windows 2000
Dmitry Timoshkov wrote:
Alexandre Julliard [EMAIL PROTECTED] wrote:
@@ -967,15 +970,19 @@ static void test_bitmap(void)
hdc = CreateCompatibleDC(0);
assert(hdc != 0);
+if (0)
+{ /* this test fails under Win2k */
SetLastError(0xdeadbeef);
hbmp = CreateBitmap(0x7ff, 1, 1, 1, NULL);
ok(hbmp != 0, CreateBitmap should not fail\n);
DeleteObject(hbmp);
+}
It would be better to find values that work on all platforms, instead of
disabling the test completely.
Yes, it would be better, but unfortunately I don't have windows 2000
installed around.
If you need me to test something on a Win2K box (Vmware) just shout.
--
Cheers,
Paul.
Re: gdi32: Make the bitmap test pass under Windows 2000
Paul Vriens [EMAIL PROTECTED] wrote: Is there a specific combination you are looking for? Huge width, small height? Anything you could test that will lead to a reasonable conclusion. Or the maximum size possible? At least we need to know this one. -- Dmitry.
Re: Some XDC update
Am Montag, 21. April 2008 17:00:04 schrieb Stefan Dösinger: I talked to Aaron Plattner and Pierre ? I forgot to look up the name: Pierre-Loup Griffais was it, if I am not mistaken
Re: d3dx9: Texturing functions
On Sat, Apr 19, 2008 at 10:11:06AM +0200, [EMAIL PROTECTED] wrote: So, the first thing I want to make sure is that we redirect the function calls correctly in order to reduce double coding. This means on the one hand that we should call the Extended versions of each function from inside of the simpler ones (most default parameters for the Ex functions are on MSDN) and on the other hand that we unify all D3DXCreateTextureFromXXEx functions somehow. I don't know how Resources are stored internally, but I guess the simplest would be to redirect all of them to D3DXCreateTextureFromFileInMemory, i.e. when D3DXCreateTextureFromFile is called we read the file into memory and call the InMemory function. I hope this shouldn't be too hard to be applied to the resource function either. Of course, this should also be done at the corresponding Surface, Volume and cube texture functions. Also, I haven't looked too much into it yet, but I guess we could go even a step further and define the CreateTextuteFromXX calls like this: 1. Redirect to the corresponding D3DXCreateXFromFileInMemoryEx call 2. Call D3DXCheckXRequirements 3. Call IDirect3DDevice9::CreateTexture 4. Lock its surface 5. Call LoadSurfaceFromFileEx with it This would reduce most of our coding work on LoadSurfaceFromFileEx. However, there are still plenty of formats supported by the texturing functions and thus, plenty of work for us to do. IIRC we once came to the decision to use libraries like libpng or so to reduce that work, too, so we'd just need to implement formats like .dds. I can't remember what the differences are between the CreateTexture and LoadSurface functions, but this is what I'd do for the LoadSurface functions: LoadSurfaceFromMemory (read data with the specified pixel format) LoadSurfaceFromFileInMemory (parse image format, read actual data into memory) LoadSurfaceFromFile (open file, read contents into memory) LoadSurfaceFromResource (open resource, read contents into memory) LoadSurfaceFromSurface (read image data from a surface) This would mean two huge chunks of code: One which parses image formats (LoadSurfaceFromFileInMemory), and one which handles all the resizing, conversion, filtering and stuff (LoadSurfaceFromMemory). -- Philip Nilsson
Re: Alternative for isinf (fix for bug 12008) (version 2)
+#if !defined(HAVE_ISINF) defined(HAVE_IEEEFP_H) +#include ieeefp.h +#define isinf(x) (!(finite(x) || isnand(x))) +#endif The problem with macros is that something like isinf(*x++) won't do what you intend. That's why even for such a simple case a function would be better imho. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Stolen from an Internet user: f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !
Re: gdi32: Make the bitmap test pass under Windows 2000
On Mon, Apr 21, 2008 at 10:06 AM, Dmitry Timoshkov [EMAIL PROTECTED]
wrote:
Alexandre Julliard [EMAIL PROTECTED] wrote:
@@ -967,15 +970,19 @@ static void test_bitmap(void)
hdc = CreateCompatibleDC(0);
assert(hdc != 0);
+if (0)
+{ /* this test fails under Win2k */
SetLastError(0xdeadbeef);
hbmp = CreateBitmap(0x7ff, 1, 1, 1, NULL);
ok(hbmp != 0, CreateBitmap should not fail\n);
DeleteObject(hbmp);
+}
It would be better to find values that work on all platforms, instead of
disabling the test completely.
Yes, it would be better, but unfortunately I don't have windows 2000
installed around.
--
Dmitry.
I've got about 6 2k boxes lying around at work I can test on...
Re: gdi32: Make the bitmap test pass under Windows 2000
On Mon, Apr 21, 2008 at 10:40 AM, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Paul Vriens [EMAIL PROTECTED] wrote: Is there a specific combination you are looking for? Huge width, small height? Anything you could test that will lead to a reasonable conclusion. Or the maximum size possible? At least we need to know this one. The maximum values for both width and height on win2k is 32767. Anything above that on either parameter returns ERROR_INVALID_PARAMETER. Both params can be 32767 at the same time and the call will still succeed (assuming there's enough memory left). -- James Hawkins
Re: gdi32: Make the bitmap test pass under Windows 2000
James Hawkins wrote: On Mon, Apr 21, 2008 at 10:40 AM, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Paul Vriens [EMAIL PROTECTED] wrote: Is there a specific combination you are looking for? Huge width, small height? Anything you could test that will lead to a reasonable conclusion. Or the maximum size possible? At least we need to know this one. The maximum values for both width and height on win2k is 32767. Anything above that on either parameter returns ERROR_INVALID_PARAMETER. Both params can be 32767 at the same time and the call will still succeed (assuming there's enough memory left). Yep, exactly what I just found. -- Cheers, Paul.
Re: MSIME support causing slow setup until explorer.exe paused?
On Mon, Apr 21, 2008 at 5:12 AM, Aric Stewart [EMAIL PROTECTED] wrote: MSIMEService, MSIMEReconvertOptions, MSIMEMouseOperator, etc... those are all Messages that Microsoft Office looks for and sends to the IME during operations. For the most part all those messages are just stubbed. The messages are Registered in Imm32/imm.c once per process, and also registered in winex11.drv/ime.c also once per process. I am pretty sure we do not send those messages somewhere. So I am not sure why they would be taking up so much cpu time. Do you know what is happening with the messages during the slow-down? Oddly, they don't seem to be happening on Dapper. I'll try again on Gutsy tonight. (Chris Smith says he saw something like this with iTunes on gentoo today, too.)
Re: [1/4] dinput: Return error for unknown property.
I'd like to see tests for this. Also lots of programs will break because they won't get some not significant property. No short - don't do this. But wine return a garbage value also for significant property. This value may cause undefined behavior of application. The patch will make errors more explicit.
Re: Wine64?
Hello Erik, 2008/4/21, Erik de Castro Lopo [EMAIL PROTECTED]: Hi all, I'm interested in the current state of work towards Wine64, ie running Win64 binaries on x86_64 Linux machines. My needs are actually really simple and hence may be a good base functionality to work towards. I just need to run Win64 binaries that read stdin, write stdout/stderr and do file I/O using the standard windows CreateFile/ReadFile/WriteFile/CloseHandle/ SetFilePointer etc functions. I have found and read this: http://wiki.winehq.org/Wine64 but some of that stuff seems rather out-of-date. When I configure with --enable-win64 it configures fine but then errors out in widl generated code because of things like this: #if !defined(__RPC_WIN32__) #error Currently only Wine and WIN32 are supported. #endif So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list? Any way for me to get involved? A lot of the lowest level stuff is currently missing. If you don't mind x64 assembly it's not impossible to do. We would need support from gcc for the windows calling convention, and making it possible to mix linux calling convention with windows calling convention. If you are up to it just make it ignore the error for now, even if it causes errors. A proof of concept Hello, world! would be a great accomplishment at this point. Cheers, Maarten.
Re: winmm/tests: waveOutGetDevCaps called with invalid size
Peter Åstrand wrote: On Fri, 18 Apr 2008, Robert Reif wrote: -rc=waveOutGetDevCapsA(device,capsA,4); +/* Final call must succeed, capsA will be used below */ +rc=waveOutGetDevCapsA(device,capsA,sizeof(capsA)); ok(rc==MMSYSERR_NOERROR, waveOutGetDevCapsA(%s): MMSYSERR_NOERROR expected, got %s\n, dev_name(device),wave_out_error(rc)); - -rc=waveOutGetDevCapsW(device,capsW,4); -ok(rc==MMSYSERR_NOERROR || rc==MMSYSERR_NOTSUPPORTED, - waveOutGetDevCapsW(%s): MMSYSERR_NOERROR or MMSYSERR_NOTSUPPORTED - expected, got %s\n,dev_name(device),wave_out_error(rc)); +if (rc!=MMSYSERR_NOERROR) + return; That's the whole point of the test, to check what happens with an invalid argument. So what do you think *should* happen with an invalid argument? The result is different on different Windows platforms. The behaviour is not specified by MSDN. In any case, continuing and executing code that uses capsA even though the waveOutGetDevCapsA call failed is definitely wrong. Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00 This is the proper fix: diff --git a/dlls/winmm/tests/wave.c b/dlls/winmm/tests/wave.c index 60f0622..37367c2 100644 --- a/dlls/winmm/tests/wave.c +++ b/dlls/winmm/tests/wave.c @@ -888,6 +888,13 @@ static void wave_out_test_device(int dev nameA=strdup(not supported); } +rc=waveOutGetDevCapsA(device,capsA,sizeof(capsA)); +ok(rc==MMSYSERR_NOERROR, + waveOutGetDevCapsA(%s): MMSYSERR_NOERROR expected, got %s\n, + dev_name(device),wave_out_error(rc)); +if (rc!=MMSYSERR_NOERROR) +return; + trace( %s: \%s\ (%s) %d.%d (%d:%d)\n,dev_name(device),capsA.szPname, (nameA?nameA:failed),capsA.vDriverVersion 8, capsA.vDriverVersion 0xff, capsA.wMid,capsA.wPid);
Re: [1/4] dinput: Return error for unknown property.
Sergey Khodych wrote: I'd like to see tests for this. Also lots of programs will break because they won't get some not significant property. No short - don't do this. But wine return a garbage value also for significant property. This value may cause undefined behavior of application. The patch will make errors more explicit. On another hand - that's the way Wine been headed - break everything that's not implemented. So go ahead and put that error in. Vitaliy.
Re: version: Fix tests that fail in win9x and win2k
James Hawkins wrote: Hi, Changelog: * Fix tests that fail in win9x and win2k. dlls/version/tests/info.c | 29 +++-- 1 files changed, 19 insertions(+), 10 deletions(-) Hi James, No patch attached. Best Regards Alistair Leslie-Hughes
Re: Strange struct alignment errors?
On Sun, Apr 20, 2008 at 3:57 AM, Dan Kegel [EMAIL PROTECTED] wrote: Shoot, icc ought to be able to handle those, but you're right, we should ignore any icc results. At least until I am done... =) But yeah icc's alignment handling seems to be totally broken...I've tried every alignment switch known to man and still get problems. -- 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: Secure filename copy to fixed size variable wfileName
Tomasz Jezierski - Tefnet [EMAIL PROTECTED] wrote: - strcpyW(wfileName, sei_tmp.lpFile); + StrCpyNW(wfileName, sei_tmp.lpFile,sizeof(wfileName)); } } else - strcpyW(wfileName, sei_tmp.lpFile); + StrCpyNW(wfileName, sei_tmp.lpFile,sizeof(wfileName)); Your patch doesn't make the code more secure than it is now. StrCpyNW takes number of characters, not bytes. And since it's just a wrapper around lstrcpynW it's better to use the latter one instead. -- Dmitry.
Documentation updating / XML?
I've been working on some of the documentation, then remembered that Scott requested a move to XML: http://bugs.winehq.org/show_bug.cgi?id=12217 There are quite a few programs to convert SGML to XML, and I've got a bit of time to kill. Alexandre, would you accept a move to XML, or would this be a waste of time? -Austin
What to do about filenames legal in Linux but illegal in Windows?
Linux users create files with names that are legal in Linux but not in Windows, simply because they can. Eventually they'll try to read those files in a Windows app, either by carrying them on a flash drive over to a real windows system, by dual booting, or by running the app in Wine. Now, normally, Wine should do exactly what Windows does. (I believe that in both Windows and Wine, directory listings will show these illegal chars, but attempts to open the files will fail.) But let's say we're in that happy time in the near future when lots of companies are willing to ship their apps with Wine as a halfway house to native support, and lots of their users start running into this issue. Can/should such apps tell Windows or Wine Oh, go ahead and let me open those funny files? On Wine, of course, we could open up a hole if we had to, but it'd be nice to know if there were a method that also worked on Windows. I looked around a bit today for a way to open such files in Windows, and failed miserably (though I did find a nice example of how to use NtCreateFile without the DDK). Anyone know of a way on real Windows to do this?
Re: What to do about filenames legal in Linux but illegal in Windows?
* On Mon, 21 Apr 2008, Dan Kegel wrote: (I believe that in both Windows and Wine, directory listings will show these illegal chars, but attempts to open the files will fail.) ... I looked around a bit today for a way to open such files in Windows, and failed miserably ... Anyone know of a way on real Windows to do this? For a files that were at least undeletable I remember I have been using a feature of Total Commander to switch format of files displayed to a Short/Long form. Not all files give up for me this way, but half of them did, though.
