- Wine-Devel - list.winehq.org

Re: include/guiddef.h: C++ compatibility patch (with MSVC++ support)
by Dmitry Timoshkov Sept. 2, 2005

Sept. 2, 2005

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > --- include/guiddef.h (revision 26053) > +++ include/guiddef.h (local) > @@ -35,12 +35,18 @@ > #undef DEFINE_GUID > > #ifdef INITGUID > +#ifdef __cplusplus > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > + EXTERN_C const GUID name = \ > + { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#else > +#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > const GUID name = \ > { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#endif > #else > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > - extern const GUID name > + EXTERN_C const GUID name > #endif > > #define DEFINE_OLEGUID(name, l, w1, w2) \ There are 2 problems with this patch: you forgot to provide a definition for EXTERN_C, and it needlessly duplicates code for the __cplusplus case. -- Dmitry.

2 1

Re: URLMON: Added CreateAsyncBindCtxEx implementation
by Robert Shearman Sept. 2, 2005

Sept. 2, 2005

Jacek Caban wrote: >+static void test_CreateAsyncBindCtxEx(void) >+{ >+ IBindCtx *bctx = NULL, *bctx_arg = NULL; >+ IBindStatusCallback *bsc = statusclb_create(); >+ BIND_OPTS bindopts; >+ HRESULT hres; >+ >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, NULL, 0); >+ ok(hres == E_INVALIDARG, "CreateAsyncBindCtx failed: %08lx, expected E_INVALIDARG\n", hres); >+ >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, &bctx, 0); >+ ok(hres == S_OK, "CreateAsyncBindCtxEx failed: %08lx\n", hres); >+ >+ if(SUCCEEDED(hres)) { >+ bindopts.cbStruct = sizeof(bindopts); >+ hres = IBindCtx_GetBindOptions(bctx, &bindopts); >+ ok(SUCCEEDED(hres), "IBindCtx_GetBindOptions failed: %08lx\n", hres); >+ ok(bindopts.grfFlags == BIND_MAYBOTHERUSER, >+ "bindopts.grfFlags = %08lx, expected: BIND_MAYBOTHERUSER\n", bindopts.grfFlags); >+ ok(bindopts.grfMode = STGM_READWRITE | STGM_SHARE_EXCLUSIVE, > > Are you sure you mean to assign the value instead of just testing it? >+ "bindopts.grfMode = %08lx, expected: STGM_READWRITE | STGM_SHARE_EXCLUSIVE\n", >+ bindopts.grfMode); >+ ok(bindopts.dwTickCountDeadline == 0, >+ "bindopts.dwTickCountDeadline = %08lx, expected: 0\n", bindopts.dwTickCountDeadline); >+ >+ IBindCtx_Release(bctx); >+ } >+ >+ CreateBindCtx(0, &bctx_arg); >+ hres = CreateAsyncBindCtxEx(NULL, 0, NULL, NULL, &bctx, 0); >+ ok(hres == S_OK, "CreateAsyncBindCtxEx failed: %08lx\n", hres); >+ >+ if(SUCCEEDED(hres)) { >+ bindopts.cbStruct = sizeof(bindopts); >+ hres = IBindCtx_GetBindOptions(bctx, &bindopts); >+ ok(SUCCEEDED(hres), "IBindCtx_GetBindOptions failed: %08lx\n", hres); >+ ok(bindopts.grfFlags == BIND_MAYBOTHERUSER, >+ "bindopts.grfFlags = %08lx, expected: BIND_MAYBOTHERUSER\n", bindopts.grfFlags); >+ ok(bindopts.grfMode = STGM_READWRITE | STGM_SHARE_EXCLUSIVE, >+ "bindopts.grfMode = %08lx, expected: STGM_READWRITE | STGM_SHARE_EXCLUSIVE\n", >+ bindopts.grfMode); > > Same here. -- Rob Shearman

1 0

Wine test results problem
by Katerina Nizhnik Sept. 2, 2005

Sept. 2, 2005

Hi, I execute Wine tests on clean Windows XP SP2 and Windows 2003 SP1 EE. I tried to use both pre-compiled binary from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe and Wine sources built by myself with Visual Studio .NET 2003 (20050830 version). What I do is just launching the test several times on the same machine and comparing log files received. Please, see the sample diff of 2 such log files. Why the number of tests executed and number of failures are so different for the identical test groups? It seems to be some synchronization problem. How should I fix this to obtain stable results? Thank you in advance. ------------------------------------------------------------ @@ -50,7 +50,7 @@ module: 34 tests executed, 0 marked as todo, 0 failures. mailslot: 75 tests executed, 0 marked as todo, 0 failures. path: 1741 tests executed, 0 marked as todo, 0 failures. -pipe: 419 tests executed, 0 marked as todo, 0 failures. +pipe: 418 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. @@ -78,7 +78,7 @@ util: 139 tests executed, 0 marked as todo, 136 failures. mlang: 11211 tests executed, 0 marked as todo, 20 failures. msacm: 385 tests executed, 0 marked as todo, 0 failures. -profile: 127 tests executed, 0 marked as todo, 1 failure. +profile: 127 tests executed, 0 marked as todo, 0 failures. htmldoc: 688 tests executed, 0 marked as todo, 0 failures. protocol: 255 tests executed, 0 marked as todo, 0 failures. db: 73 tests executed, 0 marked as todo, 0 failures. @@ -104,7 +104,7 @@ env: 611 tests executed, 0 marked as todo, 0 failures. error: 813 tests executed, 0 marked as todo, 0 failures. generated: 1981 tests executed, 0 marked as todo, 0 failures. -info: 765 tests executed, 0 marked as todo, 0 failures. +info: 725 tests executed, 0 marked as todo, 0 failures. large_int: 700 tests executed, 0 marked as todo, 0 failures. path: 230 tests executed, 0 marked as todo, 5 failures. reg: 9 tests executed, 0 marked as todo, 0 failures. @@ -133,7 +133,7 @@ main: 15 tests executed, 0 marked as todo, 1 failure. generated: 1141 tests executed, 0 marked as todo, 0 failures. shelllink: 116 tests executed, 0 marked as todo, 3 failures. -tests/shellpath.c: 10 tests executed, 0 marked as todo, 0 failures. +tests/shellpath.c: 10 tests executed, 0 marked as todo, 4 failures. tests/shellpath.c: 4 tests executed, 0 marked as todo, 0 failures. shellpath: 447 tests executed, 0 marked as todo, 3 failures. shlexec: 20 tests executed, 0 marked as todo, 0 failures. @@ -174,4 +174,4 @@ timer: 44 tests executed, 0 marked as todo, 0 failures. wave: 289 tests executed, 0 marked as todo, 15 failures. protocol: 26 tests executed, 0 marked as todo, 0 failures. -sock: 8971 tests executed, 0 marked as todo, 5 failures. +sock: 8951 tests executed, 0 marked as todo, 5 failures. ------------------------------------------------------------ -- Sincerely yours, katy

1 0

Re: WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)
by Alex Villacís Lasso Sept. 1, 2005

