Currently Wine loads the complete registry into memory at startup. This is relatively ok when the registry is small such as in fake_windows configurations, but when importing the registry fro a Windows partition this can result in the wineserver allocating more than 30MB. This slows down startup times very significantly and wastes memory even if most of it is going to be swapped out.

One of the reasons why Wine puts all the registry into memory on startup is that the current registry file format does not lend itself well to random accesses (especially writes). But there is no fundamental reason why Wine needs to read all the registry on startup. Hence this proposal to:

• change the registry file format so that Wine can easily make random accesses. A 'database' format may be appropriate here, maybe based on the Berkeley database Library (libdb2/libdb3) or the GNU dbm library (libgbm1, but check license issues).
• put in place a mechanism to update these files from the Windows registry files when appropriate (it seems impractical to access the Windows files directly)
• modify the registry routines to retrieve only the data required by the application and cache it in memory

I've looked into using a Balanced Tree DB from BerkelyDB as a quicker interface to the registry. I think it would be a good solution, but the question is whether or not you want the overhead of another library added to wine. That's why I'm writing here actually - I need to know if it's ok to add this dependancy to wine, or if I should find a different approach.

I know this would cause some chaos in the community - so If this is something that everyone agrees should be done, I'll write a small utility to convert the current ascii registry files into the new format.

Let me know what you think

The only reason that the current method is fast is because we're loading the entire registry into memory. As stated in Bugzilla, this is fine for small registries, but the author of the bug has noted wineserver allocated up to 30MB when wine initiates JUST for the registry!

I'm not saying we should abandon the way we edit our registry - because it is very useful to be able to edit it manually with a text editor. . . HOWEVER, I believe we should have a more elegant way that the API accesses the registry. Using a small helper app to sync our plain-text registry files into a db format would let us maintain a human-readable format of our registry, while also reducing the overhead required by the current registry format.

Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information - It would also provide us with a quicker and easier way to search through the registry - so we could finally implement the Find feature in wine's regedit without much effort ( Not that it couldn't be done as is, but things would definitely be easier ).

I'm really not trying to push something that wouldn't help wine if not now, in the near future. A lot of people don't have fast machines with an abundance of memory. 30MB can be a lot of memory for someone with 128MB of RAM.

How about an application that carries a binary registry hive around, and uses "LoadHive" to merge it (temporarily) into the registry?

How about deploying Wine in such a way that it uses the existing user profile, user.dat and all? User.dat is a registry file, that goes through load hive.

The way I see the ultimate outcome, Wine should have "Registry providers". These would allow it to use several different registry back ends. The default one would probably be the one used today, but this way we could plug in an SQL back end if needed, as well as a Windows compatible one, if needed.

I would like to add a checkbox control ("Show host filesystem") to winecfg to allow the user to easily (un-)register the unixfs shell namespace extension. So winecfg would have to query and create/delete the "HKLM\Software\Microsoft\CurrentVersion\Explorer\MyComputer\Namespace\{UNIXFS-CLSID}" key. There are helper functions in winecfg.c to cache registry values for later application, iff the user clicks "Apply" or "Ok". However, those seem to work only for keys rooted at the config key "HKCU\Software\Wine".

My question is: Am I doomed to implement the caching on my own for this key, should I generalize the helper functions, or do you think this configuration option should'nt be in winecfg at all?

If you register the extension, you will have the drive letters as well as the unix filesystem, which is somewhat redundant. Thus I thought we might better not register it by default and give the user the choice.

In my opinion, the best way would be to have an option under [shell32] which can be set to show the dos drives, the unix filesystem or both. This could be set globally or in AppDefaults (and since it would be under HKCU per user). This would mean some unixfs specific code in the MyComputer shell folder, but I guess there's no way around this, if we want to be able to hide the drive letters.

Yeah, I think that would work better for the user. I'm not sure it should be a preference just to enable/disable unixfs as is, but if you can set it as an appdefault and hide the drive letters that'd be good.

