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

Re: wxWindows: it's now official (almost)

by Dimitrie O. Paun

On January 8, 2003 03:09 pm, Nerijus Baliunas wrote: > What do you get - windows .dll or linux .so? For what? The wxwin libs? I get .a files, that get statically linked in. > If the latter, I could > try to compile Mahogany with it, it would be cool! Does it have a mingw port? If it builds under mingw 2.0, it should build under Wine, no problem. I can give you a hand if you need help. A good addition to the Winelib page: http://www.dssd.ca/wine/Winelib-Apps.html -- Dimi.

Jan. 8, 2003

Re: Sound driver autodetection

by Z_God

Op woensdag 8 januari 2003 20:51, schreef Eric Pouech: > Things are a bit more complicated for aRts vs OSS for example where you > get audio mixing/sharing with aRts and better RT capabilities (esp. for > games) with OSS. I'm currently playing StarCraft with the aRts driver and it seems to work pretty good. Only the movies play a little slow, ingame everything is ok. (I haven't tried any other driver yet so I don't know how the movies run with the ALSA or OSS driver). Setting aRts as default in case aRts is detected probably wouldn't cause any problems with most apps. Games that really need the ALSA or OSS driver could use an AppDefaults section.

Jan. 8, 2003

Re: html browser for wine (khtml)

by Dimitrie O. Paun

On January 8, 2003 02:11 pm, Hetz Ben Hamo wrote: > Whats the difference? now you don't need QT, so license wise - it's > kosher ;) But I guess it's still C++, no? I'm not sure if Alexandre will accept C++ dlls... -- Dimi.

Jan. 8, 2003

Re: wxWindows: it's now official (almost)

by Nerijus Baliunas

On Sat, 4 Jan 2003 13:57:37 -0500 "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Last night I had nothing better to do than to cleanup my wxWindows > patch. The entire thing is less than 500 lines! This says quite a > few things about the maturity of our headers. What do you get - windows .dll or linux .so? If the latter, I could try to compile Mahogany with it, it would be cool! Regards, Nerijus

Jan. 8, 2003

Re: Mac OS X/Darwin port of Wine

by Michael F. March

>>I think I will investigate the Linux compatible angle for a bit. I've >>already had some interest from some hard core Linux kernel hackers >>(although they seem pretty convinced Mach was the wrong solution, it is >>here to stay and at least the microkernel approach means we can neatly >>have multiple environments). > > > I think this is the right way to go. > > Once you can run Linux/x86 application like Mozilla with acceptable > performance in Bochs on MacOS X you should be able to run applications > such as Word in Wine with similar performance. Similarly, once Linux/x86 > Gimp runs with acceptable performance in Bochs on MacOS X you can run > Photoshop in Wine with similar performance (well, once it runs in Wine > that is). Wine should be able to achieve greater performance than Bochs on the same system configuration. IIRC, WABI sent only 25% of its cycles emulating X86 instructions, the rest of the API calls were implemented and executed in native mode. In Bochs case, it spends 100% of its time emulating X86 instructions. -- <admiral> Michael F. March ----- march(a)indirect.com Ph: (602)410-1780 ---- Fax: (602)296-0400 P.O. Box 2254 ---- Phoenix, AZ 85002-2254 "Seriously" - HSR

Jan. 8, 2003

Re: Sound driver autodetection

by Eric Pouech

chrismorgan(a)rcn.com wrote: > So the external tool would try to load each driver and put the detected one into the appropriate location in the registry? the tool(s) would need to: - detect all runnable sound drivers - let the user pick the one(s) he/she wants to run. it would have to detect that a wineoss and winealsa would in fact output to the same physical Linux device, so there's no need to install both of them. Things are a bit more complicated for aRts vs OSS for example where you get audio mixing/sharing with aRts and better RT capabilities (esp. for games) with OSS. - let also the user decides of the default driver (the one the mapper will open by default) - when this is decided, the registry should be populated accordingly but, this should also be part of a more generic user oriented configuration program, going much further than the pure audio driver configuration A+ -- Eric Pouech

