April 2007 - Wine-devel - list.winehq.org

Re: winealsa: Implement Get/SetControlDetails
by Alexandre Julliard 23 Apr '07

23 Apr '07

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -748,6 +749,22 @@ static DWORD MIX_GetDevCaps(UINT wDevID, LPMIXERCAPS2W caps, DWORD_PTR parm2) > return MMSYSERR_NOERROR; > } > > +/* convert win32 volume to alsa volume, and vice versa */ > +static DWORD normalized(long value, long prevmax, long nextmax) > +{ > + double ret = (double)value; > + ret *= (double)nextmax; > + ret /= (double)prevmax; > + ret += .5; > + TRACE("%ld/%ld -> %ld/%ld\n", value, prevmax, (long)ret, nextmax); > + > + if (ret > nextmax) > + ret = nextmax; > + else if (ret < 0) > + ret = 0; > + > + return (DWORD)ret; > +} You should probably use MulDiv() instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Removal of unused audio drivers
by Maarten Lankhorst 23 Apr '07

23 Apr '07

There are 5 different audio drivers for linux, I think this is a bit overkill, so I propose to remove the esd and nas drivers, I don't think anyone uses esd, especially that since for that task alsa can be used now since dmix addon. I'm not sure what nas is for, but it seems to be 'network audio system', I haven't seen any use for it, except that it causes a 30 seconds slowdown at showing 'audio' tab in winecfg. I don't think anyone uses it. For esd I think it's best to remove, for nas I'm also for remove, but I'll settle for removing it from winecfg list same way as winearts was disabled for a while. What are your thoughts about this? Maarten

11 13

