Wine Traffic #67 For 30 Oct 2000
Table Of Contents
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:
- 22 posts in 48K by Alexandre Julliard <email@example.com>
- 15 posts in 89K by David Elliott <firstname.lastname@example.org>
- 10 posts in 44K by Francois Gouget <email@example.com>
- 10 posts in 22K by Juergen Schmied <firstname.lastname@example.org>
- 9 posts in 27K by Martin Pilka <email@example.com>
- Full Stats
, Ian Schmidt, Ove Kåven
21 Oct 2000 - 23 Oct 2000
Archive Link: "COM/DCOM support"
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
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:
Wine rendering engine
24 Oct 2000 - 27 Oct 2000
Archive Link: "wine rendering engine"
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:
Some discussion also covered the licensing issues. Anyway, Greg Haerr
had an applicable solution:
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.
(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.
26 Oct 2000
Archive Link: "Mail sent to wine-devel"
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.
mixing Wine, MS and Unix C libraries
27 Oct 2000 - 28 Oct 2000
Archive Link: "Header files that conflict with UNIX headers"
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:
David mainly agreed on Francois directions and started discussing the
details of the implementation.
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
Then I think we should have three different configurations:
native C library - Unix semantics
This is what we currently have. The WineLib application compiles with
the native (unix) headers, and links with the native C library. The
semantics of all the C library functions is therefore the Unix
semantics: fopen takes a Unix path, does not understand O_TEXT, etc.
MSVCRT C library - Windows semantics
With this solution we provide C headers that are compatible with those
of Microsoft. We provide them in 'include/msvcrt' and the user puts
'-I$(WINE_ROOT)/msvcrt' in his include path. The WineLib application
is linked with a library called 'libmsvcrt.so' in such a way that the
he actually calls the C functions of this library rather than those of
the native C library (playing with the link order and no-sys library
options and such I guess). I say 'libmsvcrt.so' because that's what I
know. Maybe 'libcrtdll.so' would work too. The semantics of the
functions implemented by this library are the Windows semantics: fopen
takes a dos path and recognizes O_TEXT, we implement _beginthread and
'Mixed' C library - Unix semantics
This is an intermediate solution. The semantics is that of Unix like
in the 'native C library' case. But we provide a specially designed
set of headers to ease compilation:
The headers would be in 'include/mixedcrt' and a WineLib application
would link with the native C library and possibly with crtdll if it uses
APIs that have been remapped to one of the CRTDLL_xxx functions.
The important thing here is: 'Unix semantics' plus some compatibility
- macros map things like '_hypot' to 'hypot'
- macros provide replacements for things like _itoa
- macros fake support for 'O_TEXT'
- maybe some macros would map an API to a CRTDLL_xxx function
- provide additional headers like 'direct.h'
- maybe approximate a little bit: map _flushall to sync
Unicode: We should provide the appropriate
prototypes so that it works in the 'MSVCRT C library' case. For the
other two solutions Unicode will not be supported (because of the 2
vs. 4 chars difference).
Thread safeness: Again the MSVCRT solution should
be thread safe because it is on Windows. For the other two it all
depends on the native C library, i.e. it's most likely not thread
- This scheme leaves the door open for adding other C library
implementations. If Borland has their own slightly different C library
then we add the corresponding headers in 'include/bcrt' and provide
Wine and Win4Lin
27 Oct 2000
Archive Link: "wine & win4lin"
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:
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.
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.
Sharon And Joy