Wine Weekly News #82 (2001 Week 07)
Eric Pouech
Eric.Pouech at wanadoo.fr
Wed Feb 14 14:02:22 CST 2001
please enjoy this week issue
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
-------------- next part --------------
Wine Weekly News
All the News that Fits, we print.
Events, progress, and happenings in the Wine community for February
12, 2001 .
_________________________________________________________________
_________________________________________________________________
Keeping track of Wine
_________________________________________________________________
After two weeks away from Wine, Alexandre returned to a truckload of
patches...
* John R. Sheets (CodeWeavers) documented the SGML documentation.
* Andreas Mohr (CodeWeavers) adapted wineconf for the new config
file format.
* Ove K?ven (TransGaming) fixed some DIB section and DGA2 bugs, and
started adding a DirectDraw HAL to the x11drv.
* Marcus Meissner made the PostScript driver able to automatically
find .afm files provided by software like GhostScript and others,
so the user doesn't have to configure .afm file locations
manually.
* James Abbatiello (CodeWeavers) implemented QueryPerformanceCounter
using the Pentium's RDTSC instruction.
*
* Other Workers/Bugfixers: Marcus Meissner (printing, ddraw, misc),
Guy Albertelli (common controls), Lionel Ulmer (ddraw), Jon
Griffiths (locale hashes, shlwapi), Rein Klazes (Malayan locale),
Patrik Stridvall (winapi_check), Duane Clark (print dialog), Peter
Ganten (afm fixes), Lawson Whitney
+ CodeWeavers: Andreas Mohr (various), Huw D M Davies (print
dialog, enh.metafiles), James Abbatiello (shell, common
controls, file mappings), Dmitry Timoshkov (enh.metafiles,
MDI, Unicode), Fran?ois Gouget (winemaker, Winelib, common
controls), Susan Farley (pager control, window handling),
Chris Morgan (listview/shellview control), Josh DuBois
(portability), Aric Stewart (clipboard), Eric Kohl
+ Macadamian: James Hatheway (multimedia)
_________________________________________________________________
Discussions on wine-devel
_________________________________________________________________
This week, 87 posts consumed 335 K. There were 36 different
contributors, 17 (47%) posted more than once, and 15 (41%) posted
last week too.
The top posters of the week were:
* 6 posts in 26 K by "Patrik Stridvall" <ps at leissner.se>
* 6 posts in 22 K by Francois Gouget <fgouget at free.fr>
* 6 posts in 19 K by gerard patel <gerard.patel at asi.fr>
* 6 posts in 19 K by Andreas Mohr <amohr at codeweavers.com>
* 6 posts in 14 K by Eric Pouech <Eric.Pouech at wanadoo.fr>
* 5 posts in 16 K by David Elliott <dfe at infinite-internet.net>
* 4 posts in 14 K by Alan Chandler <alan at chandlerfamily.org.uk>
* 4 posts in 13 K by Thomas Flynn <flynnt at acm.org>
* 4 posts in 12 K by Jon Griffiths <tntjpgriff at tsnxt.co.uk>
* 4 posts in 12 K by James Sutherland <jas88 at cam.ac.uk>
* 4 posts in 12 K by "Ove Kaaven" <ovehk at ping.uio.no>
* 3 posts in 7 K by Ulrich Weigand
<weigand at immd1.informatik.uni-erlangen.de>
* 2 posts in 8 K by Huw D M Davies <h.davies1 at physics.ox.ac.uk>
* 2 posts in 5 K by Uwe Bonnes
<bon at elektron.ikp.physik.tu-darmstadt.de>
* 2 posts in 5 K by "David D. Hagood" <wowbagger at sktc.net>
* 2 posts in 28 K by Ian Pilcher <pilcher at concentric.net>
* 2 posts in 11 K by Marcus Meissner <marcus at jet.franken.de>
Wine and reverse engineering Announce
Paul Merrell posted an article from PlanetIT about some recent
decisions made in the USA regarding the legal aspects of reverse
engineering ([1]
http://www.planetit.com/techcenters/docs/security/news/PIT20010123S000
1/1?spsubcat=bugs_flaws).
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
layers horde.
Robert Cunningham shed some more lights on this matter:
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 a "precedent".
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 (clone) it.
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 one instead.
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 legal system.
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.
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.
PS printer driver and fonts Evolution
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:
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?
Huw agreed that having this kind of substitution list would be a nice
thing. Regarding the scaling issue, Huw continued: " 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:"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
external leading.
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.
"
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
[2]Xfree 4.02 and Winefor 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.
Huw answered "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
tree.
Messages and pointers Issue
Marcus Meissner ran into an interesting issue:
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:
{
DWORD startsel,endsel;
PostMessageA(hwnd1,EM_GETSEL,&startsel,&endsel);
SetFocus(hwnd2);
PostMessageA(hwnd2,EM_SETSEL,0,0);
/* ... */
CallWindowProcA(hwnd,....);
return;
}
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.
Ove Kaaven proposed a possible explanation: I
remember Ulrich have been talking about [3]message parameters
conversion ; 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:
Yes. EM_GETSEL is classified as 'pointer message', and the 32-bit
PostMessage 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"
or
"GetMessage: ignoring retrieved message with pointer"
when this happens.
Later on, Marcus implemented the dropping of messages with pointers.
Importing Wine to North America Report
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 drunkenly)"
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
his thesis...
Startup directory and resulting behavior Issue
Alan Chandler popped up some nasty behavior:
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
wine gpl.exe
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 exits.
I have just discovered that if I cd to the root of my c: drive (ie
~/win) and then run
wine c:\\sierra\\gpl\\gpl.exe
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.
Gav State was puzzled but somehow confirmed the issue:
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.
Credits: [4]Doug Ridgway, [5]Eric Pouech, and [6]Ove K?ven.
_________________________________________________________________
References
1. http://www.planetit.com/techcenters/docs/security/news/PIT20010123S0001/1?spsubcat=bugs_flaws
2. http://www.winehq.com/News/2000-52.html#2
3. http://www.winehq.com/News/1999-48.html#2
4. mailto:ridgway at winehq.com
5. mailto:pouech at winehq.com
6. mailto:ovek at winehq.com
More information about the wine-announce
mailing list