Jan. 8, 2003

Re: Web CVS annotation

by Eric Pouech

Geoff Thorpe wrote: > * Eric Pouech (eric.pouech(a)wanadoo.fr) wrote: > >>sure, the main issue we have is that winehq runs cvsweb as the web cvs >>frontend, and cvsweb only supports annotation under the condition I >>posted (IOW, it doesn't implement the annotate feature - on WWW side - >>with cvs annotate). But you're right on the constraints we get. >> >>so either check if a newer cvsweb implements annotate with cvs annotate, >>or we hack cvsweb to get what we want/need... > > > There's all sorts of versions of cvsweb floating around, no doubt one of > them contains what you want. > > BTW: w.r.t. rw permissions on CVS for annotation functionality. Do you > run cvsweb (or whatever) on a slave *copy* of the CVS repository rather > than leaving any possible window of opportunity for the master > repository to get hit? I dunno. I lost track of it when the server got moved to CW. Jeremy Newman does know. A+ -- Eric Pouech

Jan. 8, 2003

Re: DirectSound and i810 soundcards

by Eric Pouech

> That's an interesting interpretation. How would one go about testing it > under Windows? you would have to load the MM driver by hand and directly send the messages to it however, depending on the Windows version you're using, interfaces may differ. > But maybe this is wrong and it should only report what > the *driver* can handle (possibly in software). > So for us this means wineoss should perform a strict conversion of the > mask returned by SNDCTL_DSP_GETFMTS to the Windows set of flags, with no > stereo/mono, 8/16 bit muddling. > > So with an i810 soundcard and the OSS driver we would only get > 48000x16x2, and with Alsa (accessed through OSS) we would get whatever > Alsa is able to convert to a format supported by the soundcard. except if we decide at the driver level to support more format... we could also decide that if OSS fails to open a driver (even with the wave direct flag set) to do the format conversion at the driver level IMO, that's just an implementation decision. we're not obliged to stick to the pure capability of the MM driver we rely upon. > Hmm, I guess this means we're still stuck with trying multiple formats > for mmap :-( the current dsound implementation however, already supports the format conversion anyway... so basically the implementation would be, in order of trials (for OSS): - mmap with required format - mmap with any available format on the soundcard (using the OSS capability would help here) - regular wavehdr playing >> 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 > > > These sound good but I don't really feel qualified enough yet to comment > on them (or be able to contribute much I'm afraid). since Ove jumped in to discuss the other issues, I found it appropriate to fire this part too ;-) A+ -- Eric Pouech

Jan. 8, 2003

Re: Mac OS X/Darwin port of Wine

by Francois Gouget

On Wed, 8 Jan 2003, Jim White wrote: [...] > I think I will investigate the Linux compatible angle for a bit. I've > already had some interest from some hard core Linux kernel hackers > (although they seem pretty convinced Mach was the wrong solution, it is > here to stay and at least the microkernel approach means we can neatly > have multiple environments). I think this is the right way to go. Once you can run Linux/x86 application like Mozilla with acceptable performance in Bochs on MacOS X you should be able to run applications such as Word in Wine with similar performance. Similarly, once Linux/x86 Gimp runs with acceptable performance in Bochs on MacOS X you can run Photoshop in Wine with similar performance (well, once it runs in Wine that is). The other way to go is the source-code compatibility route but that won't help you if the source for your target Windows applications is not available. Well, actually having that route well tested and mapped out would help once companies start considering whether it's worth porting their application, but that's indirect... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

Jan. 8, 2003

Re: Symbol stripping?

by Francois Gouget

On 8 Jan 2003, Mike Hearn wrote: [...] > The only other way would be to compile a little test app then run > objdump on it to figure out if stabs data was included, but testing the > GCC version would be faster. Or you could try to compile a small program with -gstabs+ and if the compile does not fail then it seems safe to use the flag. The main thing is that some people may want to use the new dwarf debugging format for one reason or another... (e.g. for using with the remote gdb feature). So this test should probably be overridable maybe using a --disable-gstabs or something. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

Jan. 8, 2003