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?
The next are portability / solaris questions...
1) 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?
2) regapi uses strsep, which solaris doesn't have. Is its usage in wine compatible with strtok, or should I cut/paste strsep into library/ports.c?
3) 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?
That's all for now....
-r
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+
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
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.
could you elaborate what you mean with "show" and "audio codecs" ? (I don't get what you want to say)
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?
yes, in misc/cpu.c... however the causes of the SIGSEG have to be investigated... what's the instruction causing the signal to be raised ?
A+
eric pouech wrote:
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.
could you elaborate what you mean with "show" and "audio codecs" ? (I don't get what you want to say)
virtualdub has a selection that brings up the audio compressors (and another that has the video compressors) that can be used to compress a stream. The audio compression list is empty, while the video one has all the ones I expect. Sounds like from a previous post that it's a problem of not related to the audio device.
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?
yes, in misc/cpu.c... however the causes of the SIGSEG have to be investigated... what's the instruction causing the signal to be raised ?
uh, I wish I could be more specific, but gdb (at least under solaris) is pretty abysmal as far as multitheading apps go, and since the problem doesn't happen under linux and that wine doesn't work with the bundled assember/compiler (which rules out the use of the better forte tools), tracking this down is slow going. The current version oddly brings up virtualdub fine, but now fails bringing up solitaire (ugh). Look like something broke in the X stuff, but that's pure speculation right now.
-r
virtualdub has a selection that brings up the audio compressors (and another that has the video compressors) that can be used to compress a stream. The audio compression list is empty, while the video one has all the ones I expect. Sounds like from a previous post that it's a problem of not related to the audio device.
well, other post says that no ACM driver is reported when there's no audio available... that's perhaps the program which disables the list when no audio is avail. could you mail me anyway the -debugmsg +msacm trace
TIA
eric pouech wrote:
virtualdub has a selection that brings up the audio compressors (and another that has the video compressors) that can be used to compress a stream. The audio compression list is empty, while the video one has all the ones I expect. Sounds like from a previous post that it's a problem of not related to the audio device.
well, other post says that no ACM driver is reported when there's no audio available... that's perhaps the program which disables the list when no audio is avail. could you mail me anyway the -debugmsg +msacm trace
ok... attached is the wine output for the above
I *finally* got it back to working order. Ended up that the last checkin caused a reconfiguration that latched onto the X11 4.1.0 tree on my system (as opposed to the openwin one). For some reason (as stated before), wine crashes when compiled/linked against the XFree tree, but runs fine when compiled against the openwin tree. My suspicion is that it is a funky threading issue - probably should be in a readme somewhere.
Also, I got the following message from Avery Lee (the author of VirtualDub). Am posting it here as an FYI and for archival reasons.
From Avery Lee:
Please feel free to forward this on to other developers or onto the Wine list.
I read the discussion about VirtualDub crashing the Wine loader with great interest today. (It's a bit weird that the only way I heard about a problem with my Win32 program was via a Unix-oriented mailing list.) Yes, the exports header points to garbage, and yes, it was caused by UPX -- UPX left the export header RVA and size in the PE32 optional header exactly was it was in the unpacked image. You can safely hex edit the bytes at 180-187 to null to kill the bogus export directory, since it turns out I exported those functions by mistake in some hasty cut-and-paste and they aren't used.
As for other compatibility problems with Wine, I have gotten VirtualDub to run in the past under Linux, although I ran into severe problems with the handling of custom templates in GetOpenFileName() and slow updates in the trackbar common control. The last time I tried I had to remove two calls to SetUnhandledExceptionFilter() to get it to run.
One more thing: There is an undocumented Wine compatibility switch /w that you can specify on the command line to force VirtualDub to use StretchDIBits() to blit to the screen instead of a DIB section. It was a workaround for an old problem where Wine wouldn't mark a GDI DIB section dirty if it was written to through an aliased, memory-mapped section.
Hmm, I noticed that when using VirtualDub, I had the same problem with ACM codecs. I did some detective work and found the problem to be a mistake in dlls/msacm/driver.c. Included is a patch to fix this error. However, I noticed that with this patch, the codecs are found, but for some reason are listed many times for each codec!?
- Travis
Index: dlls/msacm/driver.c =================================================================== RCS file: /home/wine/wine/dlls/msacm/driver.c,v retrieving revision 1.13 diff -u -r1.13 driver.c --- dlls/msacm/driver.c 2001/07/25 00:43:31 1.13 +++ dlls/msacm/driver.c 2001/11/09 16:09:43 @@ -171,7 +171,7 @@
if (!fnCallback) return MMSYSERR_INVALPARAM;
- if (fdwEnum && ~(ACM_DRIVERENUMF_NOLOCAL|ACM_DRIVERENUMF_DISABLED)) + if (fdwEnum & ~(ACM_DRIVERENUMF_NOLOCAL|ACM_DRIVERENUMF_DISABLED)) return MMSYSERR_INVALFLAG;
for (padid = MSACM_pFirstACMDriverID; padid; padid = padid->pNextACMDriverID) {
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On Tue, 6 Nov 2001, Roger Fujii wrote: [...]
- regapi uses strsep, which solaris doesn't have. Is its
usage in wine compatible with strtok, or should I cut/paste strsep into library/ports.c?
I believe regapi is not compatible with strtok: if you have "Name"= then regapi expects to get two tokens '"name"' and '', but strtok only returns one. I was also wondering how to best fix that. Since it is a Winelib application and not a part of Wine I don't know if implementing strsep in library/port.c is the best solution: shouldn't we be able to compile regapi on Windows? In addition to that Wine itself does not use strsep. I would like Alexandre's opinion on that :-)
So the other solution is to reimplement strsep in regapi itself and I have a patch for that. Just in case, here is a carefully tested strsep reimplementation:
static char* getToken(char** str, const char* delims) { char* token;
if (*str==NULL) { /* No more tokens */ return NULL; }
token=*str; while (**str!='\0') { if (strchr(delims,**str)!=NULL) { **str='\0'; (*str)++; return token; } (*str)++; } /* There is no other token */ *str=NULL; return token; }
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
-
eric pouech -
Francois Gouget -
KiLMoR Zombie -
Roger Fujii