My two cents about winetools and the suggestions I read in Issue
Philip V. Neves
pneves at telus.net
Wed Mar 15 12:19:01 CST 2006
What I'm seeing here with the whole debate with wine and winetools is
that its a configuration management issue. The project is getting into
the stage where testing needs to be accomodated and so does getting
things working. I think whats currently available for managing
configurations to wine is innadequate. Even winecfg provides an
interface that is innadequate for making many changes in terms of dll
overrides. Plus it doesn't provide a mechanism for rolling those
changes back. Or even managing multiple configurations or modes so that
problems can be issolated. I think whats is comming out of the
winetools debate is better tools are needed for configuration
management. This isn't very revolutionary. Its a natural part of the
software development life cycle. As a project starts emerging from the
development phase ways to provide better configuration management start
Something that interfaces with the AppDB would be good. It would make
things easier. I think, given the complaints given by the developers are
also valid but so are the complaints made by the people trying to use
the program and even the testers. Most other projects don't need such
tools but this one does given what its trying to accomplish and the
complexity of whats being accomplished. Besides even windows XP has a
roll back feature now to fix problems. Why doesn't wine considering its
attempting a bug for bug compatibility with windows. This would be a
wise thing to implement just for sanities sake.
So I'd like to provide an addition to Jason Greens brain dump
* AppDB would have to be extended to be able to get and report this
data, and it would make sense for each App's maintainer to be able
to manage that information.
* Biggest issue here is that this information could have a tendency
to change very rapidly, so it might overload the app maintainers
if they had to track this for each version of wine. What I think
would make sense is to have regular snapshots (every 3 months?)
and release a new version of "Winetools Plus" or whatever you want
to call this thing a month later to give the maintainers time to
update each of their apps based on the frozen version. (I think
multiple versions of the AppDB would be useful. Similar to the
Release and Release candidate type way of doing things.)
* Data needed: AppID, AppVersionID, WineVersionID, Window Version,
DLL Overrides, Window settings (fullscreen/windowed - sometimes
and issue), Sound options, Video acceleration required, General
notes or HOWTO's, etc. You would need separate overrides/settings
for Installing vs. Running the app.
* AppDB could dump this information to an xml format which
"Winetools Plus" could be distributed with. Maybe have an option
to download the latest xml file directly from winehq.org.
* The 'Winetools Plus' front-end would just be a menu which would
query all of the apps in the xml dump. The user picks they app
they want to install, and it reads the necessary information,
verifies the source installation media, and goes at it.
* Applying patches to apps might get tricky (e.g., where wine only
successfully runs version 1.5 of the app, but 1.0 is on the CD),
but I'm sure it could be worked out.
* A Way to roll back DLL overrides.
* A Way store roll multiple registry configurations so that we
establish a base reference configuration and a test configuration.
Or even multiple test configurations.
* An AppDB tool that allows changes to the DLL configuration in the
AppDB to be made easily.
* A way to detect the version of wine and provide configuration
changes given that version of wine.
* A way to report bugs to the appDB maintainers about configuration
A nice to have would be
Something that allows the AppDB maintainers to distribute tweeks
to the configuration changes in the AppDB to users. So that even if we
aren't installing the programs on the system. The tweeks can still be
made on the fly. This would eliminate having to blow away the .wine
directory all the time. Blowing away the .wine directory is not a
desirable. A way for wine developers to distribute a test configuration
would also be a useful thing. That way we can test the software with
what the developers want us to test rather then shooting in the dark
only to see that the bug we reported is the same as some other bug we
Such tools would be useful in debugging the entire framework and speed
up development. These are suggestions. I hope they help a bit.
More information about the wine-devel