Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		Git
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins
 

Wine Traffic #67 For 30 Oct 2000

By Eric Pouech

Table Of Contents

Introduction

This is the 67th 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).

Mailing List Stats For This Week

We looked at 168 posts in 646K.

There were 41 different contributors. 29 posted more than once. 19 posted last week too.

The top posters of the week were:

1. Headlines

 

People: , Ian Schmidt, Ove Kåven

2. COM/DCOM support

21 Oct 2000 - 23 Oct 2000 (4 posts) Archive Link: "COM/DCOM support"

People: Chris Kerslake, James Hatheway, Juergen Schmied, Juergend Schmied, , codeweavers, News

Chris Kerslake asked:
I have been looking for information about COM and DCOM support under WINE and haven't been able to find anything. I have looked through the documentation section and have done some web searches but haven't found anything.

Chris was also looking for hints on how to start adding the missing bits in this area.

James Hatheway gave a partial answer:
The COM that is in WINE currently works pretty well, overall. For example, an app I am currently debugging is basically completely written as COM objects, and it works fine. There are certainly things that are missing, for example out of process and remote servers are not supported yet, a lot of functions are only stubs, I'm sure other people on this list can point other things out to you. A good way to find problems is to grep files for FIXME and stub. Also, DCOM support doesn't exist at all, as far as I know.

Juergend Schmied completed James' answer:
The most important thing currently unimplemented is (IMHO) the uncomplete typelib support (the Invoke function of IDispatch). This makes the use of eg. ocx's without a native oleauth.dll impossible. (This is a quite big part since it would need the typelib marshaller.) A second thing is the IStorage implementation. The creation of temporary storage was incomplete the last time I needed it ;-). Both problems you can easily show with hh.exe.

Anyway, for such questions, good sources of information are:

3. Wine rendering engine

24 Oct 2000 - 27 Oct 2000 (10 posts) Archive Link: "wine rendering engine"

People: Patrik Stridvall, Greg Haerr, , Patrik Stridval, Mark Dufour, Mark

Following previous discussion on graphical engine (see also BROKEN KCREF), Mark Dufour gave a look at MicroWindows, which provides such an implementation.

Patrik Stridvall thought there was some incompatibility between MicroWindows's and Wine's approaches:
Microwindows doesn't really have the same design philosophy as Wine. I have discussed that personally with Greg Haerr (the main author) of Microwindows some year(s) ago.

Microwindows aim towards embedded systems so it rendering engine aims to be small and fast. Wine's rendering engine should IMHO aim to be flexible and fast.

By flexibility I mean that Wine's rendering engine should use the underlying driver, like the X11 driver, if it can do the rendering faster. Note that it often can since the driver can directly or indirectly access the underlying hardware.

Some discussion also covered the licensing issues. Anyway, Greg Haerr had an applicable solution:
Microwindows (Nano-X version) has an option that allows it to be built client/server. This means that Wine doesn't need to be linked with the server, but just with the client libraries, so the server license (MPL alternatively GPL) doesn't apply. Thus, I don't think that there are any problems with creating a version of Wine that uses the Nano-X server...

Mark even got volunteers from the MicroWindows project to assist him on doing the job of integrating both: this would allow to run Wine on a frame buffered display, using MicroWindows rendering engine. Main work would mean rewriting current Wine X11 driver using the MicroWindows API. Even if this would be nice to provide a Windows CE clone for example, if wouldn't solve the first issue (Wine should have its own rendering engine), because of license issues.

4. Mail issues

26 Oct 2000 (4 posts) Archive Link: "Mail sent to wine-devel"

People: Patrik Stridvall, Ove Kaaven, , Patrik Stridval, Ove Kåven, Lawson Whitney

Patrik Stridvall discovered that the wine-devel mailing list had a quota on the size of the post (40k). He wrote:
I understand it is because some people post to long debug logs on the list. But it would be nice if people that are regular posters to the list be removed from the limit or at least have a larger limit.

Ove Kåven answered:
There is no limit to the size of postings to wine-patches, but wine-devel, on the other hand, runs with a 40K limit. This was discussed briefly by web-admin, and nobody there saw a problem with safety limits on the non-patches lists
, and asked whether other people liked to see the maximum size increased.

Not many answers came out, except Lawson Whitney stressing for using compressors (gzip/bzip) when sending large files.

5. mixing Wine, MS and Unix C libraries

27 Oct 2000 - 28 Oct 2000 (9 posts) Archive Link: "Header files that conflict with UNIX headers"

People: Francois Gouget, , David Elliot

Following previous discussions on CRTDLL vs MSVCRT DLL inclusion in wine (BROKEN KCREF) and header handling between the Unix and the Windows one (BROKEN KCREF), David Elliot tried to restart the efforts on those directions.

Francois Gouget gave an overview of what should be done:
Yes, we'll need 'our' C library headers for WineLib programs, one day. I've given some (_some_) thought on that. Here's a dump of how I see things currently. Keep in mind that it will need to be further discussed and refined.

First we must put these headers 'out of the way' so that their use is optional. There are multiple reasons for that the most important being that we still need to be able to get access to the native (unix) headers for compiling Wine. The best seems to be a subdirectory of 'include'.

Then I think we should have three different configurations:

Notes:

David mainly agreed on Francois directions and started discussing the details of the implementation.

6. Wine and Win4Lin

27 Oct 2000 (6 posts) Archive Link: "wine & win4lin"

People: Robert W Hall, Jeremy White, Alexandre Julliard, 

Robert W Hall wrote:
I keep seeing occasional reports that 'wine does not run... on a win4lin-enabled kernel'. Though this is contrary to my experience and sounds like finger-trouble.

Jeremy White gave the start of an explanation:
Actually, it's a fascinating problem - I've been bit by it, badly. Wine works fine with a Win4lin kernel, so long as you build it from source. If you try to take a binary built on a non Win4lin kernel, you get an unhandled exception when your app starts to run, with a problem in the ThunkConnect32 area.

Similarly, if you take a binary that you built on your Win4lin kernel, and give that binary to someone on a non Win4lin kernel, they see the exact same problem.

First, people thought of some mismatch in the header files, but Alexandre Julliard pointed the error elsewhere. Basically, every process on Linux (should be also true on other 32 bit i386 Unix OSes) use the same value for the CS and DS register (32 bit flat model). This value is fixed for Linux (every process gets the same selector value). Current code was getting this value when Wine was compiled. It turned out that a Win4Lin modified kernel and a regular Linux kernel don't use the same CS/DS value, hence most of the issues described earlier on.

Alexandre Julliard provided a fix to get the CS/DS value at run time (instead of compile time), which eliminated the problem.

 

 

 

 

 

 

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.