On Wednesday 30 October 2002 12:57 am, Ender wrote:
- No users, because of two things:
- Many apps do not work without Desktop enabled. This is far
worse than it sounds, because most newbies try managed non-desktop first. People think WINE should be able to do seemless intergration. Then when an application hangs, they think it's incompatible and give up. However in many cases the Application will work fine in Desktop mode. BAD, these apps should either be made to work... or non-desktop mode should be removed!
wierd, I basically never have theese problems, even in cases where the AppDB says it's an issue... what apps need this right now?
- Getting the right set of dlloverrides and registry entries
correct for a large portion of software is irritating.
yes. perhaps we should include a much larger default config with usable defaults for several popular programs (or two config files, one for shared installs, one for wine-only installs)? I'd be happy to contribute my config file, for one, which runs quite a bit of junk.
Most of this comes down to the lack of WINE being able to dynamically run RunOnce and wininit.ini entries. Doing this manually is far beyond your average user who just wants to install a reasonably complex program. Something like Crossover's reboot.so is needed.
this is a relatively simple task, isn't it? wininit.ini is especially easy; RunOnce is a little trickier, because some RunOnce stuff should probably be censored. Another issue I see is the appearance of certain 8.3 filenames in the registry and the filesystem when running certain installers; this is kind of tricky to fix programmatically, but it could be done as part of a reboot.so-type program, I guess. Another (simpler) option would be to make a log of such problems during registry and filesystem operations, and notify the user to process the log during "reboot."
Also, during "reboots" that I've done using "explorer.exe", I notice some regsvr32's tend to fail; usually, they can be fixed using various dll overrides to regsvr32; a registry of special per-dll-to-register regsvr dll overrides, and a wrapper to invoke regsvr32 with the appropriate overrides from this registry, could go a long way towards eliminating this. Again, this will only help those doing mixed installations.