Wine Traffic #45 For 29�May�2000
Table Of Contents
This is the 45th 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).
Wine 20000526 has been released. The main changes include:
- New C preprocessor for the resource compiler
- More built-in debugger improvements
- OpenGL support
- Many common controls fixes and merges from Corel tree
- Lots of bug fixes.
Mailing List Stats For This Week
We looked at 128 posts in 317K.
There were 42 different contributors.
23 posted more than once.
26 posted last week too.
The top posters of the week were:
- 17 posts in 33K by Alexandre Julliard <firstname.lastname@example.org>
- 11 posts in 22K by Dmitry Timoshkov <email@example.com>
- 9 posts in 20K by James Sutherland <firstname.lastname@example.org>
- 7 posts in 11K by Dimitrie O. Paun <email@example.com>
- 6 posts in 13K by Patrik Stridvall <firstname.lastname@example.org>
- Full Stats
Improving error messages
Archive Link: "*Much* better error msgs"
Patrik Stridvall,�Andreas Mohr,�,�Francois Gouget,�Bertho Stultiens,�Patrik Stridval,�James Sutherland,�Marcus Meissner
Andreas Mohr made a proposal to modify the Wine's debug messages macro
(TRACE, ERR, FIXME, WARN) in order to make those messages more
readable as well as more portable.
He proposed to:
Lots of people disliked the proposal, firstly for code readability:
Dimitrie O Paun liked to have, in the code, the content of the error
message. Patrik Stridval didn't agree either:
- move error messages text out of the code to a
- add more information to the error case (what should be
done, a list of persons to contact...)
- report a given error only once
- localization of error messages could also be done
So I think that we must instead ask the question:
"What methods should we use to find the existing bugs in Wine?" Trying
to reduce the problem to "How should our error messages look like?" is
Some other liked the idea and proposed to (re)use some existing
tools. Marcus Meissner pointed to gettext GNU tool which shall do
part of the work. Dimitry Timoshkov remembered a Win32 API
FormatMessage that provides part of the needed functionality
(basically parameter positioning). As Francois Gouget noticed, when
translating from one language to another have a parameter index
change: the formating engine has to take care of it.
Anyway, everyone agreed that internationalization of error messages
was not a top priority, and also that there was no need to change
current internal macros, but only, in the few cases, to use
FormatMessage to provide a much detailed (and configurable) error
James Sutherland disliked the idea of implementing this lookup
functionality with a Win32 API. He'd better use a Unix only function,
for portability issues, but also for better control on memory
conditions for example.
But, most of the posters didn't follow James point of view and turned
back his Unix only implementation.
As a conclusion, no more API will be available on that very
subject. Developers can make use of FormatMessage to display nicer
error messages. The only good news is that Bertho Stultiens started
working on a Wine's message compiler. This tool creates the resource
holding the messages table used by FormatMessage.
Archive Link: "Any documentation of prerequisites for OpenGL"
Lionel Ulmer,�,�Uwe Bonnes
Uwe Bonnes asked what are the prerequisites to run OpenGL software
with Wine. Lionel Ulmer gave the details:
The requirements are easy, it's a Linux OpenGL ABI compliant OpenGL
). To summarize, it
- include files gl.h, glx.h and glext.h
- a libGL defining all OpenGL v1.2 + the multi-texture extension
- a libGL defining the function used to query extensions
The known compliant libraries are (I am sure) NVIDIA's OpenGL drivers
and XFree 4.0's default drivers (dunno about the 3DFx DRI drivers
included in XF4.0). I think that Mesa 3.3beta also includes everything
that is needed.
After that, as ALL compliant libGLs are relying on libpthread (as
thread safety is explicitly required by the ABI), you need to force
inclusion of OpenGL (--enable-opengl) (Ed note: while configuring
). This is known to work with glibc 2.1.3 and was failing with
2.0.6 (not tested recently).
After almost ten months of existence (and the upcoming of Wine 1.0),
we think it's time to get some feedback from you, reader of this news
letter. One of its major drawback is that it only covers technical
aspects and is geared towards techies and developers, not end
users. We'll try to improve on this last part by providing two new
types of articles will (hopefully on a weekly basis):
Any contribution on both types is welcomed (if you feel like a
technical write, don't hesitate). If you also have some wishes for the
feature articles, or have other suggestions for this news letter
improvement, just let us now. All messages shall be sent to this
e-mail address (mailto:email@example.com)
feature article: this type of article should cover
one aspect of Wine (address space separation, printing, DirectDraw...)
and give information on: current state, how it's implemented
report of success (or failure): this type of
article would report successful running of some application (and
configuration twists when needed)
Sharon And Joy