eric pouech wrote:
Before I start, the large checkin this morning definitely broke the dll loader (at least on solaris). Sol.exe no longer runs :(
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 ?
it doesn't show ANY audio codecs.
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
yup... those and more are there - I copied a working w98 win tree there, and it did find the video codecs.
(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 ??)
not certain. My linux reference machine's hd just died, so I can't truss it (don't even get that far under solaris - dies trying to bring up the dialog)
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)
what I don't understand is that one would think that should cause a SIGILL, and not a SIGSEG. Does wine return a CPU type somewhere?
- 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 ;-)
looks like TOO much was removed :)
-r