Wine 0.8 TODO v0.1

Greg Turner gmturner007 at ameritech.net
Sat Nov 2 02:55:20 CST 2002


On Saturday 02 November 2002 01:23 am, Francois Gouget wrote:
> For instance, let's say I want to run for DreaWeaver 4. I go to the
> application database and see this:
>
> To get DreamWeaver running, append the following lines to your Wine
> configuration file:
>
> [AppDefaults\\Dreamweaver.exe\\DllOverrides]
> "comctl32" = "builtin,native"
> "shfolder" = "native"
> "ole32" = "builtin"
> "oleaut32" = "builtin"
> "msvcp60" = "native"
> "msvcrt" = "native"
> "mfc42" = "native"
> "imm32" = "builtin,native"
>
> [AppDefaults\\Dreamweaver.exe\\x11drv]
> "Managed" = "N"
> "Desktop" = "1024x768"
>
> ---
>
> Now what's cool is that this information actually is in the
> Application Database, it's just a bit buried (hopefully it's correct
> too). What's needed is:
>
>  * more applications should have instructions like the above
>  * we need Application Owners who use a given application regularly
> and can check the validity of these settings, can put them at the
> beginning of the page, and keep them up to date

Can't we do one better by maintaining this information in the wine tree 
itself?  I know such things /are/ hacks, but they are needed for 
several important applications, especially the "big ones".  Keeping it 
in cvs (or some other easily updated database) just seems like the most 
likely way to get it actually kept up to date.

I realize this might not be the most popular proposal amongst the 
wine-devel crowd, given the desire of all of us to have the builtin 
dlls work properly in wine for all app's; but the reality is that wine 
isn't there yet and probably won't be for some time.

IMHO there is probably some kind of potential synergy between Jeremy's 
idea of integrating WineSetupTk with wine, and Francois' idea of 
keeping these dll overrides up-to-date -- I think it would be really 
cool if we could arrange things so that wine "just works" out of the 
box for commonly used app's.  IMHO, this is more important than getting 
folks to fix bugs in wine; if they are inclined, and able to do so, 
they will be able to find the config file and hack on it.  WineSetupTk 
provides all the hard parts of the infrastructure already: namely, a 
gui onto the ~/.wine/config file.

Since wine is rapidly evolving, we all want to stay on the bleeding 
edge, and users probably do too...  I don't know about y'all, but I 
regularly manually merge changes to:

  o the wine default registry
  o the wine default config file

into my installation in ~/.wine, from changes I see in CVS.  It's a 
minor hassle for me; but unless you happen to be intimately familiar 
with version control techniques in general, and cvs/diff/patch 
utilities in particular, it's probably quite difficult to keep this all 
sorted out.  You can probably guess where I'm headed with this:

  o A database of configs and registries, with actual version numbers
    and change history (cvs could be all the database we need, or we
    could implement some more sophisticated system)
  o WineSetupTk (at least as a starting point)
  o Glue to launch WineSetupTk as a control-panel application
  o More glue to integrate WineSetupTk with the forementioned version
    database.

So, user Less Clue updates his wine.  When next time he runs, some 
little dialog box pops up:

  "New default registry entries and default configuration settings are
   available for wine.  How to deal with this?

     [ ] Attempt to merge changes automatically.
     [x] Ask me again later.
     [ ] Ignore the changes.
     [ ] Never, ever, show me this crap again.
     [ ] View the changes and merge them manually."

If Less isn't into tweaking the hell out of his config files, then he 
just picks "merge automatically" and his wine keeps on "just working," 
but he has all the latest-and-greatest defaults installed into his 
~/.wine/config with no thinking involved, and no editing text-files.  
If he does need to do some hacking, but is scared of text files, well, 
we have a gui for him to do that.

This scheme can be adapted to a pure-registry-based approach with ease 
(in fact a pure-registry approach makes it /easier/ to implement since 
you now only have to merge registries, which already have a nice (OK, 
usable) API on them we can query (win32), and the config file is gone 
(or highly static)).

Just plantin' seeds...

-- 
gmt

"The purpose of government is to rein in the rights of the people"
 --President Bill Clinton, MTV interview, 1993




More information about the wine-devel mailing list