Wine Traffic #21 For 13�Dec�1999

By Eric Pouech

Table Of Contents

Introduction

This is the twenty first 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 991212 has been released. The ANNOUNCE reads:

Mailing List Stats For This Week

We looked at 130 posts in 656K.

There were 29 different contributors. 21 posted more than once. 25 posted last week too.

The top posters of the week were:

1. Porting to OS/2 (Odin project) and C/C++ flame-war

�Archive Link: "Porting to OS/2 (Odin project) and C/C++ flame-war"

People: Alexandre Julliard,�Patrik Stridvall,�Sander van Leeuwen,�,�Patrik Stridval,�J�rgend Schmied

This long discussion started with J�rgend Schmied submitting a patch coming from the Odin project to fix some bugs in Win95 file dialog. The Odin (http://www.netlabs.org/odin) project's goal is to provide on OS/2 an execution environment for Windows applications.

Alexandre Julliard rejected it because part of the patch was meant to let code to be compiled by a C++ compiler:
code written in C is meant to be compiled with a C compiler. Making the code more ugly to get it to compile with a C++ compiler is not an improvement.
and asked for only the bug fixes to be included in the Wine tree.

Patrik Stridvall, who already tried to modify Wine code to achieve the C++ compatibility (and mainly to be able to run lint on Wine code) pointed out the known portability issues from C to C++:

Part of the discussion tried to explain the choice of IBM VisualAge C++ has a compiler instead of GCC. The important reasons were spoken out by the Odin folks:

The Odin developers were also willing to share some of the DLLs code with Wine (like the comdlg32, comctl32, shell32...) but keeping their own for the more system oriented part (like USER, KERNEL, GDI..., which anyway have a greater adherence to OS/2, like Wine has with Unix).

Another part of the discussion digressed on the type castings differences between C and C++ regarding maintenance, portability, readability and compiler efficiency (mainly for error pinpointing).

It also seems some reasons for Alexandre Julliard not being willing to commit the Odin changes lies in the potential cooperation between the two projects:
Collaboration between both projects is certainly a desirable thing, and worth making efforts to be compatible; but before we start making such efforts I'd like to see evidence that the collaboration is going to be bidirectional.
and later
the impression I have from your code is that you copy things over from Wine and hack on them to make them fit in your framework. This is of course the fastest way to get things working, but it also causes the code bases to diverge, and makes it much harder to merge things one way or another later on. So before we start modifying Wine to fit your needs, I'd like to see a global concept of how sharing code back and forth will work.

Sander van Leeuwen (from Odin project) answered:
When I mentioned sharing code, I was mainly talking about high level dlls like comctl32, comdlg32, shell32, ole etc. Those are (with the exception of changes/fixes to make them compile in VAC) for the most part identical to the original Wine code. So any bugs we fix in those dlls can be easily ported back to Wine. Assuming of course that we don't have to make dozens of changes per source file in order to make the C++ compiler happy.

Because if we have to, we will only resync with wine with every major release. (as we do right now) It's too much work to keep up with the CVS tree.

Later on, Sander posted the enhancements the Odin team made to some DLLs they borrowed the code from Wine:

We also had to make a lot of changes (again, mostly casts &renaming variables) in shell32, comdlg32 & OLE32/OLEAUT32.

None of the above changes should have any OS/2 specific code, so it should be easy to port them back to Wine.

Sander gave then the name of persons on Odin team who wrote the modifications and asked for WIne volunteers to help synchronizing the trees.

2. Libraries to be used in Wine

�Archive Link: "Libraries to be used in Wine"

People: Ove K�ven,�Alexandre Julliard,�,�Ulrich Weigand,�David Elliot,�Patrik Stridvall

Patrik Stridvall and Alexandre Julliard, while reorganizing the Wine command line parsing, fired up a discussion on libraries required for compiling Wine. Currently, most of command line parsing is done in the X11 display driver and using X11 functions. Patrik is working on having also a TTY only display driver (he reported to have calc almost working in TTY mode - graphical display being done in text mode), so required to move parsing (at least the X11 independent part) away from the X11 driver.

David Elliot proposed to use the (LGPL GNU) popt library.

Ove K�ven disagreed:
using non-standard external libraries (especially ones that cannot be distributed under our license) is only acceptable if we don't depend on them, but only use them optionally. A command-line parsing library would not make sense to use conditionally.

Some other people (Juha Hartikainen, Patrik Stridvall) pointed out the installation troubles when depending (even optionally) on external libraries:

So it seems, that as a rule of thumb, Wine will not require any LGPL library to be able to run and compile. Some features might be available thru LGPL libraries (like Mesa, ncurses...), but those will be optional (and detected at configuration time). Anyway, this is not the current situation, as Patrik is still working on removing the requirement (making it an optional feature) on X11, and, as Ulrich Weigand pointed out, there's a dependency on Xpm triggering quite a few posts on comp.emulators.ms-windows.wine of users complaining of a missing libXpm.

3. Unicode and Win95

�Archive Link: "Unicode and Win95"

People: Alexandre Julliard,�

Christopher Morgan ran into an issue while trying to have Grand Theft Auto 2 run under Wine. Some investigation showed that this program (which is intended to run on Win9x, but not on NT) depends on some odd behavior: it calls CreateEventW (unicode version) and expects to get an error code to get going. Since the program is not intended to run on NT, this is a very strange attitude.

Chris proposed to return the appropriate error code ERROR_CALL_NOT_IMPLEMENTED as Win 95 does when Wine does run in ASCII (non Unicode mode).

Alexandre Julliard was not enthusiast about the proposed fix and said:
If it's confirmed that the application does absolutely depend on this behavior, I'd be tempted to say the app is completely broken and you should complain to the author. Given that such things won't work under Win2K either, we can probably hope to see such brain-damage corrected in the near future.

Now if we really want to make this work, we should add a single check in the specific function that should fail, with a large FIXME and a comment that this should go away someday. I certainly don't want any kind of large scale effort to make all Unicode functions fail under Win95.

More generally, version checks should be strictly limited to the cases where a real-life app depends on the version difference. If we try to support all quirks and differences between Windows version we'll soon have more version tests than actual code. Also in most cases we should IMO make the NT/Win2000 behavior the default, as this is where the Win32 API is heading.

4. Display drivers and objects

�Archive Link: "Display drivers and objects"

People: Patrik Stridvall,�Huw Davies,�,�Patrik Stridval

Patrik Stridvall, in his effort to have a TTY only display driver, started discussing (mainly with Huw Davies), some evolutions on Wine display driver function tables. As an introduction, Wine (almost) allows to select a driver to handle the display (graphics, windowing...) operations. The most known driver is the X11 one, but there are some others, like the TTY driver.

Patrik explained what he had in mind:
SelectObject(), while working properly, has a lot of unnecessary code duplication and insufficient error handling, and this is made even worse by the fact that SelectObject has driver versions for BITMAP, BRUSH, FONT, PEN.

Each version of each driver does approximately the following, I take PEN as example, but BITMAP, BRUSH and FONT has the same problem.

HPEN�DRV_PEN_SelectObject(DC�*dc,�HPEN�hpen,�PENOBJ�*pen)
{
���HPEN�hPreviousPen�=�dc->w.hPen;
���dc->w.hPen�=�hPen

���/*�Do�necessary�driver�preparation�because�of�the�selection
����*�NOTE:�HPEN�is�never�used�for�this�AFAICS
����*/�

���return�hPreviousPen.
}

Notice that
  1. Change of dc->w.hPen is always done in all drivers.
  2. Even driver that doesn't need any preparations for some kind of objects needs an implementation because of 1.
  3. The pen comes as both HPEN and PENOBJ but HPEN is only needed because of 1.

In addition each drivers have implementation of DRV_SelectObject that is basically a large switch and the essentially the same for all drivers. Not that for REGION objects SelectClipRgn16 is done in all drivers which is unnecessary code duplication and not good from a maintenance perspective.

Therefore I propose that
  1. DRV_SelectObject is eliminated and the code moved to the common code.
  2. Change of dc->w.h{Bitmap,Brush,Pen,Font) is done in the common code.
  3. DRV_{BITMAP,BRUSH,PEN,FONT}_SelectObject is renamed to DRV_Select{Bitmap,Brush,Pen,Font) and that each function is added to DC_FUNCS with the following prototype, example PEN: BOOL (*pSelectPen)(DC *dc, PEN *pen) since it in combination with 1 and 2
    • Allows error handling
    • Allows that pSelectPen is NULL which mean that no special preparation is necessary, just change dc->w.h{Bitmap,Brush,Pen,Font).

This will
  1. Make the code more maintainable
  2. Makes it possible for drivers, like the TTY driver, for cases that needs no special preparation to avoid implementing a lot of code.
  3. Allow error handling.

Huw Davies agreed that
the dc->w.hpen stuff should go on in the common code. In fact recently I changed MoveToEx,LineTo etc so that the current position got updated by the common code for the same reason
but was also willing to have a closer look on how the DIB and bitmap handling was split between drivers and common code.

After some more investigation, Patrik reminded
that SetTextColor and SetBkColor have duplicated code in all drivers. This should also be fixed.
and proposed:
DeleteObject should probably be split up in Delete{Bitmap,Brush,Pen,Font} in DC_FUNCS as well, it will have the same advantage as for SelectObject, easier maintenance and lower cache footprint.

In addition perhaps we should have a {Select,Delete}Region.

Patrik also pointed an optimization area in the X11 driver: currently, when a Windows pen (pen is taken as an example, it could be a brush or a font) is created, the corresponding X11 object is not created. The X11 object (or the device object in Patrik's terminology) will only be created when its windows buddy is selected in a Windows's DC. One of Patrik's idea was to create also the X11 (device) objects when their Windows counterparts are created (and hence the need for the delete functions on driver side, for deleting the device object).

But, this triggers lots of new issues, like how to keep the association between Windows objects, device contexts and device objects. Are the association one to one or one to many, can the links be cut at a point in time and restored afterwards. Also, Patrik (after some testing) demonstrated that Windows NT re-realizes (realization is the name of the operation that creates a device object in the display driver when a logical object is, for example, selected in a DC) selected objects when the mapping of the display changes (something that nobody seemed to be aware of, and of course, undocumented).

Then followed a more technical discussion on region selection (and clipping) on metafiles (regular and enhanced), showing in particular that MS did another "bad design" (TM) in this area.

Patrik sent afterwards a patch that implements part of the output of this discussion.

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 kernel.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.