Re: waveOutReset and Win16Mutex
James Abbatiello wrote: Continuing in my efforts to get MOD4WIN working, I have come across the following problem. Its a 16bit application and it calls waveOutReset while holding the Win16Mutex (SysLevel 1). Wine attempts to send a notify message back about this. However, the notify gets sent from a different thread. That thread needs to send the notify to 16bit code and thus needs to obtain the lock. The original thread is still holding the lock and is waiting for the other thread to finish sending the notify before continuing. The following patch removes the problem for me. I just arbitrarily stuck a ReleaseThunkLock/RestoreThunkLock around the wait call in the first thread. Is this the right solution and the correct place to put it? If so, do the other similar functions there need the same thing? well, if this is needed, it shall not be done in wineoss/audio.c which is meant to be pure 32 bit DLL, but probably in 16 bit MMSYSTEM.DLL. In Windows, MMSYSTEM thunks up to WINMM (32 bit)hence releasing the locks. currently in Wine, MMSYSTEM just 32 bit calls WINMM, which can be the cause of the issues can you send me a -debugmsg +mmsys,+wave,+msacm,+relay=mmsystem:winmm just to check A+ -- --- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
Re: TSX* question
snip Yes, if you only consider systems using a recent glibc and a thread-safe Xlib. True. But, I guess, we can assume that for Linux-based system, right? Probably, yes. There are people who run libc5 still. My personal computer has it still, but I haven't used it in a bit as it's 4000 miles away. You were proposing just to make the check for glibc anyways, so that'll do. snip Ciao, Peter Hunnisett [EMAIL PROTECTED]
Re: wine .spec file autogenerator
However, I've noticed that it doesn't appear to correlate with the already existing shell32.spec file based on a dump of the WinNT4 shell32.dll (at least as far as ordinals go). Can anyone explain this? No, the shell32.spec is not based on any dump of a native shell32.dll. - the shell32 exports many functions by ordinal withou a name. Your tool likely can't cope with it - or it would need to use *.dbg and *.pdb files to get symboles from. (have not tryed it jet) - our shell32.spec defines many functions from different versions off shell32. (win95,win98,winnt, w2k). You have to carefully place some special functions on special ordinals to avoid conflicts. All functions exported by ordinal have to be on this ordinal. The leftover functions are exported by name. Your tool might be good to create a initial implementation for a unknown dll but the spec files for allready implemented dll's usually containing a lot of manual tweaking. ciao juergen