Sept. 1, 2005

Robert Reif wrote: > Alex Villacís Lasso wrote: > >> Robert Reif wrote: >> >>> Fix the wine ALSA driver rather than the test unless you can prove >>> that the test fails on Windows. >>> > Hers is a real quick hack that fixes the problem. This should give > you someplace to start. > >------------------------------------------------------------------------ > >? audio.c.test >? audio.diff >Index: audio.c >=================================================================== >RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v >retrieving revision 1.96 >diff -p -u -r1.96 audio.c >--- audio.c 12 Aug 2005 11:17:54 -0000 1.96 >+++ audio.c 31 Aug 2005 00:59:33 -0000 >@@ -2527,14 +2527,16 @@ static DWORD wodOpen(WORD wDevID, LPWAVE > getFormat(wwo->format.Format.wFormatTag)); > > dir=0; >- EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params, &buffer_time, &dir), MMSYSERR_INVALPARAM, "unable to set buffer time"); >+// EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params, &buffer_time, &dir), MMSYSERR_INVALPARAM, "unable to set buffer time"); >+ buffer_size = 0x10000; >+ EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_size_near(pcm, hw_params, &buffer_size), MMSYSERR_INVALPARAM, "unable to set buffer size"); > dir=0; > EXIT_ON_ERROR( snd_pcm_hw_params_set_period_time_near(pcm, hw_params, &period_time, &dir), MMSYSERR_INVALPARAM, "unable to set period time"); > > EXIT_ON_ERROR( snd_pcm_hw_params(pcm, hw_params), MMSYSERR_INVALPARAM, "unable to set hw params for playback"); > > err = snd_pcm_hw_params_get_period_size(hw_params, &period_size, &dir); >- err = snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size); >+// err = snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size); > > snd_pcm_sw_params_current(pcm, sw_params); > EXIT_ON_ERROR( snd_pcm_sw_params_set_start_threshold(pcm, sw_params, dwFlags & WAVE_DIRECTSOUND ? INT_MAX : 1 ), MMSYSERR_ERROR, "unable to set start threshold"); > > From what I could see from the patch, it tries to set a buffer size instead of a buffer time. However, the patch did not solve the problems as it is. First, the patch supplies a constant value for snd_pcm_hw_params_set_buffer_size_near(). However, the ALSA documentation states that the parameter for buffer_size for this function is given in *frames*, not bytes. Since a frame (nChannels * bitsPerSample / 8) can be from 1 to 4 bytes depending on the requested format, this patch only fixes the frame length, not the byte length. So the attached patch divides the required buffer size (in bytes) by the frame size to arrive to the buffer size in frames. Second, even after the division, the ALSA API is unable to honor the exact value required (at least in my hardware). For most formats the upper limit on the byte size is 30104 bytes, but for the reference tone it changes to 15052 bytes. So it triggers the buffer resize all over again. The attached patch hardcodes the value of 15052 bytes (0x3acc) as the required buffer size, and then the ALSA API doesn't resize the buffer. But obviously, this is a machine-dependent value that might be different in everybody else's machine. Any other value greater than 15052 triggers the buffer resize, and other values below it cause awful buzzings and silences on the games I have tested. Even the chosen value of 15052 bytes, though it works in the tested games, causes buzzings instead of the proper tone on some 8000Hz and 11050Hz tests (the tests where the playtime is around 100-300 ms instead of 1000 ms in the attached trace). Third (but this is no longer a winealsa issue), I still get the critical section timeouts on invalid threads in aprox. 1 in 5 runs of the interactive dsound test, even on an idle CPU. This proves that the timeout bug is not because of CPU load, and should be investigated further. All of this leads me to think that the winealsa driver should give up on trying to provide access to the direct mmap buffer, and revert to providing a fixed-size buffer that is then used to feed the actual ALSA buffer. This would a) hide the buffer resizes from the tests and the games, and b) remove the need of the undocumented hardware pointer function. In fact, I do not remember what was the rationale behind switching from the old model to the current one. In addition, I have tested a few games Any comments on this are welcome. Alex Villacís Lasso

