Wine Traffic #276 For 27 May 

By Brian Vincent

Table Of Contents

Introduction

This is the 276th issue of the Wine Weekly News publication. Its main goal is to miss deadlines. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 207 posts in 750K.

There were 69 different contributors. 39 posted more than once. 27 posted last week too.

The top posters of the week were:

1. MSHTML & Mozilla & XEmbed

24 May  (3 posts) Archive Link: "XEmbed embeder support in Wine"

Topics: Integration

People: Jacek CabanMike Hearn

As we mentioned last month (see WWN #268 (http://www.winehq.com/?issue=268#MSHTML%20Work) and #271 (http://www.winehq.com/?issue=271#MSHTML%20&%20Gecko) ), Jacek Caban has been busy implementing MSHTML on top of Mozilla. MSHTML.DLL is a massive chunk of Internet Explorer; it's responsible for parsing and rendering HTML. His first round worked with the Windows version of Mozilla, now he's try to wrap the Linux version. This week he asked on wine-devel how to proceed with a native Linux Mozilla:

As I'm working on getting MSHTML to work using Linux Gecko, I need support of XEmbed embedding in Wine. It can be also useful for Winelib applications (and maybe in future for some other parts of Wine) to show the X11 windows in Wine. My current version of XEmbed patch and a simple test application that creates gtk button inside Wine window is attached. Using this patch I can display Gecko in the Wine window (now only in my test application, but I'm working on integrating it with MSHTML).

The way I want to do it is:

  1. Wine application creates window of "_XEMBED" class
  2. Embedding window can be done in two ways (as in specification):
    • Wine application sends _WM_ATTACH_WINDOW message passing X11 Window (not yet implemented)
      or
    • Client window is created as a child window of Wine window
  3. Window is displayed and Wine communicates with X11 window using XEmbed protocol

I know my patch needs some polishing and more implementations (focus, activating, handling unmapping of window....), but I'd like to know if the way I do it is proper? What needs to be done for the first patch to be accepted?

Mike Hearn pointed out a huge problem with doing this:

How does this work if the app wants to embed an X window as a child win32 window? We no longer map child win32 windows to child X windows since the WM rewrite so there's nothing to embed into.

Jacek and Alexandre had a discussion on irc and it appears with more work that xembed could be supported. It seems like one of those things you can't find out the answer to unless you try.

2. Video Driver Infrastructure

21 May  - 22 May  (2 posts) Archive Link: "qcap/avicap and driver models"

Topics: Architecture

People: Maarten LankhorstEric PouechRolf KalbermatterReactOS

Maarten Lankhorst wondered about how designing the driver infrastructure for his new video capture code:

I implemented a driver model in qcap now, but avicap32 still uses my old #ifdef LINUX_VIDEODEV_H, since some people might be interested in writing capcreatecapturewindow, I think we should move out the drivers from qcap to our own vfwwine dll/driver, windows uses a similar model for it, as Rolf Kalbermatter pointed out in http://www.winehq.com/?issue=274#Video%20Capture%20in%20Windows (http://www.winehq.com/?issue=274#Video%20Capture%20in%20Windows)

For the qcap drivers, I used some kind of COM model

First, it tries to initialise, and lets the constructor function fill this struct, then if something is needed, it just calls Capture->SetFormat(Capture->pMine, parameters..), this is the qcap implementation, but I'm sure that if I write some parts of it so it will be DirectShow indepent, it can be used by avicap and qcap, I'm not really interested in avicap, but in the very least capgetdriverdescription should use the same code as qcap, because writing the same twice would mean a huge overhead.

So basically, I'm just wondering what to do, should I go ahead with the separate driver dll or should I do something else?

Eric Pouech described how the driver infrastructure should work:

drivers should be written as follows:

  1. since it's wine specific, its name should start with wine (so winevfw or whatever)
  2. the driver shall be a driver for both avicap and qcap DLL
  3. interfaces to the driver should be the regular windows' ones (fetch information on avicap driver interface, as well as DShow driver interface - DDK info on the Web are your friend)
  4. a single driver shall be provided for all possible unix interfaces (you can start with v4l of course) and shall

Item #2 has the following benefits:

Item #3 has the following benefits:

Item #4 has the following benefits:

BTW this is what has to be done for the audio/midi drivers (where 1, 2, 3 are already done, and 4 is missing)

3. Unaligned mmap()

21 May  (1 post) Archive Link: "[RFC] upmfs - page-unaligned mmap() for Linux"

Topics: Memory Management

People: Dan Aloni

