World Wine News

I installed Microsoft Office 2007 on a computer with Windows XP and then moved everything over to this box that has Linux on it. After moving Office 2007 over to the Linux box I had the joys of importing the registry settings from the XP install into Wine. After a week of working on this and tweaking Wine with dll overrides and registry settings I finally got most of Office 2007 to run in Wine.

Someone sent me a small Wine Configuration Manager that has a GUI for native Wine applications. This is a 0.1 release so it's still a work in progress, proof of concept. I ask if I could post it here and they said sure... So here it is!

The app is built with GTK and should run on any system that has GTK installed.

Quit has not been implemented yet so you will have to X to quit the program. I placed it in my home directory and executed it from there, the features that are currently implemented seem to work fine.

$ for y in {2002..2007}; do \
  n=$( git log | grep ^Date: | grep $y | wc -l ); \
  echo "Number of commits in $y: $n"; \
  done
Number of commits in 2002: 3094
Number of commits in 2003: 3283
Number of commits in 2004: 3851
Number of commits in 2005: 6006
Number of commits in 2006: 8431
Number of commits in 2007: 9513

 -Hans

Ok we talked and talked and talked and where did it all go? Where are the
agreed upon changes?

If we can't agree on everything, then lets do parts that everyone is ok
with. Then decide on more changes.


So far this what everyone was happy with:

wine-misc -> unknown (default selection)

test -> test (change description to "Conformance tests")
wine-advapi32 -> advapi32
wine-atl -> atl
wine-comctl32 -> comctl32
wine-console -> console
wine-crypt32 -> crypt32
wine-dbghelp -> dbghelp
wine-debug -> winedbg
wine-directx* -> directx*
wine-documentation -> documentation
wine-dos -> dos
wine-gdi-(printing) -> gdi32
wine-gdiplus -> gdiplus
wine-help -> hhctrl - Help viewer implementation
wine-kernel -> kernel32
wine-loader ->loader
wine-msi -> msi
wine-msvcrt -> msvcrt
wine-msxml -> msxml3
wine-ole -> ole
wine-opengl -> opengl
wine-quartz -> quartz
wine-richedit -> richedit
wine-setupapi -> setupapi
wine-shdocvw -> shdocvw
wine-shell32 -> shell32
wine-urlmon -> urlmon
wine-user -> user32
wine-usp10.dll -> usp10
wine-winelib -> winelib
wine-x11driver -> x11driver

Add new components:
-> wininet - Internet connectivity and Layer-7 protocols
-> wintrust - Cryptography and trust verifications
-> advpack - INF file based installation engine
-> imagehlp - PE binary file manipulations, signed file handling
-> shlwapi - Various shell helper functions
-> vdm - Wine 16-bit compatibility layer
-> comdlg32 - Common dialogs such as open/save/print/font

Remove:
Wine-Rebar

I think I will be able to do the changes next weekend.

If no one objects until Friday, I'll assume that everyone is fine with the changes as proposed in this thread.

I'll furthermore assume that I can modify the descriptions of categories as I see fit (I explained in a previous mail on this topic on how those could be made to convey more exactly which parts of wine they cover).

I just saw that there still are overlaping categories in at least one case, but that can be fixed in another step.

Alexandre's Keynote
http://www.youtube.com/watch?v=GqEp8psjv5s


Detlef Riekenberg - Printing in Wine
http://www.youtube.com/watch?v=1-n6mClDdBQ


Kai Blin - Wine and Samba
http://www.youtube.com/watch?v=ToKeJbQ87c0


Martin Pilka - CxTest
http://www.youtube.com/watch?v=VBZNOTngyeo


Maarten Lankhorst - Wine and Sound
http://www.youtube.com/watch?v=qKaYqsm4I_Q


Stefan Dösinger - Wine and Direct3D
http://www.youtube.com/watch?v=eJ-zyKR1N2A

Hi

I'm writing a small application to automate the process of setting Windows version for executables that are known to require a specific one. I'd like it to use the knowledge about defining Windows versions contained in winecfg/appdefaults.c instead of duplicating/forking code from it.

Would it be ok to move on_winver_change() and some of its friends like win_versions[] and set_reg_key() to libwine.so.1 for this purpose ?

--
Robert Millan

How about rather than writing another application to do this, you make winecfg take arguments on the command line so you could set something like winecfg foo.exe --winver win98 --dll=gdiplus.dll=n Then all you need is a script for your known bad applications....

Thanks Steven [Continued] Actually, another way you could do it is to use inf files and store them in a database. We discussed something like this for the appdb. Using inf's would be a cleaner method than hacking winecfg to automate importing this data in to the registry and then everyone can use it. I'd suggest if you know of an application thats buggy, needs the version and dll information hard set, you try the inf route and submit it to appdb if its an application listed there.

It's only a matter of setting a registry key, that can be done easily by calling regedit, there's no need to involve winecfg.

I think the solution to have multiple appdefaults with
programs having generic names like setup.exe and install.exe is to
enhance the support in wine and winecfg application/dlloverrides to
use md5sum/sha hashes. I don't know how julliard really feels about
this but this is similar to what was discussed with having a custom
Wine shim engine for application compatibly. If you were going to
change some code and he approves I think this is the route to go.....

So say rather than having

HKCU\Software\Wine\AppDefaults\setup.exe\Version win98

you would have something like

HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\Version win98
HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\filename
setup.exe

The system on windows doesn't use the md5sum (I think it has one) but it looks for the product ID which is buried into most executables first. It also checks for other things but in a hackier way. As there are a lot of different versions of a program but which all need the same override.

Roderick

I think it's a bad idea to do that:

 - Product IDs may not necessarily be unique identifiers for every
 given program.  Hashes are.

 - It's easier for users to submit information about their apps if they
 can use tools they're familiar with such as md5sum / sha1sum.

I'd like to hear Alexandre's comments for my suggestions. The current application override system bothers me but maybe he has other ideas or I am missing something. The entire system seems to depend too much on the applications name which seems limited to me but maybe he has ideas for a more robust way of tracking dlloverrides and version settings when the application name conflicts.