Wine Traffic #21 For 13 Dec 1999
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:
- Registry improvements, including NT files loader.
- DGA 2.0 support.
- Resources in builtin NE modules.
- TTY driver improvements.
- Proxy ODBC32 DLL.
- Still more features in common controls.
- Lots of bug fixes
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:
- 23 posts in 174K by Patrik Stridvall <ps@leissner.se>
- 14 posts in 46K by Huw D M Davies <h.davies1@physics.ox.ac.uk>
- 11 posts in 24K by Alexandre Julliard <julliard@lrc.di.epfl.ch>
- 9 posts in 28K by David Elliott <dfe@netnitco.net>
- 8 posts in 21K by Ove Kaaven <ovehk@ifi.uio.no>
- Full Stats
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 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:
- part of Odin is written in C++ (this is a design choice),
- GCC cannot (currently) output debug information for the OS/2
debugger (mainly IBM's IPMD),
- IBM C compiler doesn't support the extensions needed by Wine
(calling convention, anonymous unions...) whereas the C++ compiler
does.
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.
- OLEAUT32
- Fixes
- Parsing of typelib improved - Several
incorrect pointer problems fixed, esp. start of var table.
- Parameters are returned in allocated buffers.
- ITypeLib::FindName - now returns memberIDs.
- ITypeInfo::GetNames - Invalid use of
pFDesc (should be pVDesc)
- ITypeInfo::GetIDsOfNames - ! missing from
strcmp
- ITypeInfo::GetIDsOfNames - Memory leak.
- ITypeInfo::GetDocumentation - now returns
func & var data.
- ITypeInfo2::GetFuncIndexOfMemId - now
checks typekind.
- New
- Initial cut of IPicture interface
(required for VB apps).
- New loader for TYPELIBs where typelib is
encoded as a resource. (not implemented for multiple resources / dll
yet).
- Known problems (aka work in progress)
- Lib flags are incorrect (win32 returns different values)
- Default values are incorrect
- ITypeComp interface
- Hashing (this affects a lot of apps)
- NTDLL
- arith64: 64-bit arithmetics as used in win32
- COMCTL32
- TreeView: tree with sorted client leafs
- Changed/fixed trackbar, progress, header controls
- USER32
- Changes/fixes for edit, listbox, combo box &
scrollbar controls
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:
- end users have to install them (if they need/want) the feature,
- different versions of the library can produce different
behaviors,
- the library might not be ported on all platforms Wine is
supposed to run on, giving out some other headaches,
- and of course, licensing issues.
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
- Change of dc->w.hPen is always done in all drivers.
- Even driver that doesn't need any preparations for some kind of
objects needs an implementation because of 1.
- 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
- DRV_SelectObject is eliminated and the code moved to the common
code.
- Change of dc->w.h{Bitmap,Brush,Pen,Font) is done in the
common code.
- 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
- Make the code more maintainable
- Makes it possible for drivers, like the TTY driver, for cases
that needs no special preparation to avoid implementing a lot of code.
- Allow error handling.
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.
Sharon And Joy
Mirror provided by HKMirror. Sponsored by Porno Verzameling and webcamsex