December 2002 - Wine-devel - list.winehq.org

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> In other words, preprocessing is like 10% of compilation, so > it can't be unbearably slow. Something else is wrong. Perhaps. It was quite a few years ago I did it. I just remember abandoning the idea of using "gcc -E" for preprocessing in winapi_check because of horrible a speed slowdown. > > The FSF claims that you forking and calling a GPL:ed executable > > is the same as linking with a GPL:ed library and calling > > functions in that library. > > Do you have a reference to this? Never heard of something like > this before. It was dicussed extensively during the great licensing war. http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem The main part is this I think: < The difference between this and "incorporating" the GPL-covered software < is partly a matter of substance and partly form. The substantive part is < this: if the two programs are combined so that they become effectively < two parts of one program, then you can't treat them as two separate programs. < So the GPL has to cover the whole thing. In the case of wrc it is pretty clear that "gcc -E" will one of the parts of the whole program and thus wrc must be under the GPL (or compatible with it). While, as I said earlier, this is a not a direct problem for a LGPL application, we have as I said I policy not to "link" with GPL:ed applications.

1 0

Re: Janitorial Projects -- conformance tests --recruiting volunteers
by David Miller 09 Dec '02

09 Dec '02

As someone only attempting to learn C I am looking for some other way to contribute something to wine. I have WinXP home on my laptop, so I could do WinXP tests if you can give me more information on what needs to be done. Dave

1 0

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> On December 8, 2002 03:27 pm, Patrik Stridvall wrote: > > It is faster. Mucher faster. Using cpp/gcc -E needs to > > fork a new process for example. > > What?!? You got to be kiddin', right? If you can measure > any difference in build time between the forking gcc -E > and using wpp I'll give you a dollar in small change. I personally have only tried piping every file parsed by winapi_check through "gcc -E" and it is was unbearably slow, so I removed the code. The parsing it itself can't possibly taken that extra time. So I'm pretty sure that I can measure it, yes. However, the big question is not if it is measuarable but rather if it is worth the cost or not. So, yes, I agree that we need to discuss the question. > On Linux process creating is extremely fast, and we do > fork 1000s of processes while building wine, this sort > of argument is just silly. Well, it is not really the "fork" in it self that is the problem it is the overhead of loading and initializing gcc and that sort of things. > By the same rationale I suggest having a complete copy > of gcc, ld, nm, and whatever tools we use while building > wine. It is not primarily a question of having a complete copy of whatever. It is a question of having whatever accessable as functions in a library to avoid a lot of unnessary overhead. It would be very nice it something made a GNU C compiler library to support among other things only running the preprocessor. > So no, if speed is the only argument, I say we get rid > of it: it's not worth maintaining a fraction of all that > additional code. 1. Depending on "gcc -E" will make it harder to port wrc to Windows. 2. It might be less flexible (not sure though). > > And then of course using "gcc -E" would possibly cause > > a GPL violatation. Not that it would matter very much > > if wrc and friend were GPL:ed. > > WTF are you talking about?!? How did you figure this one > out? Really, this is simply false, you can fork GPL > programs all you want, and cause no GPL violation. The FSF claims that you forking and calling a GPL:ed executable is the same as linking with a GPL:ed library and calling functions in that library. This is of course absurd and would IMHO opinion nether fly in a court of law but still.... Sure wrc and friend are under a GPL compatible license (LGPL), so it wouldn't be a direct violation. However Wine has a policy that we do not link with GPL:ed libraries regardless in order to avoid possible problems for companies working with Wine so no we really can't make wrc depend of "gcc -E".

3 2

Re: Wine/FF7 midi help request
by Jeff Smith 08 Dec '02

08 Dec '02

