My two cents about winetools and the suggestions I read in Issue 308

[Tony Lambregts]

Philip V. Neves wrote:
> 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 
> showing themselves.
> 
> 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.
> 
[Snip]
>      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 
> reported.
> 
> Such tools would be useful in debugging the entire framework and speed 
> up development. These are suggestions. I hope they help a bit.
> 

I grudgingly have to agree that winecfg is at least partly inadequate. One of 
the things it is lacking is an export and and import function. I do not know how 
many times I have "blown away" my .wine directory. It would certainly save me 
some time if I could export the settings for a program and import them later.

If we had the ability to import and export the settings for a program then it 
would also be possible for someone to upload that file somewhere (lets say the 
AppDB) and someone else could download it and use the same settings.

The one problem that I can see with this is in the DLL overrides section. That 
is: if the import file contains a DLL override and the person does not have that 
dll installed we have a problem. Probably the best idea would be to search in 
the windows directories and warn the user if it could not find that file.

Of course this does not address actually getting these dlls which is part of 
what WineTools does.

Tony Lambregts