Wine Traffic #13 For 18 Oct 1999

By Eric Pouech

Table Of Contents


This is the thirteenth 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).

Well, this week has also been very calm here on wine-devel, like previous week. Fortunately, patches keep making their way to wine-patches.

Mailing List Stats For This Week

We looked at 32 posts in 104K.

There were 21 different contributors. 6 posted more than once. 10 posted last week too.

The top posters of the week were:


1. Mouse wheel
 Archive Link: "Mouse wheel"
People: Noomen HamzaOve Kåven

Noomen Hamza submitted a patch to wine-patches regarding mouse wheel support in wine. Noomen goal was to
include WM_MOUSEWHEEL within wine and process this message to scroll some controls

Ove Kåven also reported he started working on the same issue, but had some remarks about Noomen's work. Especially, Ove was concerned if
WM_MOUSEWHEEL should be considered a keyboard message (it follows focus, after all), or mouse message, or something else, in message.c and queue.c
. Noomen's patch made it a mouse message, whereas Ove was more willing to make it a keyboard one.

Noomen was happy with the result he had (spinning the wheel made controls behave correctly), whether Ove was more concerned with implementation correctness. Let's assume that the merge of both their work will benefit those two points.


2. Executable version detection
 Archive Link: "Executable version detection"
People: Jürgend Schmied

Jürgend Schmied sent out for review an enhanced algorithm to detect automatically the windows' version needed to run a given binary. Note that this is not related to the bug some people experienced with latest wine 19990923.

So, here's the proposal:
First, there is no save way to detect the windows version a program is expecting. However some hints are allowing to guess the version a program needs.
  • First the version detection looks onto the native dll's provided. This is necessary since most programs are able to run on win95/98 as well as on nt4. The native dll's are not that tolerant.
  • The most important information is the subsystem version (pe-exe- header). If this version is >=4 the executable is a 'real' (not win32s) program. This value is constant for all subsequently versions of windows (win95/98/nt4/nt5).
  • Unfortunately there is no documented way to detect if a given set of native dll's and a program is a win95/98 (ascii) or nt4/5 (unicode) version of the program. I solved this by looking into the import-table of the native dll's. All system-dll's (comctl32, comdlg32, shell32, ole32) are importing the ntdll. Any try to distinct by any fields in the pe header or by the version resource does not work.
  • for nt351 the field Major/MiniorOperatingSystemVersion contains a usable value (3.51)

Drawbacks of this method:
  • There are executables written to run under win31 and win95 detecting the windows version and _then_ loading special dlls taking advantage of the features of win95. Since these programs are not linked statically against any native win95 dll the windows version is detected as win31.
  • If you running a nt-program without any native dll provided the windows version is based on the subsystem number of the executable set to win95. Mostly effected by this are the native applets of nt. All other programs I tested with are written to run on win95 as well as nt4 and running fine.

    For this (rare) cases you still have to set the -winver flag.







We Hope You Enjoy Wine Traffic

Kernel Traffic is hosted by the generous folks at Tux.Org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.