World Wine News

I started work porting a windows app using winelib, and hit an issue relating to the fact that there is currently no implementation of uxtheme.dll (and more importantly, no headers, of which would be enough to compile the app as it dynamically loads all the uxtheme dlls as needed, and falls back gracefully)

Because of this, I've been thinking about beginning an implementation of uxtheme.dll. I am curious if someone has already taken up this task, or if anyone any opinions on this topic.

Sure it is. Apps attempt to LoadLibrary it if they detect it to enhance their drawing capabilities. It's conceivable that one day apps will not have this backwards compat code and simply require Windows XP or above, so it needs to get done.

It's also the Right Way to make Wine not look like ass on our pretty desktops, because the win32 apps will be theme aware.

I hope you know what you will begin with. (For the ones that don't know uxtheme.dll is the dll that takes care of all theming on WinXP and it is the dll that dlls like comctl32 and all others use for theming)

Some time ago I checked out uxtheme.dll a bit and it seems that it needs changes all over Wine. As I understand it WinXP ships with two sets of comctl32.dll and friends. One is the "old" version and one is a new uxtheme aware version. The uxtheme aware version contains lots of changes and uses uxtheme for theming. To use uxtheme you need to add uxtheme support to the dlls that need it which looks like a huge job. Perhaps this is something post Wine-1.0?

The "old" dll that MS ships with WindowsXP is comctl32.dll version 5.x which is the same as on other Windows versions.

Version 6 is the new version. One of the biggest changes is that this updated dll handles both the user and common controls. Further all controls now include some area in which can be drawn for theming.

For more info check out: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/xptheming.asp

Some time ago I started hacking in support for GTK themes. When I first suggested this project to the list there was suggestions that doing it with uxtheme.dll was the way to go. I agreed, but didn't have winxp to play with, so I kept tinkering on this project with the intent of learning a bit more about how wine works (which meant learning a lot about how GDI and X work, though I didn't realise that I'd need to know that stuff when I started on the project). I actually managed to get some results which were starting to look promising (though there's no way I'd submit that code as a patch). Screenshots here (the checkbox being the only important part):

• http://james.id.au/wine/wine-ss1.png
• http://james.id.au/wine/wine-ss2.png
• http://james.id.au/wine/wine-ss3.png

Anyway, the reason I'm posting is not to suggest that this code be used (nor the approach I took), but to mention that if theming code is to be written that I think it's really important to have a way to pass off rendering of controls etc to a .so that can be dlopened and called with dlsym. IIRC the existing system uses a function lookup table, so there shouldn't be much that needs to change for this to occur -- only the initialisation of this function table and probably some hooks so that these .sos can detect whether or not they'll work with the current configuration (as an example the way I was doing gtk theming won't work with anything that isn't x11drv. I don't like breaking encapsulation like this, but it sounds like it's practical in this case). I don't know if I can be of any help, but I'm interested in trying -- please keep me posted.

I'm currently working on implementing support for .msstyles themes (which are used by XP) primarily because the format follows the API pretty closely and will be easier to test my implementation against an XP box.

One nice thing about .msstyles themes is they are basically just a resource-only DLL, which could of course include exported functions.

Going along that path, one possible way to integrate theme support from your native window manager is to extend the .msstyles theme format to enable using exported functions for drawing some controls, which could then make direct GTK/etc calls.

Another possible method would be to create a conversion tool to create an .msstyles theme from a GTK theme, or to simply create a totally new method of defining themes for WINE.

I'm not very familiar with how the winelook is handled in code, what does it do exactly? If it simply affects system metrics & colors that would be easily merged with themes, if its more than that (like for example different common dialogs) it may be more difficult

Full blown theming in windows uses a combination of .theme files and .msstyles files.

.theme files I believe existed before XP and do not use uxtheme.dll. They primarily just define system metrics and colors (along with icons for things like My Computer, etc and mouse cursors).

.msstyles files are the basis of uxtheme.dll, and allow much broader theming support as seen in WinXP, as well as defining system metrics & colors (but do not define icons & cursors).

The two theme formats are coupled very loosely, they can be used together (primarily to enable defining icons & cursors with a graphical theme) or separate. When used together, any metrics & colors defined in the msstyles override those defined in the .theme

Alexandre has requested I use the registry keys that windows uses to define theme configuration, in which case under XP those keys are located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes and HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ThemeManager

The configuration seems to be split between those two locations, with a couple options in both. HKCU primarily contains configuration related to XP's msstyles method of theming, HKLM looks to primarily define theming with .theme files (although there is some slight crossover between the two).

well this is NOT yet another effort to imitate WineCfg!

WineCfg needs Wine to be running to work. WineWorks does NOT need Wine to be running. WineWorks has been developed using Qt 3.1.1

WineWorks has been written keeping it in mind as MORE of a troubleshooting tool rather than a customization and configuring tool. That is something WineCfg is there for. I intend to make WineWorks as a tool which can HELP a user figure out potential problems which can hinder running Wine on his machine and to resolve those issues so that Wine may be up and going... all from a easy to use GUI.

Please try out the program and send reports back to <subhobrotosinha at yahoo dot com> with [WINEWORKS] in the subject line and an optional line appended to it if required. I will soon put the details up on my site as soon as I get a few reports in my mail box.

The program is attached compressed as 'WineWorks.zip' and has MD5 Sum '145a82af87efa62c8a694c5a1c18a0a5'.

NOTE: It's recommended that you run WineWorks from a shell window to see the trace/debug messages. That way you can see what it's doing behind the scenes and where it went wrong (if it did)..

Recently there has been a revived interest in putting up a 'Windows' like 'Start Menu' onto the Window managers. That's good.Thanks.

But as I see it, this task is REALLY easy. Once we resolve the Windows shortcut files, figuring out how to implement the resolved menu entries for respective Desktop environments is dependent on the Desktop environment themselves, and people wanting to implement the 'Start Menu' on that environment. Windows maintains its 'Start Menu' under '%ROOTDIR%\Documents and Settings\%USER%\Start Menu' (yeah I am talking >=NT, Win2k. For 9x, it will be probably 'C:\WINDOWS\Start Menu'), and this folder contains LOADS of shortcut (.lnk) files. So if we can just recurse through this folder and read out the .lnk files into compatible menu/desktop entries of the corresponding Desktop environment (KDE,GNOME...), we have a working, synchronized 'Start Menu'.

And that's JUST what McCormack's 'winemenubuilder' does, and reading out the code I can see it's THE thing we need.

Unfortunately, 'winemenubuilder' shipped from Wine-20030618 - the VERY version from which IPersistFile::Load() (the VERY function used to resolve windows shortcuts) got broken, so I could not see 'winemenubuilder' in practice! (Mike, if you are reading this, could you tell me on what Wine ver you originally developed it, and does 'winemenubuilder' work now ? Thanks)

You yourself may try out 'winemenubuilder', and if it works let me know. I will know that I was at fault all along, and that would be good news for me !

Now, there arises the problem. Microsoft really does not tell us what's the data structure of .lnk files, though if Alexandre (or somebody of his status..) requested Matt Pietrek for that information, we can probably get it.

Unfortunately, it's not just as simple as enumerating "C:\Windows\Start Menu", though that would be a good start.

To do things exactly the same way as Windows does them, we have to make a shell namespace that contains all the stuff on the start menu, then enumerate that. Furthermore, since the namespace is dynamic, the menu really should be constructed on the fly, not just written to an .desktop file.

I had a bit of discussion with Robert van Herk about this (see the thread about ""Start menu" (continued)" on this list). I mentioned to him that I thought the best way to solve the problem would be to write a gnome-vfs library and KDE plugin that query a wine process for the structure of the startmenu at runtime.

For starters we could just use the 'Start Menu' directory, but you miss out on things like Outlook Express and Internet Explorer's Icons, because there's no .lnk file for those... they are created by a shell namespace extension (I think :).

Anyway, it would be great if we figured out the remaining structure of .lnk files, and finished the IShellLink implementation properly, and no matter how things are done, we need that code to be complete. The best way to do that, IMO, is to examine a lot of .lnk files from windows systems :)