One thing we might want to look into is integrating with the GNOME/GTK+ file roots. In the new file picker, it hides the UNIX by default and you have multiple roots like "DVD Drive", "Home", "Desktop", "Apps on SomeServer" and so on. I think that's a much more user-friendly way of doing it than exposing things like /mnt, /usr/, /etc to the user. That would be an additional unixfs feature I guess.

I think those should be handled by a MyDocuments shell folder, which should work with both shfldr_fs and shfldr_unixfs, whatever the user selected. So we would have multiple instances of the MyDocuments shell folder with different names (like Home, DVD Drive, ...) and different target directories (like /home/foobar or /cdrom), configured with winecfg (or perhaps read from the gnome config).

I found the website http://www.virtualplastic.net/html/ui_shell.html , which describes how to create virtual shell folders that link to locations in the filesystem. And then there's the freeware tool "Shell Object Editor" http://www.tropictech.de/modules/wfdownloads/viewcat.php?cid=1, which does this stuff programmatically. I guess if we implement the necessary behaviour in wine, that would be all we need? (And perhaps some code in winecfg to read the gnome configuration and map it to virtual shell folders.)

The relevant function is here:

http://cvs.gnome.org/viewcvs/libgnomeui/file-chooser/gtkfilesystemgnomevfs.c?rev=1.65&view=markup

It's gtk_file_system_gnome_vfs_list_volumes. Doesn't look too hard to dlopen libgnomevfs and fetch the right list. Harder part is integrating that with the shell32 VFS and getting things like icons right etc.

Yup, that's the fonts substitutes mechanism which is different from the replacements one<g> See LoadReplaceList in gdi/freetype.c

You need something like this:

[HKCU\Software\Wine\Fonts\Replacements]
"Marlett"="Wine Marlett"

That would work if the Wine fonts end up in the Windows dir, but aren't they likely to get installed into somewhere under /usr/share/fonts ?

Also, I like the versioning thing, it lets me have the ms webfonts under /usr/share/fonts and have /win/winnt/fonts in my fontconfig path. This way, if my Windows partition has a newer version of Arial than the ms webfonts I get to use that, rather than it being on a first come first serve basis.

Can't we just add the Replacement keys to wine.inf and be done with it?

Attached is a fairly sizable patch that revamps the way Alsa initialization is done. With this patch, Wine now does the following: scan all cards given by Alsa (not brute force 0-5), respect alsa defaults and environment variable overrides, probe to see if a reported Alsa device is useful (e.g. strip my Modem from the list of reported sound cards), and provide a mechanism for an end user to explicitly configure Wine to use Alsa.

The default configuration values should 'just work' in most cases, but the following registry values are permitted to provide finer control:

** [Software\Wine\Wine\Config\ALSA]
** AutoScanCards Whether or not to scan all known sound cards
** and add them to Wine's list (default yes)
** AutoScanDevices Whether or not to scan all known PCM devices
** on each card (default no)
** UsePlugDevice Whether or not to use the plug:hw device,
** which automagically handles rate conversion (def yes)
** DeviceCount If present, specifies the number of hard coded
** Alsa devices to add to Wine's list; default 0
** DevicePCMn Specifies the Alsa PCM devices to open for
** Device n (where n goes from 1 to DeviceCount)
** DeviceCTLn Specifies the Alsa control devices to open for
** Device n (where n goes from 1 to DeviceCount)
**
** Using AutoScanCards no, and then Devicexxx info
** is a way to exactly specify the devices used by Wine.

I'd appreciate anyone passionately interested in Alsa (Kevin? Robert?) taking the time to try this patch.

I've tried to 'do no harm', but this is a material enough change that I'm not yet comfortable submitting it to wine-patches.

fwiw, there is a (fairly thin) thread on the alsa dev lists regerading this here:

http://sourceforge.net/mailarchive/forum.php?thread_id=7452725&forum_id=1752

