October 2007 - Wine-Devel - list.winehq.org

start:start.c Display messages in the console encoding.

by Kirill K. Smirnov

> static void output(const char *message) > { >- DWORD count; >- WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), >&count, NULL); >+ DWORD count = 0; >+ WCHAR *mesW = NULL; >+ char *mes = NULL; >+ int wlen = 0; >+ int len = 0; >+ >+ wlen = MultiByteToWideChar( CP_ACP, 0, message, -1, NULL, 0 ); >+ mesW = HeapAlloc( GetProcessHeap(), 0, wlen * sizeof(WCHAR) ); >+ mes = HeapAlloc( GetProcessHeap(), 0, wlen * sizeof(char) ); >+ >+ MultiByteToWideChar( CP_ACP, 0, message, -1, mesW, wlen ); >+ len = WideCharToMultiByte( GetConsoleOutputCP(), 0, mesW, wlen, NULL, 0, >NULL, NULL ); >+ WideCharToMultiByte( GetConsoleOutputCP(), 0, mesW, wlen, mes, len, NULL, >NULL ); >+ >+ WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), mes, len, &count, NULL); >+ if( !count && len ) >+ SetLastError( ERROR_FUNCTION_FAILED ); >+ >+ HeapFree(GetProcessHeap(), 0, mesW); >+ HeapFree(GetProcessHeap(), 0, mes); > } WriteFile does not output unicode characters to console screen buffer, so if ConsoleOutputCP is smth like 65001, this will fail. The page http://msdn2.microsoft.com/en-us/library/ms687401.aspx contains remedy by Microsoft how to deal with problem: 1) If device handle is console, then output wide chars using WriteConsoleW 2) If device handle is not console, then convert wide chars to ConsoleOutputCP and output using WriteFileA. This way is already implemented in cmd (See WCMD_output_asis_len function). And it may be much better to convert start utility to unicode. -- Kirill P.S. all this manipulations is supposed to be done by msvcrt printf function family, but wine lacks this functionality :-(

Oct. 24, 2007

windows on solaris

by S E

Hi , I have an executable that resides and compiled on windows 2003 server, I want to approach from my UNIX Solaris machine and run the executable. If anyone knows how to do that, or what can I use to run that I will be very happy. Thanks, SE

Oct. 24, 2007

Re: PulseAudio as a sound output?

by L. Rahyen

On Monday October 8 2007 23:01, TheBlunderbuss wrote: > L. Rahyen wrote: > Please test with your uniprocessor and get back to us on it. Not all of us > can have the top-of-the-line system. To all: stay away from Celerons! 128KB > L2 isn't enough! Sorry for a big delay in reply. In practice it is very difficult for me to test anything on my server (because as I said it used for tasks related to forex and therefore I only can test something on weekends; this is sometimes is difficult too because currently I have a lot of work at weekends too unfortunately). I wasn't able to do full tests (compare different kernels, test all typical situations, etc.) because of lack of time and therefore I cannot post exact numbers to compare, sorry. But I post at least my impressions related to work of old uniprocessor system with 2.6.23 kernel. Well, everything is good. At least it seems to me that now everyone can forgot about sound issues when system is under heavy load: sound is clean even if I have a lot of working processes in background (I tested up to 10 - that's more than enough for uniprocessor system I think). I tried processes with and without heavy disk I/O - and sound was perfect. However, new scheduler isn't so perfect as it may seems at first glance. There is some issues with fairness anyway. And there is still no option to select frequencies higher than 1 KHz in vanilla kernel (this is sometimes useful for uniprocessor systems). I didn't run benchmarks so I cannot be sure but I think that my 2.6.22 kernel with some patches and hacks to the scheduler worked somewhat better, more smoothly under heavy load. Yes sound is clean and good but some applications doesn't run as smooth as I expect even with -20 niceness under heavy load (on my quad-core processor there is no such problem). Unfortunately I didn't test OpenGL (and games) in my uniprocessor system with 2.6.23 kernel because of annoying bug in NVidia driver which happens sometime on this old machine: I have less than 1 FPS everywhere and only way to "fix" this is to reboot the machine (or reload the driver manually but this isn't working in all cases and require to shutdown X servers anyway). There was Sunday and about 20:00 GMT so I simply havn't time to test farther because after 21:00 GMT server should start its usual servicing. But even without any benchmarking I can say that 2.6.23 contain very big improvement in Linux scheduler. If you compare it with vanilla 2.6.22 or older (without any hacks and modifications to the scheduler) you will see that now many thing works perfectly even on uniprocessor system. As I have said before SMP systems have especially noticeable improvements. Now 2.6.23 is stable so everyone can easily try and test it. All major distribution should provide precompiled 2.6.23 kernels in near future.

