Wine Traffic #82 For 12�Feb�2001
Table Of Contents
This is the 82nd 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 87 posts in 335K.
There were 36 different contributors.
17 posted more than once.
15 posted last week too.
The top posters of the week were:
- 6 posts in 26K by Patrik Stridvall <email@example.com>
- 6 posts in 22K by Francois Gouget <firstname.lastname@example.org>
- 6 posts in 19K by gerard patel <email@example.com>
- 6 posts in 19K by Andreas Mohr <firstname.lastname@example.org>
- 6 posts in 14K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- Full Stats
Wine and reverse engineering
Archive Link: "Reverse engineering court decision"
,�Robert W. Cunningham,�Robert Cunningham
Paul Merrell posted an article from PlanetIT about some recent
decisions made in the USA regarding the legal aspects of reverse
Paul even quoted some part of the article
Hypothetically, similar efforts taken by others to reverse-engineer
Microsoft Windows could be deemed justifiable if the aim of those
efforts were to make other companies' programs, designed for Windows,
run on an operating system other than Windows. This assumes that the
9th Circuit ruling holds up."
In non legal terms, this would mean that Wine developers could
reverse-engineer Windows without fearing some troubles from Microsoft
Robert Cunningham shed some more lights on this matter:
This could help Wine in the long term on some legal aspects when
needed. However, as Robert pointed out, this is just a first step, and
many more still have to be made.
Unfortunately, this decision applies directly only to those bringing
such cases within the California 9th Circuit Court. While other courts
may "take note" of this decision, it has not yet risen to the level of
Unless, of course, the case gets appealed all the way to the Supreme
Court, they decide to hear it, and they then decide to affirm the
decision. Then (and only then) would the decision become the law of
the land. Until that time, it will likely first have to be pursued on
a case-by-case basis in all other Circuit Courts. Which means we can
expect all similar cases to avoid the 9th Circuit like the plague so
long as they have other venues to run to.
As Paul mentioned in the quote he selected, the key item involves
moving an application to a different platform. Application
"portability" may legally no longer require "porting"! It may instead
allow for "OS Compatibility Layers" to be written instead. This may
also drive a needed wedge into the notion of migrating applications
into the OS, a strategy MS has evolved into a fine art.
This affects far more than Wine: One project that comes to mind is
MAME (games). There are many more seemingly similar projects that are
NOT affected, such as MOL(Mac-on-Linux), Win4Lin, Plex86, VmWare and
probably several others that actually run the target OS, not emulate
An extreme interpretation of this decision could be as follows: If I
need a reason to legally clone a new feature in some market-leading
desktop OS, all I need to do is find an app (any app) that uses that
feature, then declare my intent to make that app run under some other
(any other) OS. It does not matter if the feature being emulated is
"documented" or not. Taken further, it may even be possible to dispose
of the specific API used to implement the feature, and use a different
Eventually (assuming this decision survives), the courts will see that
ALL such forms of reverse engineering should be legal WITHOUT the
necessity of an app to port.
However, this notion still needs to be more fully explored via
additional cases before its full scope can be determined. Presently,
the scope appears to be very restricted: The article points out that
the DeCSS decision would probably not be affected in any way. In the
current environment, this is probably true. But what if you can
convince the courts to view DVD "content" as a "program"! While this
may seem obviously true to technical folks, especially those who
create multimedia apps and content for a living, it may take many
visits to court to properly communicate this understanding to the
Anyway, since most of the available content security systems ARE
software, and MS has already migrated theirs into the latest versions
of Windows, this entire issue already has the potential to snowball
completely out of the control of OS and content companies, and
possibly even Congress itself.
With the major media companies trying to tie software protection and
content protection together under copyright law (via laws such as DMCA
and UCITA), this may be just the wedge needed to pry them back apart.
PS printer driver and fonts
Archive Link: "psdrv: map Courier New to Courier"
Ian Pilcher,�Huw Davies,�Gavriel State,�,�Gav State
After Huw Davies submitted a patch were he hardcoded some font
mappings (from Windows' Courier New to Courier) in the Wine postscript
driver, Ian Pilcher started asking a few questions:
Huw agreed that having this kind of substitution list would be a nice
thing. Regarding the scaling issue, Huw continued:
Hmm. I haven't been able to get Courier to scale properly. (It
prints way too large from Lotus Notes.) I was actually thinking of
doing exactly the reverse.
What do you think of the idea of user-configurable mappings, a la the
X font aliases?
Note if you're using ghostscript to process the output then
the fonts will look about 15% larger, that's because GS's fonts are
rather bigger than Adobe's and you're probably using Adobe's
AFMs. Other than that then I'm seeing Wine's Courier to be about
another 15% larger than the output from Windows.
Gav State added:
Note: FontTastic is a TrueType server that Corel did embed in its
Linux distribution and allowed the Wine port of the Corel tools to get
information about TT fonts - which still needs to be done in Wine (see
BROKEN KCREFfor more info).
Ian and Huw then discussed the details of the implementation. Ian was
a bit confused with all the possible fonts (and type of fonts like
TrueType, X11 Type1...) and searched a way to help the configuration.
Just FYI, the corelwine tree has
support for psdrv font mapping that you might be able to use.
In general, it would be nice to move the psdrv font work that was done
in the corelwine tree into main CVS. While the x11drv/psdrv
cross-dependency issue will have to be fixed, I suspect that it
shouldn't be that hard to convert the FontTastic API calls into
appropriate FreeType calls - there are only 11 places where a
FontTastic API is called, and about 15 more where font properties
specific to the FontTastic font server are accessed - most of which
are just for added accuracy in the calculation of internal and
The printing code that's in that tree is really quite good - when we
were testing it, we were often able to hold the Wine generated output
and the Win32 generated output up to the light and see no significant
differences between them. Only after several pages of output would the
cumulative error in character widths build up to the point where
WordPerfect would break a line at a different word.
I anticipate that most people will just
be happy using TT/Type1/.fon fonts all served by FreeType and will not
bother using XLFD fonts at all. This makes font configuration quite
easy, we just tell the FreeType font driver which font files we want
it to serve and that's it. The psdrv may still want to substitute
builtin type1 fonts, but that seems to me to be psdrv's role and thus
its configuration is unique to that; this becomes more obvious when
you think that the user may install 2 instances of psdrv that print to
different printers which may have different fontsets installed,
therefore font substitution would be on a printer by printer basis.
Part of the modifications discussed here have been added to the CVS
Messages and pointers
Archive Link: "Strange window message / queue behaviour"
Marcus Meissner,�Ove Kaaven,�Ulrich Weigand,�
Marcus Meissner ran into an interesting issue:
Ove Kaaven proposed a possible explanation: I
I have an application that handles several text edit controls.
At one point it flips from the first to the second (after you have
entered the fourth character).
This is done by a function, which does (simplified) this:
/* ... */
According to the +relay,+edit trace the EM_GETSEL is executed way
_AFTER_ the return from the function, so, since it uses stackvalues,
it then smashes the stack somewhere else.
remember Ulrich have been talking about
BROKEN KCREF ;
there's the possibility that Windows recognizes that it's a
message known to contain pointers, and so just drops the message, so
that EM_GETSEL is simply never dispatched?
Ulrich Weigand gave some further explanations:
Later on, Marcus implemented the dropping of messages with pointers.
is classified as 'pointer message', and
in Win9x simply drops it. (The
16-bit PostMessage doesn't appear to care, but if a 16-bit message
with pointers is about to be received
by a 32-bit app, the
Get/PeekMessage call drops the message...)
You get DebugOutput messages like
"PostMessage: ignoring posted message with pointer"
"GetMessage: ignoring retrieved message with pointer"
when this happens.
Importing Wine to North America
Archive Link: "Benchmark hell"
,�Andreas Mohr,�Eric Pouech
Well, WWN normally doesn't cover the OffTopic mails. But we'll do an
exception this week. Wine-devel was posted with the following message:
I found your benchmark... it wasn't exactly
what I was looking for, but do you maybe have an idea on how I can
find information about the demand for wine in Canada, or North America
on the internet? I'm writing my thesis on importing german wine to
Canada and need to go over the demand part too of course.
This of course produces lots of sarcasm from the developers. Andreas
Mohr started with:
I just had to approve this
one. It's just way too funny :-) "Wine benchmark"... ROTFD (ROTF
Eric Pouech (from France) kept going on with the sarcasms
hmmm I ROTFL:ed mainly because of "German
Wine"... isn't that on oxymoron ?.
This, of course, fired some discussion about Germany being able to
produce some rather good Wine, and beer too...
Anyway, all the Wine team wishes the best of luck to this fellow with
Startup directory and resulting behavior
Archive Link: "Current Directory Strangely Affects Behaviour of Applications"
Alan Chandler,�Gavriel State,�,�Gav State,�TransGaming,�Mark
Alan Chandler popped up some nasty behavior:
Gav State was puzzled but somehow confirmed the issue:
I am trying to debug a game called Grand Prix Legends, running on Wine
with the TransGaming patch. If just spent all day getting nowhere in
winedbg because I couldn't get hold of what the game was doing.
If I cd to the directory in which the game is installed (ie
~/win/sierra/gpl) and then run
The program starts and fills the whole of my screen with a single
black window. It sits there until I move the mouse, at which time it
I have just discovered that if I cd to the root of my c: drive (ie
) and then run
The program starts and I get a 640x480 window with the correct startup
screen (I have "Desktop" = "640x480" in my config file). It is not
managed (even though I have "Managed" = "Y" in my config file).
However the program appears to partially work - in that
- The program responds to the mouse when I click on the correct
parts of the screen,
- It runs a race with computer AI cars when I tell it too.
I can't think of why this is happening, but I can confirm that we've
seen this with a few other programs, including 3DMark2000. I don't
believe that it's an issue particular to the TG patch, but I don't
know of any examples of this happening with, say, a pure OpenGL game
that doesn't require the TG patch.
The discussion then evolved in some more detailed explanation on
graphics integration in Wine. But the problem describe here shall have
to be looked at.
Sharon And Joy