Wine Traffic #72 For 4 Dec 2000
Table Of Contents
Introduction
This is the 72nd 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 105 posts in 299K.
There were 33 different contributors.
17 posted more than once.
14 posted last week too.
The top posters of the week were:
- 15 posts in 44K by Alexandre Julliard <julliard@winehq.com>
- 10 posts in 25K by Dennis Bjorklund <db@zigo.dhs.org>
- 9 posts in 24K by Andreas Mohr <amohr@codeweavers.com>
- 7 posts in 16K by Ove Kaaven <ovehk@ping.uio.no>
- 5 posts in 20K by Patrik Stridvall <ps@leissner.se>
- Full Stats
1.
Headlines
People:
Wine-20001202 has been released. Major changes include:
- New 'winemaker' script to automate source porting.
- New dll import mechanism to replace ELF linking of .so files.
- Many internationalization fixes.
- A lot of portability fixes.
- Builtin crtdll much improved.
- Lots of bug fixes.
MusicMatch also announced the availability of a JukeBox program of its
own, ported to Linux using Wine. You can check out the beta version
here.
WineHQ new design (which was announced a
while ago) has been promoted to the official skin level. We
hope you'll enjoy the new surf on WineHQ and find it more readable and
easy to browse to get all the relevant information, even if everything
is not finished (<fresh painting marks still float around>).2.
Exporting variables from DLLs
26 Nov 2000 - 29 Nov 2000
(10 posts)
Archive Link: ".spec file "extern" entries"
People:
Ove Kaaven, Alexandre Julliard, Francois Gouget, , Ove Kåven
Ove Kåven asked Alexandre Julliard for some more information on the
newly introduced DLLs in .so file mechanism. Ove found that access to
most global variable exported from another DLL failed with the new
mechanism (BROKEN KCREF):
In some DLLs, like CRTDLL, not only functions are exported, but also
variables, for example:
crtdll/crtdll.spec:@ extern __argc_dll CRTDLL_argc_dll
crtdll/crtdll.spec:@ extern __argv_dll CRTDLL_argv_dll
crtdll/crtdll.spec:@ extern _ctype CRTDLL_ctype
crtdll/crtdll.spec:@ extern _environ_dll CRTDLL_environ_dll
But winebuild doesn't cope with these. It can either generate "jmp" import
stubs, which is broken, or not generate anything at all, which fails
linking. We're having some problems with this around here... how does
Alexandre plan to solve this?
I'm not planning to solve it at the moment, and given that there are
very few such variables, I doubt solving it at all is worth the
effort. If you need these variables you should declare pointers to
them and use GetProcAddress (or for argc/argv/environ you can declare
your own variables and use _GetMainArgs to fill them).
After some investigation, Ove reported that the
unlinkable variables are GUIDs, like those defined in ddraw.h
and wondered if winebuild should be extended to allow the definition
of GUIDs from a given header file (like ddraw.h) ?
Francois Gouget replied: On Windows you are supposed
to link with static libraries to get these GUIDs. I found three such
libraries: uuid.lib (the main one), ciuuid.lib and daouuid.lib.
Francois then proposed to fix this in Wine by providing static
libraries (or even .o files) like Windows do, meaning that nor an
extension to the .spec file, nor dynamic linking (and symbol
exportation) is required.
3.
Wine debugger and a DOS driver
2 Dec 2000
(2 posts)
Archive Link: "debugger on DOW drive?"
People:
Dennis Björklund, Ove Kaaven, , Ove Kåven
Dennis Bjorklund had tried to set the debugger as indicated in the
doc-file using a UNIX style path name (like
/usr/local/bin/winedbg), and reported failure to get the
debugger started on a crash.
Dennis asked does this mean that winedbg can't live in
the normal path but have to be in a windows partition (these strange
things with letters like H:). It sort of makes sense since it's used
from the windowsworld (ie registry) but in that case the documentation
doesn't make sense any more.
Ove Kåven explained:
(it) is probably that many
developers have catch-all drives, like below - and Wine is easily able
to change a Unix path to a Windows path (and back) if such a
definition exists in the
~/.winerc file.
[Drive Z]
Path=/
4.
Wine developers still have time to play
2 Dec 2000 - 3 Dec 2000
(12 posts)
Archive Link: "civ2"
People:
Dennis Björklund, Ove Kaaven, Andreas Mohr, , Francois Gouget, Ove Kåven
Dennis Bjorklund reported: civ2 (EdNote:
Civilization II) is really slow in Wine. When I move a unit one
square the move takes something like 5 seconds. Also the blinking that
the units do when they are selected is very slow. And CPU usage are at
100% all the time, but that might be true in windows also.. It looks
good at least.
Francois Gouget reported some other type of slowness (in an sample for
a Programming Windows book) which faded away if the user actively
wiggles the mouse (Andreas Mohr reported the same bad behavior for
WinAmp about box). None of them gave a clear explanation about what
may fail, but this issue really need some fix.
But, the "mad mouse" approach didn't solve Dennis' issue.
Ove Kåven went into with some thoughts:
Civilization II uses WinG, which is implemented in Wine in terms of
DIB sections (which was introduced in Win95 as the successor to WinG
anyway).
Lately I've been working on DIB sections in x11drv - they are handled
in quite some involved ways in x11drv, and I've been working on
improving the flexibility, threadsafety, and the possibility of
reducing the overhead. Maybe I'll submit what I have done sometime
next week.
It may not help Civ2 directly, since the experimental
DIBsection->screen blt optimization I did currently only handles
16bpp and above, while WinG operates on 8bpp, but it should be very
obvious where the extra work needs to be done...
Sharon And Joy