>> 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
