MSCMS: new dll

[Mike Hearn]

> > How much work will you be doing on this library?
> 
> Hey, this is open source! It's hard to say but I will attempt to get that
> basic functionality done... 
 >
> > Will we get into the same state as SHDOCVW where the DLL is essentially 
> > useless?

For what it's worth I don't think we should start excluding new DLLs 
from the tree until they reach maturity (what is mature anyway?). If 
they aren't in there people probably won't hack on them.

The flip side is then we end up with a ton of stub DLLs and programs 
that could work in its absence now break. This is a danger whenever you 
add stubs, it's happened with function stubs as well.

For DLLs the solution I'd like to see is simply a default loadorder of 
"native, builtin" for DLLs we know aren't really complete enough for 
most apps. Possibly we could also tie the DLL overrides to the Windows 
version.

For instance, if there's a DLL that only exists in Win2K or WinXP but 
not Win98 then when the emulator is set to win98 mode, we could have 
foo.dll have an override of "native" so preventing the builtin version 
from being used. In Win2K/WinXP mode, they'd become "native, builtin" 
(or maybe builtin, native if we know the native version doesn't work).

I think most users understand the version setting and play with it first 
when things go wrong. So by tying the usage of new/incomplete DLLs to 
the Windows version we make it more likely that users will stumble upon 
the right settings.

thanks -mike