Wine Traffic #82 For 12 Feb 2001

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."

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.

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.

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.

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.

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.

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?

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.

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.

I just had to approve this one. It's just way too funny :-) "Wine benchmark"... ROTFD (ROTF drunkenly)

hmmm I ROTFL:ed mainly because of "German Wine"... isn't that on oxymoron ?.

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.

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.