Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Wine Traffic #16 For 8 Nov 1999

By Eric Pouech

Table Of Contents


This is the sixteenth release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 85 posts in 281K.

There were 34 different contributors. 19 posted more than once. 19 posted last week too.

The top posters of the week were:

1. Threads and WineLib

 Archive Link: "Threads and WineLib"

People: Mel GormanOve Kåven

Mel Gorman reported some issues while using WineLib:
I'm writing a plugin for XMMS for playing VQF's using WineLIB and windows DLL's. I had a nice amount of success in getting a plugin to work but I had to separate XMMS and the plugin into two separate programs which is kruddy as hell. When I try to merge them together, there is segfaults every direction when the windows dll tries to thread. I'm fairly sure that it's due to the difference in how pthreads (used by XMMS) does threading and how Wine does it's own threading with clone.

Ove Kåven replied:
The issue is simple: for two threaded systems to be compatible with each other, they should use the same thread primitives. This has thus two solutions:
  1. Make Wine use pthreads. Time and time again it has been discussed and argued that pthreads is generally not compatible with win32 threading, so cannot be used for the binary emulator at least. It could conceivably be used for pure Winelib if the binary compatibility part is disabled, but I don't think anyone have bothered. (Besides, it seems you are doing this for the binary compatibility, loading win32 dlls)
  2. Make XMMS use Wine threads, but it doesn't sound likely to be an option, since this is a plugin.
I think you have to stick with separate processes for XMMS and Winelib to accomplish what you want.

Note: VQF is another format for compressed audio, and a possible (better ?) replacement for MP3. For more on the VQF plugin for XMMS, you can also check Mel's project page.

2. Wine integration into Unix/X11

 Archive Link: "Wine integration into Unix/X11"

People: Eric PouechGavriel StateJürgen Schmied

David Grant from Corel submitted a patch that would better integrate KDE look'n'feel inside Wine. It would allow to display every window with a KDE look'n'feel (even the child ones, which Wine currently only displays with the Windows look, whatever mode (-managed or not) Wine is run with). In details, it implements the KDE (and also Windows 98) gradient on windows' title bar, the menu tracking, use of KDE system colors for Wine defaults.

Eric Pouech disagreed on the approach:
Have you thought 2 seconds of what it would mean to mimic every WM on the field in Wine ? You've started with KDE, we could add Gnome, mwm, fvwm, ice, CDE, <put here your favorite WM>... The code would be an utter mess. And not maintainable, needless to say. For example, are you sure that KDE will always keep the same gradient, even in KDE 2 ? if not, you'll have to integrate another tweak for KDE2... :-(

There are of course parts that can be applied as it is (like gradient for caption), but, unless we provide a cleaner way to better integrate a WM look (and perhaps feel) into Wine, I fear that your patches would cause more harm than good.

Gavriel State (Corel) answered:

Yes, ideally we would be able to modularize more of the 'chrome' code so that it would be easier to write additional modules to support the various different looks that people might want (Gnome, mwm, KDE, Win31, Win2K, etc). Right now though, we (Corel) don't have time to spend on this. We're concentrating on the KDE look primarily because KDE seems to be the most popular desktop WM, and we anticipate that it will continue to be for quite a while. Even if it doesn't look 100% right for KDE 2 (or KDE with themes), it's still better than the Win95 look for MDI windows for what we're working on.

Something else to consider is this: there is a potential copyright issue with the Windows look and feel sets - specifically with the maximize, minimize, and close buttons on the Window borders. Better to have at least one look and feel setting that doesn't look exactly like windows.

If Alexandre and the wider WINE community don't want to integrate the patch into the main CVS tree, it's no big deal for us - we mostly work from our own internal tree anyway. If someone else wants to modularize the look and feel code so that it's easier to support new looks (Gnome, mwm, etc), we'd probably be happy to move the KDE look into that structure, but I don't think that we're prepared to do that modularization ourselves at this time.

Jürgen Schmied proposed in order to help this modularization to build upon the existing ownerdrawn mechanism:
Why not plug all drawing functions (win31 and win95 look could be the first two) into the ownerdrawn mechanism? Like if its a real ownerdrawn control send the message and if its one of our internal drawing routines call the appropriate function through a calltable. All structures of the ownerdrawn mechanism could be reused and all the ugly if(style=win31) the do this and if (style=win95) the do that constructs could be thrown out.

The discussion evolved to a wider approach of the integration of Windows applications (run with Wine) into the Unix/X11 environment (having all widgets with a KDE look'n'feel, how to display paths...). Gavriel State gave Corel's view:

3. Wine identification

 Archive Link: "Wine identification"

People: Gavriel StateUlrich Weigand

Gavriel State is looking for a
a clean way to determine if we're running under WINE, and preferably the vintage as well.

He proposed a Wine only extension of return values from GetVersionExA().

Ulrich Weigand proposed:
The TNT toolkit (which allows to run WinNT console apps under DOS) exports a special symbol 'IsTNT' from its version of KERNEL32.DLL, so apps can simply check with GetProcAddress() whether that's there.

We might similarly add a KERNEL32 routine 'IsWine' or so; for extended info that symbol could point to a string containing version info, or even to a routine that could be called to query lots of settings...

No patch has been submitted yet.

4. Of Windows' versions

 Archive Link: "Of Windows' versions"

People: Rein KlazesUlrich WeigandRein Klaze

While fixing some incorrect behavior in edit control in disable state, and finding out that the messages to be sent depend on the Windows's the application is running on, Rein Klazes popped up this question:
Now I wonder how windows can detect that an application is designed for windows 3.1?.

There is currently, three different notions of Windows' version used in wine (from Ulrich Weigand's explanation):

So, to implement correctly the old and new behavior as explained by Rein, Ulrich proposed the following:
First, check VERSION_GetVersion() to find out which Windows version we do emulate; then, behave like that Windows version does.

All this gets even more complicated if we expect Wine to transparently select a Windows version to emulate, so that the executable runs best ...

This thread triggered a set of patches, including returning correct version information for builtin modules.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.