November 2003 - Wine-Devel - list.winehq.org

Re: new old winetests

by Alexandre Julliard

Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > Is not > > #ifdef _WIN32 > # include <io.h> > # include <process.h> > #else > # include "config.h" > # include "wine/port.h" > # define mkdir(d) mkdir (d, 0777) > #endif > > an acceptable workaround? This should be compilable even > with MSVC after all, and Dimi has already invented all the > magic needed for a successful make winetests_cross.exe. I'm not sure why you don't want to use the normal mechanism for that. Dimi's patch cannot do the right thing, as you have noticed yourself, since it doesn't use the right config.h; and I don't think we want to add such #ifdefs to all the programs. -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2003

Dropped wildcards patch

by Shachar Shemesh

Hi Alexandre, Just wondering whether there was a reason that the patch at http://www.winehq.org/hypermail/wine-patches/2003/11/0339.html was not commited. My understanding of the ensuing debate was that it was acceptable. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...

Nov. 30, 2003

Direct Sound problem

by Kris 'Spike' J

Hello there, I get an error when starting a voice communication tool that uses dsound: err:win32:PE_fixup_imports No implementation for DSOUND.dll.12 imported from C:\Programme\Ventrilo\Ventrilo.exe, setting to 0xdeadbeef a guy called TD from #winehq @ irc.freenode.net told me to mail this to the list. Done. Spike :>

Nov. 29, 2003

Re: debugger problems

by Chris Morgan

Still isn't working with build from todays cvs. Is this patch in there? Chris On Saturday 29 November 2003 05:20 am, Eric Pouech wrote: > Chris Morgan wrote: > > Just rebuilt using 2.95 by changing the symlink /usr/bin/gcc to point to > > /usr/bin/gcc-2.95 and it still doesn't appear to be working. Did: > > > > make clean > > ./configure&&make depend&&make > > make install > > > > This enough to ensure that everything rebuilt? It looked like it. > > Running debian unstable here. > > ok, so it might not be compiler related. > There's a last fix to debug.l which has been contributed which might > help too. Could you give it a spin. > > A+

Nov. 29, 2003

Re: Splitting out shared Win16/Win32 code

by Steven Edwards

Hello Capser, --- Casper Hornstrup <chorns(a)users.sourceforge.net> wrote: > Dlls/winmm/lolvldrv.c has a function (MMDRV_Message) shared by the > Win16 and the Win32 implementation of mmsystem. Since it is shared > by both mmsystem.dll and winmm.dll, all Win16 APIs used in the shared > functions will be imported by the Win32 implementation (winmm.dll) > also. On ReactOS no such APIs exist so the library will not load. Yup there are a few places where you will see this problem, Winmm, comdlg32 and some spots in User and GDI. The User and GDI parts are not that big of a deal for the ReactOS port though. We can pick and chose code snips as needed. > I see two immediate solutions: > > 1) Check with a preprocessor variable and not compile the Win16 part > of the shared Win16/Win32 functions when --disable-win16 is > specified. I like this method but it adds a few more Ugly #ifdefs to the code. We need to keep these changes as small as possible. > 2) Duplicate the shared code in a Win32 specific file and Win16 > specific file. It submitted a patch for this problem a while back in comdlg32 and it went to the silent void that is Alexandres patch rejection que.... http://www.winehq.org/hypermail/wine-patches/2003/10/0265.html > How should it be handled? Alexandre? Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

Nov. 29, 2003

Splitting out shared Win16/Win32 code

by Casper Hornstrup

Dlls/winmm/lolvldrv.c has a function (MMDRV_Message) shared by the Win16 and the Win32 implementation of mmsystem. Since it is shared by both mmsystem.dll and winmm.dll, all Win16 APIs used in the shared functions will be imported by the Win32 implementation (winmm.dll) also. On ReactOS no such APIs exist so the library will not load. I see two immediate solutions: 1) Check with a preprocessor variable and not compile the Win16 part of the shared Win16/Win32 functions when --disable-win16 is specified. 2) Duplicate the shared code in a Win32 specific file and Win16 specific file. How should it be handled? Casper Hornstrup

Nov. 29, 2003

Re: sysparams: slight optimisation for IDA 3

by Andrew de Quincey

> Sorry to bother you again, but probably the comparison statement > needs to be reverted... Doh! You're right. Fixed in yet another patch. Gah As for bothering.. no problems! The sooner I know what coding styles etc are acceptable the better.

Nov. 29, 2003

Re: SystemParametersInfoA very slow

by Andrew de Quincey

On Saturday 29 November 2003 17:32, Peter Berg Larsen wrote: > On Fri, 28 Nov 2003, Andrew de Quincey wrote: > > Initially, I've been trying to get Datarescue IDA working... the actual > > application works fine, but certain operations take a long time to > > complete (e.g. the open file dialogue takes 20 seconds to appear on my > > 2GHz machine). > > > > Is anyone else working on this area right now? If not, I'll get going on > > doing something properly. > > I am, but I have taken a different approach: The console version idaw.exe > is in my experience 5-10 times faster (analizing) than the graphical > version (idag.exe). > > My approach have been to patch the console as the output from the console > is somewhat poor as it is shown in ascii. Yesterday I sent some patches > that makes the console support unicode and allows the xterm to be resized. > I am running ida in 132x43 which is nearly perfect except for some color > problems. Cool! Unfortunately I'm kinda addicted to the GUI version now... (though the console version was good in its day) but its good to know other people are looking in this. One thing I noticed was if you hid all the views in the GUI version, the analsis speed shoots way up (though its still not as fast as it is under windows). I'm in the middle of adding some simple profiling support to the wine +relay trace mode so I can track down exactly what causes this.

Nov. 29, 2003

Re: sysparams: slight optimisation for IDA 3

by Dmitry Timoshkov

"Andrew de Quincey" <adq_dvb(a)lidskialf.net> wrote: > Version 3 > + spi_idx = SPI_GETICONTITLELOGFONT; > + > + if (!spi_loaded[spi_idx]) > + { > + memcpy(lpLogFont, &iconTitleLogFont, sizeof(LOGFONTA)); > + break; > + } Sorry to bother you again, but probably the comparison statement needs to be reverted... -- Dmitry.

Nov. 29, 2003

Re: SystemParametersInfoA very slow

by Peter Berg Larsen

On Fri, 28 Nov 2003, Andrew de Quincey wrote: > Initially, I've been trying to get Datarescue IDA working... the actual > application works fine, but certain operations take a long time to complete > (e.g. the open file dialogue takes 20 seconds to appear on my 2GHz machine). > Is anyone else working on this area right now? If not, I'll get going on doing > something properly. I am, but I have taken a different approach: The console version idaw.exe is in my experience 5-10 times faster (analizing) than the graphical version (idag.exe). My approach have been to patch the console as the output from the console is somewhat poor as it is shown in ascii. Yesterday I sent some patches that makes the console support unicode and allows the xterm to be resized. I am running ida in 132x43 which is nearly perfect except for some color problems. Peter

Nov. 29, 2003