Oct. 24, 2007

wineconf photos

by Steven Edwards

Hi, I was not lucky enough to have my digital camara with me during Wineconf, so if you've got photos uploaded somewhere please post urls or better yet add them to the Wiki. 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

Oct. 24, 2007

Re: start:start.c Display messages in the console encoding.

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > static void output(const char *message) > { > - DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + DWORD count = 0; > + WCHAR *mesW = NULL; > + char *mes = NULL; > + int wlen = 0; > + int len = 0; There is no need to initialize variables to 0 since you are going to explicitly initialize them later anyway. > + wlen = MultiByteToWideChar( CP_ACP, 0, message, -1, NULL, 0 ); > + mesW = HeapAlloc( GetProcessHeap(), 0, wlen * sizeof(WCHAR) ); > + mes = HeapAlloc( GetProcessHeap(), 0, wlen * sizeof(char) ); Allocating wlen chars for 'mes' won't work correctly on a multibyte locale. > + MultiByteToWideChar( CP_ACP, 0, message, -1, mesW, wlen ); > + len = WideCharToMultiByte( GetConsoleOutputCP(), 0, mesW, wlen, NULL, 0, NULL, NULL ); Just move the call to allocate 'len' bytes for 'mes' here. > + WideCharToMultiByte( GetConsoleOutputCP(), 0, mesW, wlen, mes, len, NULL, NULL ); -- Dmitry.

Oct. 24, 2007

rpc: (resend) Add missing headers

by Roy Shea

Hello, Attached is a corrected version of this patch. I thank Mikolaj who brought to my attention the fact that rpcproxy.h is the incorrect location to include the files I added in the earlier patch. This revised patch adds the includes directly to rpc.h. The Windows version of rpc.h accesses these includes throuh windows.h. Peace, -Roy On Tue, Oct 23, 2007 at 09:50:25AM -0700, Roy Shea wrote: > Howdy, > > The REGISTER_PROXY_DLL_ROUTINES macro defined in rpcproxy.h calls > DisableThreadLibraryCalls. This patch adds two header files needed > for calls to DisableThreadLibraryCalls. > > Peace, > -Roy >

Oct. 24, 2007

Re: [PATCH 3/3] configure: Use 0 instead of NULL because NULL isn't defined.

by David Laight

On Sat, Oct 20, 2007 at 11:12:10AM +0200, Alexandre Julliard wrote: > Michael Stefaniuc <mstefani(a)redhat.com> writes: > > > Actually it's not a cast. It's a heuristic that the compiler has to make > > to detect a NULL pointer. The best heuristic for this is (char *) 0. (char *)0 is bad, 0 is ok, as is (void *)0 > > There's no heuristic involved here, the assignment is clearly to a > pointer, and 0 is a perfectly valid null pointer, no cast is needed. As is 1-1, or any other compile time integer expression with a numeric vaule of zero. David -- David Laight: david(a)l8s.co.uk

Oct. 23, 2007

Re: widl [3/4]: Remove printf format strings that aren't really format strings.

by David Laight

On Thu, Oct 18, 2007 at 11:12:23AM +0200, Michael Stefaniuc wrote: > > - fprintf(file, varname); > > + fprintf(file, "%s", varname); > fputs() would be a faster alternative to that. Though i doubt that > matters in this case. FWIW gcc tends to convert fprintf(file, "%s", arg) into fputs(arg, file). Discovered on a semi-embedded system which had fprintf, but not fputs :-) David -- David Laight: david(a)l8s.co.uk

Oct. 23, 2007

Re: wininet: ftp test hangs behind firewall, so turn it off by default

by Dan Kegel

On 10/23/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > I don't think it really hangs, it just takes a long time to complete. That could be. Waiting for it to finish is like waiting for paint to dry, though. It took six minutes just now, and I'm on a fast connection. If we're going to keep it, can we shorten it so it passes in one minute or less? > > It would be better to embed a little ftp server into the test, > > and connect to that instead of a public one, but that would > > be a pain. > > No, we clearly want to run the test against a real ftp server. Running > it against different types of servers would be even better. What we > should probably do is try to connect to a server on localhost first, > this way people can install the server of their choice to provide more > test coverage. That would be an improvement. - Dan

Oct. 23, 2007

Re: msi: Propogate errors from events all the way up to the parent dialog

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > Fixes bug 10107. http://bugs.winehq.org/show_bug.cgi?id=10107 > > Changelog: > * Propogate errors from events all the way up to the parent dialog. This one fails for me: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so package.c && touch package.ok package.c:587: Test failed: wrong return val make: *** [package.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Oct. 23, 2007