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

Re: Problem in dlls/ddraw/dsufrace/main.c

by Lionel Ulmer

> found=NULL; > for (surf = This->attached; surf != NULL; surf = surf->next_attached){ > ... // surf is not modified into that > if (...) found=surf; > } > if (found == NULL) { > TRACE("Did not find any valid surface\n"); > return DDERR_NOTFOUND; > } > Well, we loop on 'surf' (which will be NULL at the end of the loop) and test 'found' (that won't be NULL if a matching surface was found). So no, I do not see any problem here. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 7, 2003

Re: Wine Fun v0.3

by Steven Edwards

--- Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote: > If it hasnt already said : > Some 'qt under windows' port is already in progress, see the guys from > kde-cygwin.sf.net. Yeah I am aware of Donald Becker and others port for kde-cygwin and LibW11/cygwin a while back but this of course was using X11 2 GDI translation. There was another one where the guy converted the MS_VC makefiles to Mingw makefiles and built QT native but I dont remeber if troll tech accepted his patches or not. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 7, 2003

Re: DirectSound and i810 soundcards

by Eric Pouech

> Another thing i > wonder about is whether Windows lets you play 11kHz sounds with > WAVE_FORMAT_DIRECT using winmm and an i810 soundcard. If not then my > winmm test is incorrect, and if yes then I have to wonder what > WAVE_FORMAT_DIRECT really means. So if someone can send me these results... well, it may also depends on who is in charge to "understand" the WAVE_FORMAT_DIRECT: - from what I understand from the doc (I didn't actually tested under windows), WAVE_FORMAT_DIRECT tells winmm not to perform frequency modification if the driver doesn't support the requested format - it doesn't state that the driver shouldn't do any transformation by itself A+ > I don't know why the mmap fails. I would tend to think this is a > limitation or bug of the Alsa driver since it works with the OSS driver. do you mean - wine OSS driver on a Linux OSS emulation on ALSA driver - or wine ALSA driver on a Linux ALSA driver the later could have still quite a few issues anyway, there are also a couple of issues we may have to look after: - the driver interface used always comes from a single audio driver (even if multiple audio drivers are installed in wine) - trying to get rid of wine's DRV_QUERYDSOUNDIFACE... a bit more hacky... one solution would be (as MS does) to install in the registry all the required settings for our sound drivers (including a guid for each wave out, wave in... so that we could bind dsound to each of those drivers) - getting rid of WAVE_DIRECTSOUND... I didn't look at all the details... but, wouldn't the semantics of open&setformat methods of the IDsDriver be enough for that A+ -- Eric Pouech

Jan. 7, 2003

Re: DirectSound and i810 soundcards

by Francois Gouget

Ove Kaaven wrote: > On Mon, 6 Jan 2003, Francois Gouget wrote: [...] > Note that test results from Windows XP won't be very useful for this; > under XP, dsound primary buffers doesn't map directly to the sound > hardware any more, according to MSDN. If you create and use a dsound > primary buffer under XP, it will just become another stream sent to XP's > kernel-mode sound mixer, before it gets to the hardware. Ah that probably explains some results I've seen then. Thanks. >>I don't know why the mmap fails. I would tend to think this is a >>limitation or bug of the Alsa driver since it works with the OSS driver. > > ALSA has resampling features. If you open the sound device at e.g. 11kHz, > then ALSA's OSS emulation will, instead of telling you that the chip is > 48kHz, install a resampling filter to convert from 11kHz to the hardware's > required 48kHz. Unfortunately, that filter gets in the way of direct > access, making an mmap fail. (In WineX we test mmap on a range of common > frequencies to work around this.) Ok. That makes sense. That's sort of the opposite direction of the DirectSound patch I sent to wine-patches (and which just got applied). The annoying thing is that the mmap, the device format bubbling up and the CreateThread are all in different places :-( Oh well, I'll try to come up with something. It seems hacking things to make mmap succeeds is the simplest approach. But what's the best approach? 1. if we tweak things so that the mmap call succeeds then Wine will be making the resampling. And Wine is not really good at that and tends to introduce audible distortion. It probably doesn't matter if you start from an 8kHz signal but if you're playing a 44kHz sound... 2. if we tweak things so that the CreateThread is done, then the resampling will be done by Alsa (or whichever back-end) which will presumably do it much better than us. howeve rin that case we have to make the almost never used case work and I'm not sure how well it would work anyway (I'm concerned about skips/cracks/pops). To make 1. cleaner maybe we should have a Wine-specific message that asks the backend to return the formats supported by the device, i.e. for OSS returning an exact translation of the value returned by SNDCTL_DSP_GETFMTS. Then if our msacm gets improved to the Jack sound format conversion library we're golden... (what's the status of this btw?) -- Francois Gouget fgouget(a)codeweavers.com

Jan. 7, 2003

Re: wxWindows: it's official!

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > That's the user's choice. We need to support io.h, mingw has it, cygwin > has it. If we provide it only in msvcrt, we force everybody to use msvcrt, > which is not right IMO. IMO it is right. I would say this is a cygwin bug; cygwin is supposed to be Unix compatible, and under Unix access() is in unistd.h. So if the app needs access() it should include unistd.h; if it needs the other functions from io.h then it has to use msvcrt because they don't exist in the Unix libc. -- Alexandre Julliard julliard(a)winehq.com

Jan. 7, 2003

Re: wxWindows: it's official!

by Francois Gouget

On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: > Sorry about my previous attempt, I've pressed Send by mistake. > And I've learned you can't stop KMail from sending... :) > > On January 7, 2003 02:09 pm, Francois Gouget wrote: > > include/io.h > > include/msvcrt/io.h > > > > That seems like an include order nightmare. Furthermore your header only > > contains: > > int access(const char *__path, int __amode); > > It's a big problematic, but not much. winegcc get this right anyway, > and I can't see how it can be a problem: if you use msvcrt, you first > have to include those headers. If not, they are not in the search path, > so they don't exist. What scenario to you forsee where this can be a > problem. The case where a developper mistakenly does: -I/usr/include/wine -I/usr/include/wine/msvcrt And then wonders why things don't compile... [...] > Thing is, the cygwin io.h contains only these definitions: > > extern long get_osfhandle(int); > extern int setmode (int __fd, int __mode); > int access(const char *__path, int __amode); Yes, but Mingw applications are Windows applications and thus hey use Windows paths (c:\Windows\wininit.ini) and link with a C library that understands these Windows paths. But that will definitely not work in Wine unless you link with msvcrt. There's no way around that. > That's the user's choice. We need to support io.h, mingw has it, cygwin > has it. If we provide it only in msvcrt, we force everybody to use msvcrt, > which is not right IMO. For Cygwin the situation is different (symetrical to the Winlib one in fact). The applications are Unix applications that use Unix paths (/windows/wininit.ini) on Windows and thus have to link with the Cygwin C library rather than the system 'native' C library (msvcrt). (or crtdll, but no one on Windows uses crtdll) For exactly the same reasons, Winelib applications, using Windows paths (c:\Windows\wininit.ini) on Unix have to link with the Wine C library (msvcrt) rather than the native one (glibc) in order to call functions with these paths. [...] > Since program not using msvcrt expect only these funtions, > that's what we need to provide. I don't know what get_osfhandle(), > and setmode() are (they are not standard Unix functions), I've > added included only access(). They are both implemented in msvcrt. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Jan. 7, 2003

Re: Problem with interrupt vector

by Sylvain Petreolle

tried to install it, says "corrupt installation detected". --- Gustavo Junior Alves <alves(a)coslinux.com.br> a écrit : > Is a goverment program for incoming taxes. Appear to be made in > Delphi. > > The log from app (wine --debugmsg +int) is: > > err:ntdll:RtlpWaitForCriticalSextion section 0x400f3ac8 > "../../scheduler/syslevel.c: Win16Mutex" wait timed out, retrying (60 > > sec) tid=08074ff8 > trace:int:WIN87_fpmath (cs:eip=42f:1155 es=23f bx=0000 ax=0000 > dx==0002) > trace:int:WIN87_fpmath (cs:eip=42f:1163 es=23f bx=0003 ax=1168 > dx==042f) > fixme:toolhelp:InterruptRegister16 (0000, 0x24700ba), stub. > wine: Unhandled exception, starting debugger... ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 7, 2003

Re: wineboot wininit patch 1

by Shachar Shemesh

Andreas Mohr wrote: >On Tue, Jan 07, 2003 at 08:19:19PM +0200, Shachar Shemesh wrote: > > >>Changelog >>Shachar Shemesh <winecode(a)sun.consumer.org.il> >> >>programs/wineboot/wineboot.c >> >> * Added a print to indicate to user that installation is done. >> >> >Hmm, I'm not sure whether that's an entirely good idea. >It's probably more flexible to have the script invoking wineboot >print such a message instead. >(some people might want to have "hidden" execution of wineboot configured) > >But OTOH you could also solve that issue by configuring wineboot >to be silent in such a case, so maybe having such a message is a >good thing after all. > >Andreas Mohr > > > The reason I put it in is because wininit.exe has that message under the exact same circumstance. When I say "that message", I actually a less sarcastic one, but nevertheless. In any case, the initiating message was already in the code, I just forgot the message saying "wer'e done". Worst case, we'll add an option to turn that silent. I think that's the proper place for it. Sh.

Jan. 7, 2003

Re: getting started

by Francois Gouget

On Tue, 7 Jan 2003, Dimitrie O. Paun wrote: > On January 7, 2003 03:39 am, Francois Gouget wrote: > > 1. get the sources to a Linux machine > > 2. run winemaker on the sources to generate Makefiles > > We should modify winemaker to use winegcc. There's now > a lot of (bad) duplication between winemaker, and winegcc, > like wrapper support, linking, etc. Actually there is not all that much duplication and I think winemaker and winegcc have different purposes: * winegcc & co The assumption is that the user already has Mingw makefiles that work. So their goal is simply to emulate the tools that come with the Mingw environment. * winemaker The assumption is that you have a Windows application (complete with CR/LF), most likely based on Visual C++ and thus with no suitable makefiles. So winemaker's goal is to quickly generate suitable Makefiles that will build Winelib applications/dlls from what it's given and fix the simple issues in the source (CR/LF, #pragmas). The backend is somewhat secondary. Currently the Makefiles are modelled after the Makefiles used to build the programs in Wine. From there we can go into two directions for the backend: 1. make the Makefiles more similar to those of the Wine programs. Alexandre told me he wanted the winemaker Makefiles to match and reuse more stuff from Wine. Part of this goal was to move lots of autoconf stuff to a .m4 file and to use that in both Wine and Winemaker generated stuff. There is some work to do there to make this feasible because Winemaker has to deal with the possibility that there may be multiple .exe/.dlls to build from a single Makefile (so you cannot define a single 'MODULE=' variable at the top of the Makefile) whereas this is never the case in Wine. 2. we can modify Winemaker to generate Mingw makefiles (does that rule out using autoconf?) and assume that a 3 line change will turn them into Winelib makefiles (or the other way around). Actually, has anyone written a .dsp to Mingw makefile converter? Potentially we could do both: * modify the makefiles in programs/* to use winegcc & co * turn these Makefiles into Mingw makefiles * make it so as much of this as possible can be shared with Winemaker * have Winemaker generate Mingw compatible makefiles based on the model above > Moreover, having > winegcc handle the linking details automatically, we > (1) shield the users from all that nastiness, and > (2) retain more freedom on changing things in the build process. The user is already somewhat shielded from these issues since he does not have to write the Makefiles. However each time the build process changes the Makefiles break so if winegcc & co can help with that it would be nice. [...] > My Perl knowledge approaches zero asymptotically, so I can't > quite do this myself, but I am willing to help on it with > what's needed. The problem for me is time :-( -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Jan. 7, 2003

Re: wxWindows: it's official!

by Dimitrie O. Paun

On January 7, 2003 03:00 pm, Francois Gouget wrote: > For exactly the same reasons, Winelib applications, using Windows paths > (c:\Windows\wininit.ini) on Unix have to link with the Wine C library > (msvcrt) rather than the native one (glibc) in order to call functions > with these paths. But this is missing the point. What you are saying is that we should not allow people to link to the native libc, because you think that the msvcrt behavior is more correct. I beg to differ. If people choose to ling to glibc, they must be aware the apps will not work with Windows paths. It's their choice. -- Dimi.

Jan. 7, 2003