In ALSA_TestDeviceForWine, the call to snd_pcm_open blocks if I have any applications currently using my sound card, and does not complete until all other apps accessing alsa close, effectively freezing wine mixing is not supported on my card, so only one application can open hw at a time, all others will block on snd_pcm_open it does, however, work with

[ALSA]
"AutoScanCards"="n"
"DeviceCount"="1"
"DevicePCM1"="default"
"DeviceCTL1"="default"

Sound card is standard AC'97 that comes with nForce4

# lspci -v -s 00:04.0
0000:00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
Subsystem: ASUSTeK Computer Inc.: Unknown device 812a
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 22
I/O ports at dc00
I/O ports at e000 [size=256]
Memory at d2003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2

The sound card is in use by the dmix/dsnoop plugin. my "default" device is actually a chain of plugins, a striped down version of my .asoundrc is (let me know if you want my full config)

pcm.output {
  type dmix
  slave.pcm "hw:0,0"
}
pcm.input {
  type dsnoop
  slave.pcm "hw:0,0"
}
pcm.duplex {
  type asym
  playback.pcm "output"
  capture.pcm "input"
}
pcm.!default {
  type plug
  slave.pcm "duplex"
}
ctl.!default {
  type hw
  card 0
}

so default goes through asym, which joins dsnoop and dmix, which then actually access my hardware.

This is a pretty common config for cards that do not support hardware mixing, IMO.

I have another 'fun' and useful project to add to the list.

It should be fairly to make wined3d (or d3d8) use the wgl (windows opengl) instead of glx. (just search for glx commands and replace then with the wgl equivalents)

Doing so would enable Wine's d3d to run on windows in place of the windows driver and without the rest of Wine which would greatly help in debugging.

It would also allow wined3d to use the wgl implementation in Wine.

Didn't one of the video card makers experiment with something like this at one point, translating all Direct3d calls into OpenGL and just writing OpenGL-optimized drivers (or perhaps vice-versa)?

We're working on setting up an environment to cross-compile a winelib application (initially from x86 linux to sparc solaris). To do this, we need a cross-compiling version of winebuild which will generate the assembly code for the target architecture instead of the build architecture.

I see two basic ways we can accomplish this. We could either use autoconf's --target flag to specify the target architecture, and then replace all of the "#ifdef __sparc__" statements in winebuild with "#ifdef __target_arch_sparc". I came across an autoconf macro (http://autoconf-archive.cryp.to/ac_create_target_h.html) that would generate the appropriate defines.

The other way we could approach the problem is to modify winebuild to always generate assembly code for all of the architectures, pushing the #ifdefs down into the .spec.c file.

I'm inclined to stick with the first option, since it looks like less work and less chance of introducing errors, but I wanted to run it by the list before starting work. Would a patch like this be accepted into wine? Do you know of any other gotchas we should be aware of?

I think the right way is to get rid of the #ifdefs, but not by pushing them into the .spec.c file but my making the target a run-time option. I've been meaning to do this for a while now, I was just waiting for someone to actually need that feature ;-)

Over the past few weeks I have been experimenting with SVK and Subversion managing a handful of branches to Wine CVS, and it appears to be working well. The system is based on a "central" Subversion repository that mirrors the Wine CVS tree without any modifications (publicly readable at svn://wine-svn.troy.rollo.name/wine/wine/) and is kept up to date within a day or so.

Branches are stored in separate Subversion repositories.

I am finding this very convenient. If you have converted from CVS to Subversion on other projects, you are probably aware of the huge difference it makes. Adding SVK on top of Subversion is another giant leap when you have distributed development. In the case of Wine, however, with the CVS repository being read-only except to Alexandre, the difference between read-only CVS and the combination of Subversion and SVK is even more dramatic (I would compare it to the difference between chiselling documents into stone tablets and using a word processor).

For anybody who is interested in moving their own Wine development to Subversion and SVK, there is a page on the Wiki describing what to do at http://wiki.winehq.com/SVK.