Table Of Contents
|1.||Stock fonts information|
|3.||Cvsdate new release|
|5.||Porting to BeOS (cont'd)|
IntroductionThis 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:
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:
Stock fonts information
Archive Link: "Stock fonts information"
People: Francis Beaudet, Richard Cohen,
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
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 accordingly.
Right Way (TM)to do it, but that he would rather implement solution (1) because it's easier to implement.
Archive Link: "Clipboard behavior"
People: Jutta Wrage, Noel Borthwick, Dave Elliot, , Jürgend Lock
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.
Cvsdate new release
Archive Link: "Cvsdate new release"
People: Jutta Wrage, , Pavel Roskin
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.
Archive Link: "The Vineyard"
People: Adam Sacarny, , News
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:
Porting to BeOS (cont'd)
Archive Link: "Porting to BeOS (cont'd)"
People: Patrik Stridvall, Ulrich Weigand, , Patrik Stridval
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:
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
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
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.
at the bottom of the address space (4MB or so). Currently under Linux, the address space looks like this:
|ELF shared libs||0x4000....|
|PE system DLLs||0x7xxx.... (Win95)|
|PE shared DLLs||0xbxxx.... (Win95)|
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.