- Wine-devel - list.winehq.org

RE: wpp
by Patrik Stridvall 08 Dec '02

08 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

Failure running 1998-era online manual
by Dan Kegel 07 Dec '02

07 Dec '02

I grabbed Wine-20021125 and built it on my Red Hat 7.3 box. Its behavior installing http://enduser:enduser(a)bbs.toshiba.co.uk/file/area128/S22D95UM.ZIP (the Windows 95 version of the user manual for my 1998-era Toshiba laptop) seems much improved over May/June 2002 wine, cool! However, running the app does no better. To run the app, you do cd 'c/Program Files/DOC' wine edoc32.exe TOSHIBA.M14 On Windows, it works fine. On Wine, it displays a splash screen, then exits. Here's a partial log: 08074e50:Ret kernel32.lstrcpyA() retval=406d2dc0 ret=01643c25 08074e50:Call winmm.mmioInstallIOProcA(2034314d,01643b30,10010000) ret=01643c54 trace:mmio:MMIO_InstallIOProc (540291405, 0x1643b30, 10010000, 1) fixme:mmio:MMIO_InstallIOProc Global procedures not implemented ... 08074e50:Ret winmm.mmioInstallIOProcA() retval=01643b30 ret=01643c54 08074e50:Ret PE DLL (proc=0x1641030,module=0x1640000,type=1,res=0x1) retval=1 ... 08074e50:Starting process C:\Program Files\DOC\edoc32.exe (entryproc=0x41c9b0) ... 08074e50:Call winmm.mmioOpenA(406d2cfc "+init",00000000,00000000) ret=00405fd6 trace:mmio:MMIO_Open ('+init', (nil), 00000000, 1); 08074e50:Call ntdll.RtlAllocateHeap(40380000,00000008,0000005c) ret=40c3e59b 08074e50:Ret ntdll.RtlAllocateHeap() retval=403c42b8 ret=40c3e59b trace:mmio:MMIO_ParseExtA ("+init") err:mmio:MMIO_ParseExtA + but no . in szFileName: "+init" It sounds like mmioOpen's documentation at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/m… is incomplete; it doesn't describe what the function does when there's no filename, just a +init, in the string passed to mmioOpen. I tried patching the source for MMIO_ParseExtA to assume an extension of "" in this case, but it didn't help, the program still exits. Any suggestions? - Dan

2 2

Language search order
by Shachar Shemesh 07 Dec '02

07 Dec '02

From dlls/kernel/locale.c if (GetEnvironmentVariableA( "LC_ALL", buf, sizeof(buf) ) || GetEnvironmentVariableA( "*LC_CTYPE*", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LANGUAGE", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LC_MESSAGES", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LANG", buf, sizeof(buf) )) Hi list, I'm trying to understand the above line of code. It would appear to me that default_lcid is used for "find resource". The manual for locale says: LC_CTYPE This changes the behaviour of the character handling and classi- fication functions, such as isupper() and toupper(), and the multi-byte character functions such as mblen() or wctomb(). Specifically, I'm looking into setting LC_CTYPE to "he_IL" so I can type Hebrew characters, while setting "LC_MESSAGE" to "C" so the messages programs issue are in English (or whatever their local setting says). It seems to me we may want to support independant settings of the two. I realize that there are places where we may want to use the information from LC_CTYPE (WideCharToMultiByte comes to mine), but I believe that we should use a different setting for that so we can allow Unix users independant control over both settings. Thoughts? Shachar

1 0