Wine Traffic #192 For 17 Oct 2003

WHAT'S NEW with Wine-20031016: (see ChangeLog for details)

• Support for the Xrandr extension.
• Dll separation of kernel and ntdll is finished.
• Many enhanced metafile improvements.
• Lots of bug fixes.

My version of Xrandr doesn't need Xrender so I hoped it wouldn't be needed, guess I was wrong.... what does it need Xrender for?

The problem with the dependency is that currently we deliberately don't link to libXrender but load it dynamically so that it works on all platforms; so I guess we'll need to load libXrandr dynamically too.

Dimi, when you are debugging a game and have your desktop change resolution all the time, trust me, you NEED a way to easily disable it.

So, well, if you do not like the config file option, please AT LEAST put it as a registry key (I would hate to always have to change my Wine tree to disable it in the code itself).

One more thing I noticed about resolution changing:

Sometimes a program running with Wine terminates without cleaning everything up. When XVidMode is used to switch resolutions, the user can use ctrl-alt-plus/minus to restore the resolution.

Those don't work when the resolution was changed with RandR. A user would need to run

xrandr -s 0

to restore it. Since that may be hard for some to remember, is it worth including a trivial Winelib program that does the same thing? ChangeDisplaySettings(NULL, 0); is all it needs to do to restore the default mode.

I have been testing using a simple program that puts up a dialog box listing all the modes and lets you choose them. Is that worth including somewhere/merging with winecfg?

As some of you might know I am working on a Wine Start menu, for Linux.

I have heard different things on this list about the way Windows treats the start menu.

Some told me that it would be better to make a Windows (wine) client that reads the actual start menu by querying a Wine dll, while others told me that this is not neccesairy as all the links are contained in the Start Menu directory.

From looking at my Windows installation, I must agree that it seems that all items in Programs are indeed in the Start Menu directory.

So, my question is: would it be enough to create just a Linux program that synchronizes with this directory? Can anyone give me an example of a lnk file that IS actually missing in a Start Menu directory, but is there in his Program folder in the Windows start menu?

Does anyone know how far people came at parsing the lnk files for Linux? I read something about the .lnk format, but I don't really feel like writing my own link file parser ;-). Does anybody know of parts of other software that could be recycled here?

my guess is that, eventually, some fancy feature will be lacking unless wine/winelib is brought into the picture, for example, control-panel, "My Computer" or context-sensitive right-click menu-actions, the fancy docking capability of Windows Media Player 9, etc. One thing I do know for sure -- those don't /have/ to be .lnk files in there... they could be .exe's or .mp3's or whatever, and in Windows, "the right thing" would happen....

That is not to say that a rational cost/bene analysis will not ultimately favor a pure-linux implementation, depending on where your code is going.... but my bias would be towards a wine/winelib implementation. Do you forsee this code going into wine or into kde/gnome, or remaining as a separate thing? What relationship would you like between your code and wine's "explorer.exe," once it has one?

Codeweavers has done a lot of work with shortcuts & menuitems, to make them work with different distros... so they might know what some of the nitty-gritty details are (Unfortunately, I do not). You may also want to look at LiteStep, ReactOS's explorer, and other windows shell-replacement software for clues.

Since I want the menu to really integrate into your Linux environment, this would be a Linux executable. I guess than that if I'd want to query Wine for the needed links, that would have to be in a Wine executable. The problem is that this seems a bit of an overkill:

• I'd have to write a communcation protocoll between the Wine app and Linux app
• A wine process would always be running, just for serving the menu. Killing your wineserver (what I personally like to do often :-)) would kill the start menu server too... It would take some fancy programming to get it back up again without the user noticing it (i.e. without some horrible crashing of the Linux client ;-))

Therefore, I would prefer to write just a number of Linux apps, one for each desktop environment. Maybe some could be merged together.

In the current setup, an abstract menu is kept as a datastructure in which the menu items are stored. So, for the different Linux desktop environments, only the very frontend of the application would have to be rewritten.

It's probably easier to just go with the link file reader first, but it will have some limitations:

1. you won't be able to get stuff in the shell namespace (eg. desktop icons, Control panel stuff)
2. you'll have to hardcode the location of the start menu (you can change the location of the start menu by playing with registry keys... see SHGetSpecialFolderLocation).
3. you'll have to duplicate the code to read .lnk files (see dlls/shell32/shelllink.c), and the code to read the icons from .exe files
4. if you want to support adding other stuff (eg. a .txt file) to the menus, you'll have to read the registry to get the right association, to pull the right icon from an exe.

I guess that's not too much of a problem, and it's probably not worth the effort to make it perfect.

The code that wine Crossover uses to generate KDE/Gnome menus is already merged into Wine. We just have a more extensive wineshelllink script that deals with more corner cases.

Some games that worked pretty well in Wine (like, for example, Tomb Raider 3) are now failing with latest CVS due to :

Unhandled exception: privileged instruction in 32-bit code (0x0048e2e1).

So I was wondering what changed in the Wine code that suppressed the emulation of these instructions.

What changed is that emulation of these instructions was deliberately removed ;-)

This was done for dll separation reasons, and because they are not emulated under NT either (which also means better performance for the exception handling). What happens if you run with Windows version set to NT?

This is a first patch to let Wine run on either an NPTL enabled or not system.

The remaining issues deal with linking ntdll to libpthread, and autodetection in configure.

It's not production-ready yet, I'm aware that there are a couple rough edges (ie, nptl_check passing from libwine to ntdll, wine_pthread_init_(process,thread)_no_nptl, what really happens if run on a system without NPTL).

It's been tested on RH9 with NPTL.

I might as well point out (as I didn't find this intuitive when I was learning) that you do that like this:

1. Open up a new terminal window
2. Run winedbg
3. "walk process"
4. Locate the win32 process id of the program that has deadlocked
5. "attach X" where X is the pid
6. "bt 0x9" gives you a backtrace of thread 9
7. "bt 0x15" gives you a backtrace of thread 15 etc....

Then you can see what path the code took before it hit the locks.

I have just sent a post to the openssl list trying to solicit any developers of openssl-based win32 programs to try their programs under Wine. Eric Pouech helped me recently by fixing the one or two glitches in Wine that the openssl libs and utilities were stumbling on, and so openssl seems now to pose no problems for Wine. Anyhow, I just thought I'd post a link to this 'openssl-users' thread in case there's anyone else interested in this (in particular, if you think I've misrepresented anything about Wine or the process of testing win32 applications under it, feedback would be welcome);

http://marc.theaimsgroup.com/?l=openssl-users&m=106626702426381&w=2