Wine Traffic #10 For 27 Sep 1999
Table Of Contents
This is the tenth 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 19990923 has been released. Here's the changelog summary:
Some changes also occured with version handling (of .EXE and .DLL); if
you encounter error messages regarding version handling, try to run
wine with the -winver XX option (XX being win31, win95, win98, nt35,
nt40), it helps in some cases.
- DIB optimizations.
- Multimedia and OLE DLLs reorganization.
- Many fixes in font mapping.
- Clipboard support improvements.
- Lots of bug fixes.
Mailing List Stats For This Week
We looked at 90 posts in 481K.
There were 38 different contributors.
19 posted more than once.
8 posted last week too.
The top posters of the week were:
- 10 posts in 27K by Ulrich Weigand <firstname.lastname@example.org>
- 8 posts in 31K by Lionel Ulmer <email@example.com>
- 8 posts in 21K by gerard patel <firstname.lastname@example.org>
- 4 posts in 220K by 'Stephane Lussier' <email@example.com>
- 4 posts in 21K by Karl Lessard <firstname.lastname@example.org>
- Full Stats
Stock fonts information
Archive Link: "Stock fonts information"
Francis Beaudet, Richard Cohen,
After the recent changes to the font size handling, Francis Beaudet reported
some issues with some programs (QuattroPro not to name it):
The problem I got is that Quattro gets a stock font handle and
then it uses GetObject to access the height of the font through he LOGFONT
structure. Since the height is set to 0, all the calculations are off and
the display is whacked.
Richard Cohen expressed two properties to be kept for stock fonts:
and proposed two possible fixes:
- Stock fonts are independent of mapping mode
- Stock fonts are proportional to resolution
Francis acknowledged that solution (2) was the
the first one, as an extension of Francis' proposal, would
query the actual height using GetTextMetric()
the second one, would require to modify the initialization
of stock fonts (in device units) and change SelectObject() not to interpret
the size as logical units. Richard also reported that, according to
his tests, this option
is what Windows does (e.g. stock fonts
selected into printer DCs are interpreted as device units rather than
logical units), but this would require the modify the DC_FUNCTIONS
(TM) to do it, but that he would rather implement solution (1)
because it's easier to implement.
Archive Link: "Clipboard behavior"
Jutta Wrage, Noel Borthwick, Dave Elliot, , Jürgend Lock
Jutta Wrage reported some issue she had with recent clipboard changes,
If I copy something from inside Agent into the clipboard, I
cannot copy and paste from xterm into Agent any longer. I always get the
content copied from Agent before, when trying to paste. - Same with
Noel Borthwick explained this behavior is how the current clipboard
code has been designed:
Dave Elliot proposed to add
When you do a copy in your application, it now takes ownership of both
PRIMARY and CLIPBOARD selections. Now when you mark something in
XTerm, Wine loses only
the PRIMARY selection, since XTerm doesn't
support CLIPBOARD selections.When you then try to paste back into
Wine, since Wine still owns the CLIPBOARD selection it takes priority
over PRIMARY, and what you see is the data you previously copied in
We discussed this issue internally and felt that the other alternative
(losing both PRIMARY and CLIPBOARD selections on loss of PRIMARY) would be
even worse. Suppose a Windows user copied something into the clipboard using
Edit | Copy. Now if you were to accidently mark a selection in XTerm or some
other app. This would cause the content of the clipboard to be lost. This
would be pretty non-intuitive for Windows users.
I think one possible resolution to this could be to have some settings in
.winerc to customize Wine's clipboard selection behavior to lose both
PRIMARY and CLIPBOARD selections on loss of PRIMARY, for users who prefer
BTW you won't see this symptom if you copy something into an app which uses
the CLIPBOARD selection. This is because we lose both PRIMARY and CLIPBOARD
on loss of the CLIPBOARD selection.
an option on the system menu to
release the CLIPBOARD selection., and noted that
Netscape uses the PRIMARY selection if you middle click, and the
CLIPBOARD if you select paste. While that would be a great solution, it is
rather un-intuitive anyway, and I think implementing middle-button paste
would be even harder than just allowing WINE to release the CLIPBOARD
In another thread, Jürgend Lock and Noel discussed the causes of a
clipboard crash when copying with the 16 bit winhelp. After
investigation, it turned out that Wine's edit control was the culprit,
because it called 32 bit clipboard functions with 16 bit data, while
it should only call the 32 bit (resp. 16) when handling a 32 bit
(resp. 16) WM_COPY message.
Cvsdate new release
Archive Link: "Cvsdate new release"
Jutta Wrage, , Pavel Roskin
Jutta Wrage announced that she had enhanced cvsdate (first provided by
Pavel Roskin). Cvsdate allows to retrieve a complete source version of
wine by date; this is mainly use to help finding which patch caused a
regression (by a binary search on the data and regenerating wine from
the source tree).
Jutta explains the enhancements:
The latest version can be grabbed at
Cvsdate is (currently) not part of wine source tree.
Cvsdate now fetches a specific version of the tree without any useless
requests on files already existing or obsolete.
If you want to use cvsdate, copy your working copy of the wine tree to
another directory and fetch a cvs log with cvsdate first.
Archive Link: "The Vineyard"
Adam Sacarny, , News
Adam Sacarny installed on Winehq a prototype of "The Vineyard", an extension
website that would be home for News, the daily
builds maintained by me and Jean-Louis Thirot, and TkWine. The major focus
of the site would be News and Discussions, although it would have other news
You can find it at:
Feel free to send your comments to Adam
Porting to BeOS (cont'd)
Archive Link: "Porting to BeOS (cont'd)"
Patrik Stridvall, Ulrich Weigand, , Patrik Stridval
Patrik Stridvall continued his saga about porting Wine to BeOS. His
concern was linked to the address space mapping imposed by the
different OSes between kernel space and user space:
The inversion in user and kernel space between Win 9x and BeOS makes
impossible to load a Windows binary into BeOS' user space (if the
Windows binary uses some knowledge of Windows' user space). Patrik's
interpretation is that applications respecting the following rules
would be able to run on BeOS:
Ulrich Weigand agreed with Patrik. He explained it in details:
- 1/ Don't use strange undocumented Windows API features
- 2/ Don't try do strange operations/tests on pointers
- 3/ Have relocation records
- on point 2,
some Win95 system DLLs do test on
address >2GB as a marker for 'shared space'. Apart from those, I don't think
anyone should care. Any program/DLL that runs both on NT and 95 certainly
won't care. According to Ulrich, Native USER could be one of them.
- on point 3, Ulrich explained that lots of applications have their
relocation records striped (this seems to be default behavior of MS linkers
for "retail" version of executables). This means that the executable can
only be loaded at one peculiar address (the OS' loader cannot "relocate" the
at the bottom of the address space
(4MB or so). Currently under Linux, the address space looks like
What doesn't work currently on Linux is to run two applications
without relocation records: this is one the main reason for address
space separation - see previous releases of this letter.
|ELF shared libs
|PE system DLLs
|PE shared DLLs
Sharon And Joy