Wine Traffic #79 For 22 Jan 2001
Table Of Contents
Introduction
This is the 79th 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 109 posts in 370K.
There were 39 different contributors.
23 posted more than once.
22 posted last week too.
The top posters of the week were:
- 11 posts in 31K by Alexandre Julliard <julliard@winehq.com>
- 10 posts in 32K by Francois Gouget <fgouget@free.fr>
- 8 posts in 26K by Jon Griffiths <tntjpgriff@tsnxt.co.uk>
- 6 posts in 21K by Dmitry Timoshkov <dmitry@sloboda.ru>
- 6 posts in 17K by gerard patel <gerard.patel@asi.fr>
- Full Stats
1.
Porting to BeOS
11 Jan 2001 - 17 Jan 2001
(7 posts)
Archive Link: "Interest in a BeOS port"
People:
Doug Clement, Michael Cohen, , Francois Gouget, Patrik Stridvall
Michael Cohen made an old issue resurface. He asked if some effort was
made to let Wine work on BeOS.
Francois Gouget pointed out to some information on the BeWine project:
This subject had already been covered in previous articles (
BROKEN KCREF and
BROKEN KCREF).
However, this effort stopped almost two years ago. Patrik Stridvall
explained the biggest difficulties that couldn't be solved:
- The memory area were applications are usually loaded is not
permitted by the BeOS kernel. This either mean that your application
has to be relocated (some .exe files don't hold the relevant
information to do so - remember the old message about stripped
binaries ?), or that the Wine "emulation" cannot be run properly (but
this shouldn't impact Winelib programs).
One could trap all faulty accesses and relocate them (in the trap
handler) to another area, but this would really slow down the
execution.
- Some other Unix calls were missing from BeOS at that time:
- BeOS doesn't have mmap
- BeOS doesn't have recvmsg/sendmsg (which allows passing file
descriptors between any Wine program and the wineserver)
- BeOS doesn't handle file descriptors and sockets as the same
thing (even if this would be fixed by the BONE (BeOS Networking
Extension) extension
Doug Clement (who was leading the effort at that time) also answered:
Last voice from the list was that we're waiting on BONE, for some
features relating to sockets. To be honest, I've about given up on Be
since it's taken so long to get BONE out, and I'm completely out of
the loop now. I'll happily keep the web site up for whoever wants to
use it, though. Make sure you start with the latest patch we have..
Michael Cohen tried to start up some discussion on helping with the
relocation bits:
I had an idea contemplating the PPC port and I have some preliminary
patches for 20001222 that might affect wine in general. I was
considering one day that a sort of pre-interpretation system could be
implemented, where the entire application is analyzed quickly and then
modified as it is loaded into memory to suit the particular
architecture's needs. I've not seen much in this way discussed on this
mailing list, and I have also not received much input, be it positive
or negative, as far as this idea is concerned.
As I have seen it, the developers of wine have put an immense amount
of effort into understanding MFC and the various quirks of such a
horrible but extensively (almost universally :-( ) used operating
system set as windows is, but I am surprised that the modularization to
bring wine to other systems is not as big of a focus as I thought it
would be upon first taking interest in wine. Wine has come a long way,
but it still needs a bit of polishing before it can become a truly
excellent app.
2.
Porting to S/390
17 Jan 2001
(3 posts)
Archive Link: "Wine for LINUX on S390"
People:
Jim ___doe, Ulrich Weigand, , Francois Gouget
Jim (without a last name but with an email address' domain at
daimlerchrysler.com) asked: has anyone tried
to port Wine to run on LINUX on an IBM mainframe? We are running
several LINUX virtual servers of different distributions and would
like to try running WINE. So far when I run the /tools/wineinstall I
get the error that I must add my CPU CONTEXT to WINNT.H.
Francois Gouget said that, for the time being, it was not possible to
run Wine on S/390, but it could be possible to run Winelib
applications, as long as the basic support was put in (like the CPU
context handling...).
Ulrich Weigand started putting his hands into it:
While I just did a quick hack, I got at least WineMine running.
Now that Winelib is a bit cleaned up (Sparc runs out of the box),
it would probably be not too difficult to properly implement S/390
support, or in fact support for any 32-bit architecture (64-bit is
an entirely different story).
I didn't pursue it further because I wasn't sure there's really
anybody interested in running Wine on S/390. But if you'd like
to try it, I could certainly contribute the arch-specific patches.
[ B.t.w. I'm now working for IBM on the Linux for S/390 port.
That's why I am quite familiar with the architecture ... ;-) ]
3.
Unicode and Winelib
16 Jan 2001 - 18 Jan 2001
(11 posts)
Archive Link: "Winelib + Unicode"
People:
Jonathonm Griffiths, Francois Gouget, , Jon Griffiths
Jon Griffiths, still working on MSVCRT DLL, was trying to make
VWCLworking on Wine (as a strong
user of the MSVCRT DLL). He needed to have a way to define Unicode
string even when the Winelib program (using VWCL) was compiled as a
ASCII one.
However, the standard way of using the L prefix on string fails:
L"foo" is compiled by gcc as a 32 bit Unicode string, whereas a
Windows compiler would generate a 16 bit Unicode string (see
BROKEN KCREF on UTF-16 and
UTF-32). Jon looked for ways of defining UTF-16 properly from Winelib
code.
Francois Gouget suggested two solutions:
- use a bleeding-edge gcc compiler (2.97 and later) which comes
with a
-fshort-wchar flag (this will generate UTF-16
instead of UTF-32)
- use the
WINE_UNICODE_TEXT macro. Good part of it
include:
- it supports both chars and strings, i.e. you can write:
WINE_UNICODE_TEXT('c') as well as
WINE_UNICODE_TEXT("string"). I agree that it's a bit ugly
but I had to do it because that's what they do with
OLESTR in the MFC! In C I believe you will have warnings
(but at least it will compile and do the right thing). You might want to
have two macros instead.
- it will do the right thing when you switch to g++ 2.97,
i.e. it will become
L##x
Jon went further and was upset with the use of
-fshort-wchar flag in combination with standard gcc libc:
Actually, having said that, have you tested
-fshort-wchar? does it require libc to be rebuilt? or
just to build with a different set of headers (i.e. lib funcs still
cannot be used)? My assumption is that it just changes the behavior
of L"foo", and doesn't address the crt issues at all.
Francois replied:
That's right, it does not address the crt issues at all. Actually it
helps a little in that you can use the standard C library headers
(e.g. to get wcslen) and then link with crtdll or msvcrt.
But the libc C still expects 4byte Unicode chars and I don't expect
this to change anytime soon. It would require two implementations of
each Unicode function which means two versions of the library.
I think this sounds the end of
the idea of the 3 crt scenarios (ms/libc/mixed) that were discussed
before, for all but the most trivial apps. What is left is ms and
mixed, where mixed still uses modified headers but uses the ignore
directive in the apps .spec file to link to the libc implementation
where desired (and where not already specified in msvcrt.spec).
For more details on the matter, you can look at old articles:
(BROKEN KCREF,
BROKEN KCREF,
BROKEN KCREF)
Francois was less pessimistic, at least on the impact of this Unicode
matter: I think that there are many Windows
applications that don't really care about Unicode. These should not
have too much trouble with the native C headers.
Anyway, the final scenarios for MSVCRT are still open, but, with time
going by, it seems the number of options is decreasing and the full
native header might be the final solution (just a feeling that might
start growing).4.
DirectDraw reorganization (cont'd)
16 Jan 2001 - 17 Jan 2001
(6 posts)
Archive Link: "Reenable DXGrab"
People:
Ove Kaaven, Alexandre Julliard,
Continuing after last week article (BROKEN KCREF), Ove Kaaven got a look at the DDK for the DirectDraw/3D
interfaces:
It seems that whoever designed DirectDraw/3D weren't the same guys
that designed DirectSound. There isn't exactly a COM interface, rather
the HAL interface is a range of C structures and callbacks (although
GUIDs and vtables seem to be referenced here and there).
(As a reminder, the DirectSound driver interface is in fact another
COM object. Here, the interface is merely a couple of C structures
with function pointers).
Alexandre Julliard reiterated his approach on adding/deriving
Microsoft interfaces in Wine:
If the interface is reasonably sane (at least by Microsoft standards,
so it's not a strong constraint ;-) and it allows doing everything we
need, then yes, it's better to use an existing interface than defining
our own. OTOH if we need to add our own private interface on top of
this one then it's probably not worth the trouble.
Ove felt like 99% of the job can be done with the standard interface,
but 1% would require Wine specific flags.
Alexandre went on:
A few extra flags are not really a problem, there are some precedents
already (like the Wine-specific WS_EX_* window style bits). This
should of course be avoided as much as possible, but as long as the
basic meaning of the interface is preserved, adding a few small
extensions is acceptable.
This should now be the end of the thread.5.
WebBrowser DLLs (cont'd)
17 Jan 2001
(1 post)
Archive Link: "Initial stubbing of shdocvw.dll (IWebBrowser)"
People:
Yoram Grahame,
Yoram (Yoz) Grahame, while reading last week issue, posted a follow up
on BROKEN KCREF regarding the COM
object for web browsing:
6.
Documentation access
18 Jan 2001 - 21 Jan 2001
(13 posts)
Archive Link: "documentation patch"
People:
Uwe Bonnes, Alexandre Julliard, , John R Sheets, Jeremy White
After a patch was submitted to update the .sgml contents in the
documentation directory, Uwe Bonnes started complaining:
our development package now doesn't contain any
more readable formatted files in
documentation. So it
gets harder to point posters in c.e.m.w to those files...
What about adding a directory with formatted documentation? This would
require Alexandre to run a make in the
documentation
directory after patches to the documentation as a run with autoconf is
needed if configure.in was patched.
If that isn't acceptable, there should be another place where
up-to-date readable versions of our documentation files can be found
The doc is not built by default, so there is no point in making it
conditional. People who don't have the docbook tools simply shouldn't
run 'make' in the doc directory.
Alexandre also explained that all the documentation versions generated
from DocBook (including text and HTML) were available:
Only it's in separate tar files because I don't want to force
everybody to download the doc in 4 different formats if they don't
need it. If someone can download the source package, they can also
probably figure out how to download the doc package that sits in the
same directory (we probably should mention this in the README though,
patches welcome).
Anyway, the documentation can also be browsed on-line at
http://www.winehq.com/Docs/
7.
Wine logo
18 Jan 2001
(4 posts)
Archive Link: "Proposed New Wine Logo"
People:
Jeremy Newman, , Marcus Meissner
Jeremy Newman announced:
Marcus Meissner found the foot of the glass too thick, but Jeremy was
also concerned by the look when the image is reduced to a 48x48 xpm,
and sticked to his idea.
Jeremy proposed, after all comments are made (and taken into account)
to update the website accordingly. He also proposed to have a
consistent spelling of Wine across the Web site to be 'Wine' (and not
'WINE' or 'wine').
Sharon And Joy