Dan Aloni of coLinux (http://www.colinux.org/) fame wrote to wine-devel about an idea he had concerning unaligned mmap:

I'd like to bring this to your attention and review, hopefully to spawn some constructive discussions. The code was a result of experiments I've been doing lately concering some new idea not especially related to WINE.

To quote myself from http://wiki.winehq.org/UnalignedMmap:

Large majority of PE executables have sections that are page-aligned in memory but not in the PE file image. Linux's mmap() doesn't support mappings that are not aligned to page boundries with regard to file offsets. Currently it forces wineserver to fake mmap() by allocating anonymous pages and using read() to load the sections.

In dlls/ntdll/virtual.c, comment above map_file_into_view() says: "Linux kernels before 2.4.x can support non page-aligned offsets, as long as the offset is aligned to the filesystem block size. This is a big performance gain so we want to take advantage of it."

These days are long gone, we are now using Linux 2.6, and it doesn't support unaligned mmap().

Enter upmfs. This simple kernel module exports this function to userspace using '/proc/index.html':

Given an fd and an offset, a new fd is returned. Using mmap() on that new fd, the mapping will be aligned with the given offset, which can be smaller than PAGE_SIZE.

A wineserver implementation can check the existance of that module in the kernel (i.e "/proc/upmfs/interface/index.html" exists) and use its functionality.

The code for the upmfs source package is attached (http://www.winehq.com/hypermail/wine-devel/2005/05/att-0763/01-upmfs.tar.gz) to this post.

4. Cabinet.dll: File Creation Interfaces

21 May  (2 posts) Archive Link: "Work being done at the File Creation Interface of Cabinet.DLL"

Topics:

People: Gerold Wucherpfennig

Gerold Wucherpfennig wanted to let everyone know he was working on cabinet.dll:

I just want to let you know that I'm working at the FCI functions of CABINET.DLL. I had a look at this a few years ago, but gave up soon. Two weeks ago I made a new attempt and next weekend I should be able I post a patch which implements all FCI functions and will work with spanning cabinets. Real file compression will not be implemented at that point of time as I still have to write missing parts and complete error handling first. This work took me longer than expected so let's see if I can adhere to my schedule.

5. DWARF2 Debug Support

21 May  (4 posts) Archive Link: "Re: dwarf2 support progress step 4"

Topics: Debugging

People: Mike HearnLionel UlmerRaphael Junqueira

Raphaël Junqueira did a lot of work to enable Wine's debugger to understand the DWARF2 debug format. Mike Hearn wondered exactly how Wine would benefit, " What exactly will this work allow - will winedbg get better as a result? At the moment backtraces already give function information..."

Lionel Ulmer replied, " >From what I know, this will allow to build Wine without the -gstabs+ compilation flag. Ie Wine will understand the new (standard) DWARF2 debugging symbols. "

Raphaël confirmed that's the case:

dwarf2 debug format is the standard format since gcc3 (and dwarf3 format which is a dwarf2 extension already specified so gcc4/5 may use it).

Stabs format (use when -gstabs+ option is used) is only supported (without any evolution) for backward compatibility with olders debuggers.

If you want to get maximum debug info of recent gccs ou must use dwarf2 (and prepare for the future when stabs format won't be supported)

6. Standalone Tests

24 May  (4 posts) Archive Link: "question about standalone tests"

Topics: Testing

People: Kees CookAlexandre JulliardDan Kegel

Kees Cook wanted to know why some changes were made to some tests he submitted:

Hi! My crypt32 protectdata tests were just added to CVS (thanks!) but they were added without the #ifndef STANDALONE stuff that exists in the recommended example from the lzexpand test code. The steps here:

don't have a method for doing the build with the free-of-charge windows CLI compiler (which the "STANDALONE" stuff works fine with).

Is there some new way to build standalone tests, or should I send a patch for re-including the #ifndef STANDALONE stuff for the tests?

Alexandre explained how tests could be built as standalone without the #ifndef:

You should be able to build by simply copying over wine/test.h, it's supposed to compile with MSVC too. If it doesn't this should be fixed. There's no reason to add special magic in every test file for that.

Kees thought the lz tests should be updated as well since they're frequently cited as an example of how to create tests. Dan Kegel found some problems with copying wine/test.h and Alexandre promptly submitted some changes to fix it.

7. MSI Dialogs

26 May  (1 post) Archive Link: "msi dialogs, events and office 2003"

Topics: MSI

People: Aric StewartCodeWeaversMike McCormack

The work on MSI has been ongoing for a while now. Aric Stewart and Mike McCormack gave nice presentation at WineConf about getting involved and how to go about doing work on it. After some discussion this week, Aric dropped a large patch and announced:

We have been concentrating alot of effort on Office 2003 and specifically on getting office 2003 to install and come up properly. We would love to work more directly with you and the whole Wine community in this goal.

With this patch I have enabled the dialog code that Mike has put into Wine and started a basic structure for handling ControlEvents sent to and from various dialog controls. Alot of this code is still pretty hacky and incorrect but the basic functionality and structure is there. It also should allow you to actually start installing Office. With the current CVS tip Office2003 fails to install due to actions relating to MSXML failing but that is where our effort is now focused. You can get around that by changing the ACTION_ProcessExecSequence(package,FALSE) in ACTION_ExecuteAction() to ACTION_ProcessExecSequence(package,TRUE), then at least Office 2003 will be able to install its basic functions and come up.

We here at CodeWeavers are constantly trying to work closer with the Wine community. I am bad about keeping up on wine-devel, so you can always e-mail me directly with MSI related things, and i know Mike McCormack and a number of other are very good at keeping up on the mailing list. I also hang out in the irc channel quite a bit.

With some work and some luck we should be able to get office 2003 looking pretty good.

8. New Wine Doc Requirements

26 May  (1 post) Archive Link: "Winedocs and Po4a dependencies"

Topics: Documentation

People: Francois Gougetcvs

The recent move of the docs to SourceForge along with the new internationalization changes might have raised the barrier to entry a bit. Francois Gouget dropped an email this week outlining some of the changes and how things have changed:

For the Wine project we are trying to make it as easy as possible for Wine contributors to modify and rebuild the Wine documentation. The Po4a dependencies have caused some concern in this regard: for each dependency the contributor will have to track down which package to install for his distribution and this makes the initial setup significantly harder.

Po4a being not very widespread we have checked it in the Winedocs CVS (http://cvs.sourceforge.net/viewcvs.py/wine/docs/). But Po4a has quite a few dependencies so this does not help very much. So now we are hoping to make it possible to reduce the number of po4a dependencies. Here is the list I came up with, together with some notes for each of them:

 

 

 

 

 

 

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.