Roger Fujii wrote:
ok... getting reasonable output, but now I have some questions.
First, it seems like wine can't find the audio codecs, though it seems to find the video ones. Is this a to-be-implemented or a bug and any clues on where to look?
which audio codecs ? you mean the ACM ones ? there are loaded as any drivers, looking for their names in system.ini drivers32 entries. to use the native acm codecs, you need something like:
[drivers32] MSACM.imaadpcm=imaadp32.acm MSACM.msadpcm=msadp32.acm MSACM.msgsm610=msgsm32.acm msacm.msg711=msg711.acm MSACM.trspch=tssoft32.acm msacm.l3acm=l3codeca.acm msacm.vivog723=vivog723.acm msacm.voxacm119=vdk32119.acm msacm.iac2=C:\WINDOWS\SYSTEM\IAC25_32.AX
(btw, video codecs are loaded the same way, so it's strange it doesn't work. any trouble somewhere with the .acm extension in the loader somewhere ??)
- For some unknown reason, the solaris version segfaults
when it tries to load win87em.dll, but the linux one doesn't. I presume that this is trying to load the fpu emulator, but I'm not certain. In any case, what controls the loading of this in the first place?
well it depends how the program was first compiled. there are options on windows to compile a program as: - without fpu (force always emulation) - only with fpu (no emulation) - mixed strategy (if fpu present, then use it, otherwise fall back to emulation) so, it sounds like the fpu traps are not correctly handled between wine and solaris (hard to tell more here)
- In win32/console.c, it seems that master/slave is reversed
through the fork. This is only going off the docs, but if it is, how is this working under linux?
don't worry about that. all this code should be removed real soon (if Alexandre commits my patches ;-)
A+