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?

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.

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

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

typedef struct capturefunctions {
...
Video_SetMediaType SetFormat;
...
void *pMine;
} Capture;

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?

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:

• it centralizes access to a given kernel resource in a single DLL
• some information between the two types of interfaces may have to be shared

Item #3 has the following benefits:

• you can test the qcap, avicap... DLLs under windows with *real* drivers and see if it works
• we can share all the qcap, avicap... DLLs with the folks from ReactOS
• some braindead programs may look at some (real driver) interfaces for their own use

Item #4 has the following benefits:

• it's up to the driver, at runtime, to find out and setup the existing physical devices
• you don't need to have fancy settings (configuration...), which most users won't understand

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

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

* int mmap_offset(int fd, unsigned long offset);

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" exists) and use its functionality.

The code for the upmfs source package is attached to this post.

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.

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)

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:

http://www.winehq.com/site/docs/wine-devel/testing-windows

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?

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.

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.

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:

• Locale::gettext (perl module)
  Needed by po4a for localization.
  Provided by liblocale-gettext-perl on Debian, perl-Locale-gettext on Mandrake and Fedora Core(DAG), perl-gettext on SUSE.
  
  Would you be open to a patch that acted as a wrapper around Locale::gettext so that po4a would continue to work untranslated if that module was missing?
  The idea we would add a 'Po4aGettext' module that would export gettext() and dgettext() functions. These would try to load Locale::gettext in an eval function and use it if that succeeds. Otherwise the Po4aGettext would simply return the untranslated strings. The only changes to the other Po4a modules would be replacing 'use Locale::gettext' with 'use Po4aGettext'.
• Text::WrapI18N (perl module)
  Pure perl (so easy to check in) but depends on Text::CharWidth which
  is not pure perl. Provided by libtext-wrapi18n-perl on Debian. Found no RPM packages providing it.
  
  Text::WrapI18N was not used in po4a 0.16.2. I initially thought it was used to wrap the text being output to the .po and .sgml files but in fact it seems to only be used to print messages, warnings and errors. Why is it needed? Doesn't a simple print work fine?
• Term::ReadKey (perl module)
  Provided by libterm-readkey-perl on Debian, perl-Term-ReadKey on Mandrake and Fedora Core(DAG), perl-TermReadKey on SUSE.
  
  This module is used to determine the size of the terminal. This information is then used by the wrap functions.
• SGMLS (perl module)
  Needed by po4a to interface with the nsgmls parser.
  Pure perl (so easy to check in).
  Provided by libsgmls-perl on Debian, perl-SGMLSpm on Mandrake and Fedora Core, perl-SGMLS on SUSE.
  
  This is an essential part of po4a. The easiest way to remove this dependency would be to check it into the Winedocs repository. So no action needed on the Po4a side.
• nsgmls (command line tool)
  Needed by po4a to parse the Sgml files.
  Provided by sp on Debian, sgml-tools or openjade on Mandrake and Fedora Core, opensp on SUSE.
  
  This is an essential part of po4a. So it will have to remain as a dependency which is reasonable.