August 2005 - Wine-Devel - list.winehq.org

Re: test case demonstrating PeekMessage give up timeslices

by Alexandre Julliard

Oliver Mössinger <olivwork(a)web.de> writes: > Hi wine-devel, > > attached i have a test case whitch demonstates the differece between Windows > and wine. There is also a sample program 'TEST.CPP' attached. > > On Windows XP > - Start 'test.exe' from a dos-box... you see some FAST counting integers > - Start a other (loop.pl) program witch consumes mutch cpu time. > - the output of 'test.exe' is slower but FAST > > On wine > - Start 'test.exe' from a dos-box... you see some FAST counting integers > - Start a other (loop.pl) program witch consumes mutch cpu time. > - the output of 'test.exe' is very slow > > This different behavior starts from wine version 20041201. The version before > was ok. > > I have no patch and it would be nice if someone can write a patch to fix this. You can probably fix it by passing PM_NOYIELD in the PeekMessage calls. But if your app needs a lot of CPU, restructuring the code to avoid all the needless polling would give much better results, and probably improve the behavior on Windows too. -- Alexandre Julliard julliard(a)winehq.org

Aug. 2, 2005

Re: pf_vsnprintf implementatnion of 'I', 'I32' and 'I64' prefixes for type specifiers

by Jonathan Wilson

> Feel free to go ahead and write one if you like :) One assumes ReactOS needs such a function, how do they do it? Would getting the ReactOS guys to re-licence as LGPL (if such a thing is even possible) their printf base code work? (is what they have even any use?) Just a thought :)

Aug. 2, 2005

Re: Esound support

by Tom Wickline

On 8/1/05, Peter Åstrand <astrand(a)cendio.se> wrote: > > Hi. This patch implements Esound sound support. See > http://bugs.winehq.com/show_bug.cgi?id=326 for details. Can it be applied? > > Index: ChangeLog > =================================================================== > RCS file: /home/wine/wine/ChangeLog,v > retrieving revision 1.96 > diff -u -r1.96 ChangeLog > --- ChangeLog 25 Jul 2005 12:22:04 -0000 1.96 > +++ ChangeLog 1 Aug 2005 13:02:04 -0000 > @@ -1,4 +1,8 @@ > ----------------------------------------------------------------- > +2005-08-01 Peter Astrand <astrand(a)cendio.se> > + * configure.ac, dlls/Makefile.in, include/config.h.in, programs/winecfg/audio.c, > + programs/winecfg/properties.c: Implemented EsounD sound support (#326). > + > + ---------------------------------------------------------------- > 2005-07-25 Alexandre Julliard <julliard(a)winehq.com> > > * dlls/comctl32/updown.c: Frank Richter <frank.richter(a)gmail.com> > Index: configure.ac You may want to remove this from your patch as only Alexandre does the changelog. Only patches that are excepted can be included into the changelog, and he has to except it first.. Tom

Aug. 2, 2005

Re: pf_vsnprintf implementatnion of 'I', 'I32' and 'I64' prefixes for type specifiers

by Mike McCormack

Jonathan Wilson wrote: > Question: Why doesnt WINE just have a complete implementation of the > core "printf" logic itself? It's a little more complicated than you think, after you start handling all the width modifiers, various floating point formats, etc. Feel free to go ahead and write one if you like :) Mike

Aug. 2, 2005

Re: pf_vsnprintf implementatnion of 'I', 'I32' and 'I64' prefixes for type specifiers

by Jonathan Wilson

Question: Why doesnt WINE just have a complete implementation of the core "printf" logic itself? With all the differences between "printf" as defined in ANSI C and as is present on the systems WINE runs on (i.e. linux, darwin, solaris, BSD etc) and "printf" as implemented by Microsoft in their C Runtime library, it seems to me that it would make more sense to write a complete implentation of the core "printf" functionality instead of trying to make it "fit" onto whatever minimum set of functionality the target can be expected to have and hacking the rest on top of that. Although I dont know much about the differences between printf & friends on linux, windows, solaris etc etc so I could be way off base here :)

Aug. 2, 2005

getting the path to .wine

by Ivan Leo Puoti

What's the best way/way usually used in wine to get the full path to .wine? Ivan.

Aug. 2, 2005

Re: MSXML3: initial implementation based on libxml2

by Andreas Mohr

Hi, On Tue, Aug 02, 2005 at 05:39:48PM +0900, Mike McCormack wrote: > > This patch is a start on msxml3. More implementation to follow. Nice! I need that one... Andreas

Aug. 2, 2005

Re: WLDAP32: tests for ldap_err2string{A,W} and LdapMapErrorToWin32

by Hans Leidekker

On Tuesday 2 August 2005 06:52, Dmitry Timoshkov wrote: > > +static const char* WLDAP32_error[] = { > > + "Success", > > This test won't work on a not english locale once somebody adds > translations for another language. You either need to prevent > the test from running on locales different from english, or find > another way how to test returned by LoadString error strings. The test was perfectly OK before you talked me into doing the errors as resource strings ;-) But you are right, and there already is a German translation so I guess I'll have to fix it up. -Hans

Aug. 2, 2005

test case demonstrating PeekMessage give up timeslices

by Oliver Mössinger

Hi wine-devel, attached i have a test case whitch demonstates the differece between Windows and wine. There is also a sample program 'TEST.CPP' attached. On Windows XP - Start 'test.exe' from a dos-box... you see some FAST counting integers - Start a other (loop.pl) program witch consumes mutch cpu time. - the output of 'test.exe' is slower but FAST On wine - Start 'test.exe' from a dos-box... you see some FAST counting integers - Start a other (loop.pl) program witch consumes mutch cpu time. - the output of 'test.exe' is very slow This different behavior starts from wine version 20041201. The version before was ok. I have no patch and it would be nice if someone can write a patch to fix this. Thanks Oliver Mössinger

Aug. 2, 2005

Re: ownerdraw paint recursion in listbox

by Alexander Yaworsky

Dmitry Timoshkov wrote: > > While browsing my old not answered e-mails I've found this one. Does > the attached patch help? It restricts the control to draw outside of > the item rect but not the whole control rect as it currently does. > No, it does not help.

Aug. 2, 2005