Table Of Contents
|2.||Executable version detection|
IntroductionThis 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:
Archive Link: "Mouse wheel"
People: Noomen Hamza, Ove Kåven,
include WM_MOUSEWHEEL within wine and process this message to scroll some controlsOve 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.
Executable version detection
Archive Link: "Executable version detection"
People: Jürgend Schmied,
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.
Drawbacks of this method:
- 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)
- 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