Re: WWN article: DLL overrides

[Eric Pouech]

Bradley Baetz wrote:
 
 Ove Kaaven wrote:
 
  On Mon, 5 Jun 2000, Bradley Baetz wrote:
 
   Also, the msacm/msacm32 dll pair is used for the audio compression
   manager. In order to do conversions the builtin versions have to be
   used.
 
  Are you sure that's what it says? The documentation is quite ambiguous at
  that point.
 
 This is from discussions with Eric earlier this year.
 
 I think its ambiguous because its confusing :) That file is no longer
 really a status file, and should probably be split up a bit.
 
 
   Hows this for some text, paraphrased from the docs:
 
  That text apparently applies to msacm.drv, and in my interpretation says
  that built-in msacm.drv only works if you also use built-in msacm and
  msacm32.
 
 That's probably right, although I haven't tested that. If that is the
 case, then is it possible for the three files to be linked with
 [DllTriplet], or a pair of dllpair entries in whatever file those have
 moved to? Does the code handle entries appearing twice?

to be precise:
msacm.drv is the wave mapper (it both allows to choose from several physical
output device, as well as inserting filtering and conversion algorithms
between an audio stream provided by an application, and the audio stream
the hardware is able to render
msacm.drv uses the DLL pair msacm/msacm32 to provide the loading/unloading
an invocation of those filters and conversions (which are external DLLs)

there are three layers to look at:
mmsystem/winmm
msacm.drv
msacm/msacm32

native mmsystem/winmm requires native msacm.drv (for 16/32 issues)
native msacm.drv is 16 bit, so relies on msacm. builin msacm is not as well 
implemented as builtin msacm32

I don't remember all the details, but IIRC, I couldn't get native msacm/msacm32
to run because of registry settings I never bothered to look into

currently, the only working solution is 
mmsystem/winmm/msacm.drv/msacm/msacm32 all builtin
however, mmsystem/winmm/msacm.drv builtin and msacm/msacm32 native should be made
working as well as 
mmsystem/winmm builtin and msacm.drv/msacm/msacm32 native 

A+
--
---
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle

Re: WWN article: DLL overrides

[Uwe Bonnes]

Rein Klazes writes:
 On Mon, 5 Jun 2000 07:44:36 +0200 (CEST), you wrote:
 
  My next WWN feature article can be previewed at
  http://www.ping.uio.no/~ovehk/wine/News/2000-23.html
  
  I'd appreciate it if you could tell me about any errors, omissions, or
  unclear things before it's too late (when this WWN is released)...
  
 
 I would at least mention somewhere that the settings in these sections
 may be overridden by the -dll option on the command line
   
  --dll

-dll still works somehow, probably only is honored for the first
process started... 

Bye

Uwe Bonnes[EMAIL PROTECTED]

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
- Tel. 06151 162516  Fax. 06151 164321 --

Re: WWN article: DLL overrides

[Peter Hunnisett]

snip


I would at least mention somewhere that the settings in these sections
may be overridden by the -dll option on the command line

I may be ignorant, but it would seem that as of, at least the last release,
this doesn't work. You can only use the -dll option to specify things if
you don't have a DllOverides section. I haven't looked into it, because I'm
basically too lazy. I'd guess DllOverides is evaluated after the command
lines. I think that at one time you could command line override the wine.conf
file though (memory hazy ask later...;).


Rein.
-- 
Rein Klazes
[EMAIL PROTECTED]



Ciao,
Peter Hunnisett
[EMAIL PROTECTED]

Re: WWN article: DLL overrides

[Ove Kaaven]

Thanks to all that showed me the errors of my ways before the WWN was
released... hope I can count on you next week too (and the week after
that, and the one after that, etc).