>From: Robotech_Master <robotech(a)eyrie.org> > >On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a >discussion about midi in WINE in which FF7 was mentioned): > > > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > > modification to wine at all, and the OSS emulation of ALSA makes the > > thing transparent to WINE. > >Can you, or someone, please let me know how to set up wine to use >this? I'm running Debian Linux; these are the versions of timidity >and wine that I have: > >ii timidity 2.11.2-1.3 Software-only MIDI sequencer. >ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) This is something I would not mind knowing myself. It's not too high a priority for me though as I have SoundFonts working on my SBLive now. >For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a >Soundblaster live card. > >On the FF7 config program, it gives me the choices > > Wine OSS midi out (#0) - disabled > EMU10K1 midi This looks like what I would get from the OSS driver - emu10k1. The module name for the ALSA driver is snd-emu10k1. The choices I would expect from ALSA's OSS emulation would be something like: Emu10k1 MIDI 0-0 Emu10k1 Port 0 Emu10k1 Port 1 Emu10k1 Port 2 Emu10k1 Port 3 >Under "midi data" it gives me the choises > > General midi > Soundfont midi (Creative AWE32/AWE64) > Yamaha XG midi I would imagine this should stay on General midi unless you are *sure* it needs to be on another selection. >No matter what I try, in whatever combination, I get "Error opening >device" and the wine console says > >fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 >fixme:dsound:IDirectSoundImpl_SetCooperativeLevel >(0x403ab930,0001003c,3):stub > >Can someone help me out--or point me at somewhere else I can find >help? Try running it like this ... wine -debugmsg +winmm,+midi,+msacm program_name.exe ... and send the output. -- Jeff S _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

3 3

RE: wpp
by Patrik Stridvall 08 Dec '02

08 Dec '02

> Anyone remembers why we need our own cpp implementation, > instead of simply using cpp/gcc -E? It is faster. Mucher faster. Using cpp/gcc -E needs to fork a new process for example. And then of course using "gcc -E" would possibly cause a GPL violatation. Not that it would matter very much if wrc and friend were GPL:ed. Obviously any GPL claim would be absurd as we discussed to death in the great licensing flamewar but still.

2 1

Re: Intel 8x0 and ALSA sound driver
by Nikolay Stefanov 08 Dec '02

08 Dec '02

On Sunday 08 December 2002 5:39 pm, Eric Pouech wrote: > which I'm say is a bad idea. the Alsa driver should report all available > drivers, and you should not be forced to define the one you want. > To be more correct, the notion of "default device" exists under windows, > but has to be handled at the wave mapper level, not at the driver level. Aha, got it. I doubt that I will be able to implement this, so I might just file it as a bug report. > that's why I say we have to remove those assertions and do proper error > handling instead > btw, if ALSA fails with an assert it's either: > - a bug in the ALSA driver > - a bug in the ALSA library > => those should be fixed (as ALSA isn't 1.0 yet, there's no need to work > around it in wine code) I had a look at mplayer code and it is structured in a completely different way than winealsa for the mmap case. I'm looking at wodPlayer_WriteMaxFrags, btw. This leads me to believe that the way wine does it is off, and it's not a driver issue... I'll try to tinker a bit with it and see whether I have any success. Nikolay

1 0

Loading Autorun.inf on CD's
by Dustin Navea 08 Dec '02

08 Dec '02

Hey guys, I was browsing through the forums on franksworld.net and noticed this post: http://www.frankscorner.org/wineforum/viewthread.php?tid=158 Now that got me thinking, wine doesnt have any method to check .inf files right now and load an installer if it finds one on a CD. I was wondering, what do you guys think it would take to get that supported? I know that we would probably have to associate .inf files with wine and/or have some sort of a wine cd detector that actively monitors cd's for autorun files, but what would need to be added to wine itself to parse an autorun file, so that we could create the loader later? -Dustin

3 5

Re: what to do with include/wine/obj_base.h?
by Jeff Smith 08 Dec '02

08 Dec '02

>From: Ove Kaaven <ovehk(a)ping.uio.no> >On 6 Dec 2002, Alexandre Julliard wrote: > > > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > > > 4) make widl not use macros at all, but emit full C and C++ >definitions > > > directly (this is what midl.exe does, it seems) > > > > I'd say this is the way to go if it's not too painful, it seems to be > > the most flexible. In any case obj_base.h has to go, so if we keep the > > macros they have to be put inside one of the standard headers, which > > wouldn't be very clean. > >We may have to keep the macros anyway, there are headers that use them >that can't be generated from IDL, like the DirectX headers. I suppose they >could be converted to using the MS-style objbase.h macros by perl scripts >or by rewriting them from api headers or something, but someone else would >have to take on that task, I think. > >But I'll try to add a widl header generation mode that don't use macros, >then. I don't really care whether the ICOM_ macros go or stay in the current form, but if they stay, they should at least be corrected in the following sense. Presently, a typical macro in obj_base.h is #define ICOM_METHOD4(ret,xfn,ta,na,tb,nb,tc,nc,td,nd) \ public: virtual ret CALLBACK (xfn)(ta a,tb b,tc c,td d) = 0; Note that we have na, nb, ... on the 'left' matching with a, b, ... on the 'right'. Not that this causes problems, it's just that it isn't right. And if the stuff gets stripped, it is a moot point anyway. If anyone thinks it is worth any effort, I can easily create a patch. -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

2 1

Re: wine/dlls Maketest.rules.in Makedll.rules.in
by Eric Pouech 07 Dec '02

07 Dec '02

Alexandre Julliard a écrit : > > ChangeSet ID: 6522 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/06 13:51:20 > > Modified files: > dlls : Maketest.rules.in Makedll.rules.in > > Log message: > Build test programs as part of the normal build. > > Patch: http://cvs.winehq.com/patch.py?id=6522 Alexandre, this patch is broken when building from a clean tree: - when building the tests for ntdll we need to link to kernel32 (for a cui program) which isn't built at this time - IMO, building the tests programs at the same time as the modules is a bad idea. we don't impose that tests for DLL x only depends on DLL x and DLLs built (in the wine dependency order) before x. - so, either we back up to the previous mode, or we add dependencies on test building as well A+

2 1

tools/wrc/wrc.c portability breakage
by Gerald Pfeifer 07 Dec '02

07 Dec '02

The following patch broke portability of tools/wrc/wrc.c: revision 1.18 date: 2002/12/06 19:49:36; author: julliard; state: Exp; lines: +78 -10 Dimitrie O. Paun <dpaun(a)rogers.com> Make wrc command line compatible with windres. 1) getopt() is supposed to to come from <unistd.h>, and <getopt.h> is a non-standard header. 2) getopt_long() is non-portable (and does not exist on FreeBSD, for example). The man page for getopt() clearly shows that, BTW: #define _GNU_SOURCE #include <getopt.h> Would you mind fixing this problem? Thanks, Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

2 4