Wine Traffic #10 For 27 Sep 1999

By Eric Pouech

Table Of Contents

Introduction

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.

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:

1. Stock fonts information

 Archive Link: "Stock fonts information"

People: 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:
  1. the first one, as an extension of Francis' proposal, would query the actual height using GetTextMetric()
  2. 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 accordingly.

Francis acknowledged that solution (2) was the
Right Way (TM)
to do it, but that he would rather implement solution (1) because it's easier to implement.

2. Clipboard behavior

 Archive Link: "Clipboard behavior"

People: 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 Write.

Noel Borthwick explained this behavior is how the current clipboard code has been designed:
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 Wine.

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 this behavior.

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.

Dave Elliot proposed to add
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 selection.

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.

3. Cvsdate new release

 Archive Link: "Cvsdate new release"

People: 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:
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.

The latest version can be grabbed at http://www.westfalen.de/witch/cvsdate.tgz (http://www.westfalen.de/witch/cvsdate.tgz)

Cvsdate is (currently) not part of wine source tree.

4. The Vineyard

 Archive Link: "The Vineyard"

People: Adam Sacarny, , News

Adam Sacarny installed on Winehq a prototype of "The Vineyard", an extension of Winehq
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 sections.

You can find it at:

Feel free to send your comments to Adam (mailto:magicbox@bestweb.net)

5. Porting to BeOS (cont'd)

 Archive Link: "Porting to BeOS (cont'd)"

People: 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:

OS Kernel space Shared memory User space
BeOS 0x00000000-0x7FFFFFFFF 0x80000000-0xFFFFFFFFF
Windows 9x 0xC0000000-0xFFFFFFFFF 0x80000000-0xBFFFFFFFF 0x00000000-0x7FFFFFFFF
Windows NT 0xC0000000-0xFFFFFFFFF 0x00000000-0xBFFFFFFFF

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:

 

 

 

 

 

 

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.