2 1

curses problems in wineconsole
by Robert Lunnon Sept. 1, 2005

Sept. 1, 2005

curses.c in wineconsole seems to be under (re) development at the moment. Under Solaris I get the following. I presume this is because the changes are being developed with ncurses in mind. gmake gcc -c -I. -I. -I../../include -I../../include -DUNICODE -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I /opt/sfw/cups/include -I /opt/sfw/cups/include -o curses.o curses.c In file included from winecon_private.h:24, from curses.c:50: ../../include/wincon.h:133:1: warning: "MOUSE_MOVED" redefined In file included from curses.c:41: /usr/include/curses.h:1487:1: warning: this is the location of the previous definition curses.c:70: error: parse error before "mmask_t" curses.c:70: warning: no semicolon at end of struct or union curses.c:75: error: parse error before '}' token curses.c:95: error: `mouseinterval' undeclared here (not in a function) curses.c:95: warning: type defaults to `int' in declaration of `p_mouseinterval' curses.c:96: error: `mousemask' undeclared here (not in a function) curses.c:96: warning: type defaults to `int' in declaration of `p_mousemask' curses.c: In function `WCCURSES_ResizeScreenBuffer': curses.c:221: error: dereferencing pointer to incomplete type curses.c:221: error: dereferencing pointer to incomplete type curses.c:222: error: dereferencing pointer to incomplete type curses.c:223: error: dereferencing pointer to incomplete type curses.c:225: error: dereferencing pointer to incomplete type curses.c:226: error: dereferencing pointer to incomplete type curses.c:226: error: dereferencing pointer to incomplete type curses.c:229: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_PosCursor': curses.c:250: error: dereferencing pointer to incomplete type curses.c:257: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_ComputePositions': curses.c:299: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_Refresh': curses.c:354: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c:356: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_FillMouse': curses.c:557: error: `MEVENT' undeclared (first use in this function) curses.c:557: error: (Each undeclared identifier is reported only once curses.c:557: error: for each function it appears in.) curses.c:557: error: parse error before "mevt" curses.c:559: error: `mevt' undeclared (first use in this function) curses.c:559: error: too many arguments to function curses.c:586: error: `BUTTON_SHIFT' undeclared (first use in this function) curses.c:588: error: `BUTTON_CTRL' undeclared (first use in this function) curses.c:590: error: `BUTTON_ALT' undeclared (first use in this function) curses.c: In function `WCCURSES_FillCode': curses.c:657: error: dereferencing pointer to incomplete type curses.c:746: error: `KEY_RESIZE' undeclared (first use in this function) curses.c: In function `WCCURSES_GetEvents': curses.c:830: error: `KEY_CODE_YES' undeclared (first use in this function) curses.c: In function `WCCURSES_DeleteBackend': curses.c:849: error: `mmask_t' undeclared (first use in this function) curses.c:849: error: parse error before "mm" curses.c:853: error: dereferencing pointer to incomplete type curses.c:855: error: dereferencing pointer to incomplete type curses.c:856: error: dereferencing pointer to incomplete type curses.c:856: error: `mm' undeclared (first use in this function) curses.c:856: error: called object is not a function curses.c:859: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_MainLoop': curses.c:873: error: dereferencing pointer to incomplete type curses.c: In function `WCCURSES_InitBackend': curses.c:906: error: invalid application of `sizeof' to incomplete type `inner_data_curse' curses.c:921: error: dereferencing pointer to incomplete type curses.c:956: error: `BUTTON_SHIFT' undeclared (first use in this function) curses.c:956: error: `BUTTON_CTRL' undeclared (first use in this function) curses.c:956: error: `BUTTON_ALT' undeclared (first use in this function) curses.c:957: error: dereferencing pointer to incomplete type curses.c:957: error: called object is not a function curses.c:962: error: called object is not a function curses.c:966: error: dereferencing pointer to incomplete type curses.c:966: error: called object is not a function gmake: *** [curses.o] Error 1

2 2

Re: Web Server Back Online
by Jeremy Newman Sept. 1, 2005

Sept. 1, 2005

Try that, let me know if it's better. Note: web browses cache mime type as well, so try a different .bin if needed. I'll try it for now. I played with mod_mime_magic as well, but was unable to get any joy out of it. It is supposed to do what the command 'file' does and get the mime type based on the contents of the file. Didn't seem to work though. On Thu, 2005-09-01 at 10:49 -0500, Robert Shearman wrote: > Could you configure .bin files to have a MIME type of text/x-diff or > something in Apache? Maybe just for the mailman directory if there are > other .bin files on the web site. >

1 0

uxtheme requiring shlwapi
by Aric Stewart Sept. 1, 2005

Sept. 1, 2005

Thanks for the great work on this! It is really cool, however I am having a dependency problem that would be great to resolve. uxtheme currently links in shlwapi.dll, shlwapi.dll in turn links in ole32.dll. Since WM_NCCREATE seems to load uxtheme it would be that ole32 is being loaded almost all the time now. This is an issue because when we here at CodeWeavers try to install dcom95.exe we need to set ole32=native (ie, disabled) so that dcom95 does not detect the builtin version. However because uxtheme is now being loaded with MessageBoxA, the install fails because it is unable to load ole32, thus shlwapi and thus uxtheme. Looking at uxtheme it seems like there are only 3 functions being used out of shlwapi. StrChrW: this is also located in comctl32.dll, while i hate to add comctl32.dll as a dependency to swap out shlwapi, it does solve the current problem, also a quick reimplementation of StrChrW as a helper function would remove this problem totally. SHRegGetPathW and PathAddBackslashW: These are really convenient functions but should not be hard to make little helper functions to replace the dependency. Any chance these changes could be made? Thanks alot, -aric

2 2

Re: KERNEL: check for NULL in LoadModule16
by Andreas Mohr Sept. 1, 2005

Sept. 1, 2005

Hi, On Mon, Aug 29, 2005 at 12:37:31PM -0500, Alex Villacís Lasso wrote: > An old copy of Print Shop Deluxe Companion manages to supply a NULL as a > name to be loaded by LoadLibrary16 --> LoadModule16 --> SIGSEGV. This > patch adds a check to return ERROR_READ_FAULT instead of crashing. > > Alex Villacís Lasso > > Changelog: > * Add a NULL check in LoadModule16 Are you sure that Windows does that thing? Somehow I really cannot imagine that during all these years this one has gone unnoticed... (and is ERROR_READ_FAULT the correct error to return here?) Thanks, Andreas Mohr

3 5

Re: Wine device drivers proposal
by Evgeny F Sept. 1, 2005

Sept. 1, 2005

In message Mon, 28 Mar 2005 02:30:28 -0800, Damjan Jovanovic wrote: > I propose adding a driver loading system to Wine that > works as follows: > -CreateFile() gets a device filename, like (in my > case) \\.\MiiScan0 > -Currently, Wine's behaviour for such a filename is to > try load a VXD. > -In the case of VXD loading failure, a search is > performed in (Wine's) C:\Windows\System32\Drivers (or > somewhere else?) for a matching driver. > > The driver is then loaded and used for (at least): > ReadFile() > WriteFile() > DeviceIoControl() > CloseHandle() I am doing now a dll which should load scanner microdriver and implement all the surrounding API's. Can anybody tell, what naming convention Windows uses for USB devices ("\\.\????")? > 2. The driver is a file giving a process to start and > some IPC method to use. Wine starts the process and > uses the IPC method to communicate with the driver. > This is good as far as Wine's current ReadFile() and > WriteFile() go, since they don't have to know they're > not writing to an actual file. The problem here is, > which IPC method supports both read() and write() on > the same file descriptor, preserves message > boundaries, and carries out-of-band data for > DeviceIoControl()? I was thinking TCP sockets, but > they don't preserve message boundaries. Local UNIX sockets would do fine, do we really have to preserve message bounderies? Evgeny

4 8

Re: include/guiddef.h: C++ compatibility patch
by Dmitry Timoshkov Sept. 1, 2005

Sept. 1, 2005

"Troy Rollo" <wine(a)troy.rollo.name> wrote: > #ifdef INITGUID > +#ifdef __cplusplus > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > + extern const GUID name = \ > + { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#else > +#define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > const GUID name = \ > { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } } > +#endif > #else > #define DEFINE_GUID(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8) \ > extern const GUID name PSDK has 'extern' for both C and CPP cases, just the CPP one has 'extern "C"'. We have to use the same approach. -- Dmitry.

4 4