Sorry for spamming the list :(
by Jonathan Schleifer 23 Apr '07

23 Apr '07

I had some trobule sending the messages, it seemed like they were filtered out since I wasn't subscribed to the list, therefore I resent them, but it seems like they got through after 24h. :( My apologies for this. -- Jonathan

1 0

Re: implements D3DRMVectorAdd
by Stefan Dösinger 23 Apr '07

23 Apr '07

Am Montag 16 April 2007 01:29 schrieb David.Adam(a)math.cnrs.fr: +/* Add Two Vectors */ +LPD3DVECTOR D3DRMAPI D3DRMVectorAdd(LPD3DVECTOR d, LPD3DVECTOR s1, LPD3DVECTOR s2) I personally prefer D3DVECTOR * over LPD3DVECTOR, but I don't know if there's any rule for that. If in doubt follow your personal preferences. + ok( ((fabs(expectedvec.x-gotvec.x)<0.000001)&&(fabs(expectedvec.y-gotvec.y)<0.000001)&&(fabs(expectedvec.z-gotvec.z)<0.000001)), \ Perhaps its better to make 0.000001 a constant? + todo_wine { + expect_vec(e,r); + } Why did you make this a TODO_WINE if you just imlemented the function?

2 1

Re: Fix xcopy so output is either unicode (console) or oem (file)
by Kirill K. Smirnov 23 Apr '07

23 Apr '07

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > >> The written strings in 866 and 1251 code pages are only readable > >> when output console code page matches the string encoding. > > > > This is in wine. > > In windows only cp866 is readable regardless of ConsoleOutputCP. > > As I said I tested under Windows (XP) only, and SetConsoleOutputCP > does change the behaviour of WriteConsoleA for me. If it wouldn't > I'd call it a bug. I tested under Windows 2003 and SetConsoleOutputCP does NOT change the behaviour of WriteConsoleA for me. Does Windows play us a trick?

2 2

Re: Fix xcopy so output is either unicode (console) or oem (file)
by Kirill K. Smirnov 23 Apr '07

23 Apr '07

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > > A question: what make you think that WriteConsole uses current console > > output code page to translate strings? > > The written strings in 866 and 1251 code pages are only readable > when output console code page matches the string encoding. This is in wine. In windows only cp866 is readable regardless of ConsoleOutputCP.

2 1

Re: Fix xcopy so output is either unicode (console) or oem (file)
by Kirill K. Smirnov 23 Apr '07

23 Apr '07

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > >> WriteConsole uses current console output code page to translate strings. > > > > wine - yes. > > windows - no. > > See attach. > > What makes you think so? Since I tested under Windows only I described > the results I've got under it not under Wine. Wine behaviour is not > interesting at this point. I tested under both windows and wine. The results I attached in previous mail make me think so. Please, have a look at them. A question: what make you think that WriteConsole uses current console output code page to translate strings? -- Kirill

2 1

Re: Fix xcopy so output is either unicode (console) or oem (file)
by Kirill K. Smirnov 23 Apr '07

23 Apr '07

> wprintf does write unicode strings to a console, the problem in your test > is that it doesn't change the locale from the default "C" to russian, and > the conversion from unicode to code page simply fails. > I'm attaching a modified version of your test, with some > results/conclusions: I failed to compile it under mingw32 nor winegcc as-is: con_test_dmitry.c:33:21: converting to execution character set: Invalid or incomplete multibyte or wide character con_test_dmitry.c:50:21: converting to execution character set: Invalid or incomplete multibyte or wide character > WriteConsole uses current console output code page to translate strings. wine - yes. windows - no. See attach. > WriteConsole does produce an output when not redirecting output to a file. Yes. > WriteConsole does not produce an output when redirecting output to a file, > returns FALSE and sets last error to 6 (ERROR_INVALID_HANDLE). Yes. > wprintf translates unicode strings to current CRT multibyte locale before > printing them either to a console or to a file. > > printf doesn't care about locale at all, it simply prints what it has. I do not know much about msvcrt, but I can say, they suffer from the same bug as WriteConsole. > So, the patch sent by Jason is OK, except using wchar_t instead of WCHAR. Yes, it is OK. I understood that a bit later... I've slightly modified your test to make it compile under mingw32. The results under windows and wine are attached. -- Kirill P.S. I've appiled Jason's patch during tests.

2 1

Re: Fix xcopy so output is either unicode (console) or oem (file)
by Kirill K. Smirnov 23 Apr '07

23 Apr '07

No, from this point of view the patch is correct. >> +/* >========================================================================= >> + * Output a formatted unicode string. Ideally this will go to the console >> + * and hence required WriteConsoleW to output it, however if file i/o is >> + * redirected, it needs to be WriteFile'd using OEM (not ANSI) format >> + * >>========================================================================= */ >The described above behaviour should be implemented either inside of wprintf >implementation in msvcrt, Just little test: #include <windows.h> #include <stdio.h> int main(void) { WCHAR str_uni[]={0x044d, 0x0442, 0x043e, 0x0020, 0x0442, 0x0435, 0x0441, 0x0442, 0x0000}; char str_oem[]="~]Б╝ ЮЦАА╙╗╘ Б╔╙АБ in OEM"; wprintf(str_uni); printf(str_oem); return 0; } It will write both strings in wine and only second in windows. wprintf should not write unicode strings to console. >or inside of the console driver of WriteConsoleW >depending on the test results IMO. And not here too. Application must check this itself. http://msdn2.microsoft.com/en-us/library/ms687401.aspx contains tips: [quote] Both WriteConsole and WriteFile can be used for console I/O. While WriteConsole supports writing Unicode characters to a console screen buffer, WriteFile does not. However, WriteConsole fails if it is used with a standard handle that is redirected to a file. If an application handles multilingual output that can be redirected, determine whether the output handle is a console handle (one method is to call the GetConsoleMode function and check whether it succeeds). If the handle is a console handle, call WriteConsole; otherwise, the output is redirected and you should call WideCharToMultiByte to convert the text to the current code page and WriteFile to perform the I/O. [/quote] There are some my tests at: http://www.winehq.com/pipermail/wine-devel/2007-April/056102.html I could miss something, it would be great if you check it! I've just found another bug in the patch: >+ /* Convert to OEM, then output */ >+ convertedChars = WideCharToMultiByte(GetConsoleOutputCP(), 0, >output_bufW, >+ len, output_bufA, MAX_WRITECONSOLE_SIZE, >+ "?", &usedDefaultChar); The comment is correct, but code is wrong. Here should be CP_OEMCP instead of GetConsoleOutputCP(). I did not noticed it before, because there two bugs: one is here, and another is in WriteConsoleA (the same bug - should be CP_OEMCP not GetConsoleOutputCP()). And they are mutually annihilated ;-) Test demostrating that WriteConsoleA is wrong: #include <windows.h> #include <stdio.h> int main(void) { DWORD tmp; WCHAR str_uni[]={0x044d, 0x0442, 0x043e, 0x0020, 0x0442, 0x0435, 0x0441, 0x0442, 0x0000}; char str_oem[]="~]Б╝ ЮЦАА╙╗╘ Б╔╙АБ in OEM\n"; WriteConsoleW(GetStdHandle(STD_OUTPUT_HANDLE), str_uni, wcslen(str_uni), &tmp, NULL); WriteConsoleA(GetStdHandle(STD_OUTPUT_HANDLE), str_oem, strlen(str_oem), &tmp, NULL); SetConsoleCP(1251); SetConsoleOutputCP(1251); WriteConsoleW(GetStdHandle(STD_OUTPUT_HANDLE), str_uni, wcslen(str_uni), &tmp, NULL); WriteConsoleA(GetStdHandle(STD_OUTPUT_HANDLE), str_oem, strlen(str_oem), &tmp, NULL); SetConsoleCP(866); SetConsoleOutputCP(866); return 0; } =^_^= -- Kirill

2 2

WineD3D patch test needed
by Stefan Dösinger 23 Apr '07

23 Apr '07

Hi, I have a patch which fixes the performance problems introduced with c0782603d09807c6ca506948bb4a814a73430184 . I am sure that the patch is correct, but I have the bad feeling that it brings up a few other bugs, so I send it to wine-devel for testing first. It only reallocates surfaces when they are either new or the description was changed. Thanks, Stefan

3 3