From discussions with others from this list, I understand that you should not just want to list the entries in the start menu folder, but also other things (control panel, etc).

There should be a dll file (shell32.dll?) that can be queried to provide this information.

What I am currently working on is a client on Linux and a server in Windows (Wine). The server should notify the client when new entries appear, and the client uses the server to get all the needed information for the start menu.

I am about halfway for the first client, that will run on KDE.

Didn't touch the server yet, seems harder to build. Also didn't think really hard on the communication between the server and the client. Pipes won't probably be a good idea, because you want bidirectional communication.

Anyhow, the first client is set up using QT. I am not sure whether this is general enough, so please tell me if this is not wise to do, for example if it won't be compatible with Gnome. If everything is QT compatible, only the very frontend of the client will have to be reprogrammed for the different desktop environments. That means that most classes could be recycled from the KDE version.

I am going to anonunce that Task Manager is starting to work in ReactOS... Thanks to w3seek's last patch it displays almost all controls correctly. (Also thanks to GvG and everyone else involved.)

There are still these problems:

1. It crashes in NtGdiDeleteDC in call to DRIVER_UnreferenceDriver.
2. The current state of ReactOS shell32.dll and winmm.dll is bad. It worked correctly a while before ReactOS 1.1.3 was released. AFAIK, Steven Edwards and Andrew "Silver Blade" Greenwood are working on winmm.dll. I can repair the shell32.dll from the old version, if there is enough interest.
3. We still don't have a comctl32 port in our CVS. I will commit it as soon as my w32api patch will be merged to MinGW's CVS.