Wine Traffic #116 For 24 Feb 2002

This is the 116th 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).

There were 158 different contributors. 93 posted more than once. 91 posted last week too.

First, a big oops on my part. I submitted the last issue to Zack with a large section on the Wine licensing debate. However, Zack received a few different copies of the issue from me and the final one didn't have that story in it! It seems an XML faux pas on my part seems to have messed up the parser. I've updated issue #115 to include it, please go back and check it out: Issue #115, Section #2 (5 Feb 2002: Wine License Change, Round 2)

With the creation of the new wine-license list all future mailing list stats will include both wine-devel and wine-license. This will be done by simply concatenating the two lists before counting them. The side effect will be anything that is cross-posted will be counted twice, however I don't think that matters too much.

The issue of the Digital Millenium Copyright Act has come up a few times in the recent license debate. Yahoo carried a Reuters article this week titled "Grateful Dead Lyricist Condemns New Copyright Law". It treats the subject fairly lightly while presenting both sides of the argument.

There's also an update over on Lindows.com about their legal dispute with Microsoft. There's a link to an interesting survey they conducted. Michael Robertson declares the survey shows "not even a SINGLE respondent was confused" between Microsoft's programs and LindowsOS. Then again the survey population of 14,001 consisted of people who registered on Lindows.com's website.

Did you see the above note about missing the license debate in the last issue? Please go back and check out that thread: Issue #115, Section #2 (5 Feb 2002: Wine License Change, Round 2) This section picks up from there.

The license debate continues. This week I'll summarize it first by looking at a few posts by Alexandre. Then we'll move on to the various threads.

Folks,

Here is the summary of the votes I received in answer to the request to switch to a copyleft-style license:

	Agree	Disagree	Indifferent
All votes:	76 (70%)	15 (14%)	17 (16%)
Contributors:	39 (66%)	7 (12%)	13 (22%)
Contrib. weighted:	59 (64%)	13 (14%)	20 (22%)

The first line counts all the votes I received. The second line counts the votes of all people/companies who contributed some code to the project. The last line counts all contributors again but with each being given 1, 2, or 3 votes depending on the importance of his contributions (this evaluation is obviously a bit subjective, but I think the overall trend is clear).

The obvious result of this vote is that my previous conclusion was wrong: there is clearly widespread support in the community for a copyleft-style license. With 2 out of 3 contributors in favor of the switch, and less than 15% opposed to it, it's clear that we are going to proceed with the change.

We now have to decide the implementation details, like the exact license used, whether to require copyright assignments, etc. My suggestion is that we create a separate mailing list to discuss that, to avoid drowning wine-devel under yet another license flame war.

Roger Fujii wondered, " As a curiosity, what % of the voters are affiliated with codeweavers?"

Alexandre explained, " Actually I have counted Codeweavers and its employees as one contributor. Only people who have done work for themselves outside of Codeweavers have been counted separately. The total of all these votes represents about 10% of the contributors votes (and about 5% for Transgaming in case you wondered). "

At this point a new mailing was created, wine-license. You can find all of the Hypermail archives on the WineHQ web site. Most of the discussion shifted over there within a few days.

With regards to the existing code, Kenneth Davis asked, " Will there be a final release of the X11 tree previously maintained by Alexandre Julliard? (for those of us who do not wish to use a version under another license)." Alexandre replied he would cut a final release under the BSD license before making the change. Kenneth also wondered if someone would be willing to maintain the BSD tree to which Ove Kåven responded, " If it proves necessary, I'd be happy to. I know I will not contribute to a LGPL-only Wine; I don't care much about business models, but if the Wine project will not allow my work to be used in someone's Xbox clone with NDA-ed hardware specs and operating environment (i.e. hardware-specific changes to the Wine core with no disclosure allowed), then I'm not interested in contributing to the Wine project at all."

Patrik Stridvall felt it was too early to think about how the two trees will co-exist since the only thing that had been decided was " that we should explore the possibillities for some sort of copyleft license " . Alexandre clarified that, " What has been decided is that we *will* switch to a copyleft license. Right now the LGPL is the obvious favorite, judging from the responses I got (even though the question was about copyleft, a large proportion of the voters explicitly said they favored LGPL). I'm open to alternative solutions though, and you are welcome to make *constructive* propositions of other possible licenses. "

I want to start this thread to discuss advantages and disadvantages of MPL.

Disclaimer: I'm not a lawyer, do not consider myself an expert in licenses

For the text of the license see http://www.mozilla.org/MPL/MPL-1.1.html

I reviewed MPL - it seems to fit very well to our goals. This is a copyleft license.

Can we use the conclusions they came to - licensing under tri-license MPL/LGPL/GPL?

Alexandre replied, " The main problem with multiple licenses is that as soon as someone actually uses the extra permissions, by doing something allowed by LGPL but not by MPL, or allowed by MPL but not by LGPL, this creates a fork that can never be merged back into the main tree. So it sorts of defeats the purpose of copyleft."

Found RMS comments about compatibility of NPL/MPL with GPL: http://www.gnu.org/philosophy/netscape-npl.html

The article says thag GPL is incompatible with NPL(MPL) because NPL has additional restrictions and conditions. What he exactly means?

The article has many concerns which are applicable to Wine.

It should be noted that because of potential incompatibilities of the MPL and GPL licenses the Mozilla project decided to adopt the GPL/LGPL/MPL licenses just to make sure the MPL code could be shared with GPL'ed projects. Anand Kumria summarized some key features of using the MPL: "

The next thread was started by Gerhard Gruber, " When I was thinking about the license issues discussed here I was thinkg about wxWindows. As it seems there may be similarities, because wxWindows is also a library that can be used in commecrial applications. Maybe if somebdoy looks into the licenses of wxWindows it might help."

Andriy looked into and reported, " Their choice is pretty interesting. Quote from the site: "The wxWindows 2 licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWindows, and also those producing proprietary software.""

Deven Corzine tossed out another idea. This follows on the idea of creating a "WineCorp" entity that had been suggested before - namely a controlling group would be able to sell a proprietary license to anyone that wanted one. Deven's example showed how Sleepycat Software worked:

Berkeley DB started as a small embedded database library which only supported hash tables and btrees. Since it was written for BSD Unix as a replacement, it was released under the BSD license. After a few years, it was widely used, but it still only offered access methods. When Netscape wanted more features, such as transactions, disaster recovery and multiple-user support, Sleepycat Software was founded to further develop Berkeley DB (on the strength of a licensing deal with Netscape).

The new version of the software was released under the Sleepycat license [sleepycat.com], an OSI-approved [opensource.org] license which allows Open Source applications to use Berkeley DB, but (unlike the GPL) appears to be compatible with any Open Source license. For proprietary applications, Sleepycat offers a more traditional licensing option to companies who don't wish to distribute their source code. Revenue from such licensing funds additional development of Berkeley DB, to the benefit of all. (For example, Berkeley DB 4.x adds replication and high-availability functionality that surely would not exist without the funding received through this dual licensing.)

Perhaps the Wine project should follow this example? Wine could be placed under a license like Sleepycat's, which would allow Wine to be freely used by Open Source projects (whether GPL or not), and proprietary companies could pay for a license which allows proprietary use. Funding from such licensing could be used to further develop Wine, to the benefit of proprietary and Open Source users alike.

Several people pointed out that putting all of the control into the hands of a few people didn't seem like a good idea.

At different times people asked for a clarification of exactly what was to be accomplished by using a copyleft license. The hope was that by defining the goals perhaps the best match could be found with existing licenses. Andriy provided a list and several people commented on it. The second revision was:

Get all the modifications to our code back (copyleft license).
Allow reimlementation of any call of Windows API under different license
Allow products under different license to link against Wine
GPL, LGPL compatibility
protection agains patent claims

Allow proprietary programs to dynamically link to any set of DLLs from Wine; they should be able to mix and match Wine DLLs with their own proprietary ones.

Bob La Quey broke the problem down systematically and approached the problem from a different point of view:

First the disclaimers: I am an outsider to the Wine community but my company OsoComm see http://www.osocomm.com/ has recently done some contract work for Lindows.com. I anticipate that we will be quite active in this community during the next year and so I am reading the mail archives, studying the technology and generally trying to come up to steam so that OsoComm can be a good member of this community. Oh yes also IANAL and personally favor the GPL.

Now a comment on the licenses:

The BSD vs xGPL debate is really very simple.

First I will define three groups. Call them PA, PB and C where:

xGPL says you MUST give code back to the community, PAs tend to like this license, PBs do not. BSD says you MAY give code back but you are not forced to do so, PAs do not like this, PBs do, and C's do.

It appears that all groups would agree to the principal that having source code available would generally be a good thing if their economic interest were not threatened. The puzzle then is how to arrange this.

I propose a single license, call it the CPL for Compromise Public License.

The CPL is a function of one variable Time. So we have CPL(T), where T is a period of time allowed before the source code MUST be revealed.

T is essentially the time at which the license switches from BSD to GPL, i.e. the delay between the release of a binary and the release of the code for that binary.

The resolution to the conflict is to use T to balance the needs of investors of either time (programmers) or money (companies) with the needs of the community for open source.

This is the same idea as copyright but under the "Sonny Bono Copyright Term Extension Act" copyright now has T=70+ years, which for software is absurd. If you look into the history of copyright you will find that Jefferson was initially ( See http://digital.library.upenn.edu/books/bplist/archive/1999-02-11$2.html ) opposed to it. He was a GPL guy, but Madison convinced him that allowing a monopoly to the creator for a limited time was a fair way to balance the needs of the creators and the community. I think some 200 years later this remains the best solution.

But we need a reasonable T.

I think a T of six months to one year is probably about right, with six months better then one year. This gives investing companies an opportunity to recover their investment and still insures that the community gets the code, albeit a little bit later then they do under the conventional GPL.

There weren't very many responses to the idea by the time I kicked this issue out the door. So, there we are - a new license is in the works. Stay tuned.

Michael Cardenas wondered if it was possible to make his serial port use DTR flow control:

Is DTR flow control supported?

There's a comment in comm.c in SetCommState that says it's not, but EscapeCommFunction has a SETDTR case and a CLRDTR case.

Below are the lines I'm talking about.

I'm working on an app that asks for DTR flow control and uses overlapped IO when using a modem. It establishes a modem connection, but then it can't send any data over the connection. I'm using an external modem on a serial port.

To my knowledge the serial driver of Linux does not support DTR flow control.

So it might be a bit hard to implement in WINE.

There is an article from Rein Klazes, http://www.winehq.com/hypermail/wine-users/2001/12/0209.html could you try his suggestions?

That article from Rein goes into detail on some changes to make concerning selecting or not selecting DTR flow control and using some different flags for that. Mike McCormack explained in more detail that DTR wasn't supported:

However the Win32 API uses very confusing names, so make sure the app is really asking for DTR/DSR flow control.

DTR_CONTROL_ENABLE does not mean DTR/DSR flow control is enabled, it means turn on the DTR line permanently. Only DTR_CONTROL_HANDSHAKE means the serial port should use DSR/DTR handshaking. (AFAIK, DTR_CONTROL_ENABLE and DTR_CONTROL_DISABLE flags are not correctly handled in the current wine... they should actively turn on or turn off DTR).

Additionally, there were some problems in the GetCommState/SetCommState code that saw DTR_CONTROL_HANDSHAKE accidently turned on, so make sure that it is really the application that is requesting it.

As Marcus pointed out, the linux kernel itself does not support DTR/DSR flow control, but given the time and motivation, we could solve the problem if you really need to make this work...

Arjen Nienhuis experienced a problem with a game he has using DirectInput. He felt the key mapping method wasn't correct and explained:

The MapVirtualKey in GetDeviceState is not "the way to do it". It does not map VK_?? to DIK_??. I don't know why it does work most of the time. "ptr[i] = 0x80; ptr[i + 0x80] = 0x80;" gave double key events in a game I have.

The correct way to convert the keys is by this table (attachment). I made this table by pressing all the keys on my keyboard, and record the keycodes.

It works because DIK_* is (at least up to 0x53, as far as I can see) identical to the PC keyboard scancodes, and MapVirtualKey handles scancodes perfectly well. I really don't think this is a coincidence, I think this is so that Microsoft's DirectInput do *not* need the kind of mapping table you propose. If there's a problem with the scancode conversion, you should fix it in MapVirtualKey. I think you may want to keep in mind that the scancode tables in the keyboard code denote extended codes with e.g. 0x138 (0x100 + 0x38), while the DIK for that key is 0xB8 (0x80 + 0x38). Perhaps the keyboard scancode tables could be changed to be compatible with the DIK codes without losing any functionality.

As far as using the table Arjen created, Ove felt different keyboard layouts complicated the issue,

Then that table would depend on the keyboard layout (country, language, etc). It should be enough to keep the keyboard layout table mess in *one* place in Wine (in the keyboard code, where MapVirtualKey resides), not two.

So Arjen went back to his patch and worked on it so that some scancodes used MapVirtualKey to do the conversion and others used a table to lookup the proper values. He asked Ove what he thought of the change and Ove replied:

Well, better. I still think it might be better to make MapVirtualKey handle codes above 0x80 itself, but I'm not sure.

By the way, the problems we have with MapVirtualKey not having an one-to-one mapping might be solved by implementing map mode 3 (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/keybinpt_0hfd.asp).

David Hammerton of Transgaming asked for some suggestions about changes to x11drv:

I'm presently modifying the X11DRV dibsection code for slight speed improvements using shared memory pixmaps and the like. Im into the "clean up and make it work on all systems" stage of thing, and I have a question. Do people ever worry about what happens if the user is running in a 1, 4 or 8 bit X mode? This has some wacky code, which I am unable to test on my machine (or any machine around).. So i'm implementing what I think _should_ do the trick - but I have no idea if it will work..

Is it a big issue?

1 & 4 bit - very rarely used (unless you're talking about monochrome screens in embedded - by then 4 bit is important for gray scales..)

8 bit - used mostly on old system with old graphics cards when 16 bit & up are slow - I'm talking about graphics chips like : trident 89xx family, ATI Mach 8, Cirrus Logic (all ISA versions), ancient S3 chips, and Number 9 (ISA) - on all of those cards it is better to run XFree in 8 bit or else you'll get a totally slow graphics...

Everything else today on X86 is running at least 8 bit and on 99% - 16 bit and up...

You might want to be careful regarding to 8 bit and up modes - like 15 bit, 24 and 32 bit. I think Matrox old graphics cards (with their 2.3MB RAM) are using packed pixels so it could be a bit problematic...

I recalled Francois Gouget's VNC work from October and found the message where he described how to use it to test various combinations: http://www.winehq.com/hypermail/wine-devel/2001/10/0278.html

I'm now saying that this will work in 1, 4 or 8 bit configurations, but it's worth a try. It might also be worthwhile to make sure your code works with several '-pixelformat's to test compatibility.

You can use VNC to test 8bpp true-color modes, but I think David Hammerton had 'palettized' modes in mind. In that case, the only solution I can see is to run the VGA XFree driver. It's not as practical but is the only solution I know of. Pretty much all graphics cards should be able to use it as all it requires is VGA support.

Today we made some changes to make it possible for Linux CVS clients to log in.


CVSROOT=:pserver:guest@www.netlabs.org:/netlabs.cvs/odin32

User: 		guest

Password: 	readonly

For more info on the Odin project, refer to Issue #112, Section #2 (25 Dec 2001: Cooperation With Odin Project)

I am attempting to implement toolbar window message 0x463 -- which, as far as I can tell, is undocumented. If anyone has any information about it, I would love to hear it.

I currently have a question about a difference in the implementation of comctl32.dll under Wine vs Windows. In both Wine and Windows, the function ToolbarWindowProc starts by calling GetWindowLongA (hwnd, 0) and treats the returned value as a pointer to a structure.

Under wine the structure is the TOOLBAR_INFO structure defined in dlls/comctl32/toolbar.c. Under Windows, I have no idea what the structure looks like. Using the debugger, I can see that the first two elements of the structure are the hwnd numbers of the window and its parent -- but after that it is not very obvious. The structure is over 150 bytes in size.

Does anyone know what the structure under Windows looks like?

Most (if not all) the extended common controls (those in comctl32) seem to store their main implementation data via GetWindowLong(hwnd, 0). However we really don't care about the format of the MS version since our code *should* never interface with it. I have not personally seen any access to that in Rebar, Toolbar, or ComboEx. To avoid *trouble* I would suggest staying away from MS's version of the implementation data.
From looking at relay traces, Toolbar messages 0x045d and 0x0463 seem to be a pair. They also seem to invoke comctl32.413 which is also undocumented. The relay traces seem to suggest that .413 somehow redirects the message to another Winproc. All windows that process through .413 seem to have the atom for "CC32SubClassInfo" added as a property (GetProp/SetProp). I suspect that this whole thing may be related to the "nativefont" control. There seems to be no ill-effect to the messages not being implemented (except for the annoying fixme). Note that comctl32.413 may also be related to comctl32.410 and .412.

If you can somehow get the "nativefont" control to make a visual difference, then maybe we can implement some of this.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	13 Feb 2002 - 23 Feb 2002	(3 posts)	wine-license list, Lindows.com legal battle
2.	13 Feb 2002 - 23 Feb 2002	(422 posts)	Wine Licensing (con't)
3.	21 Feb 2002 - 23 Feb 2002	(5 posts)	DTR Flow Control
4.	20 Feb 2002 - 23 Feb 2002	(7 posts)	DirectInput Key Mapping
5.	20 Feb 2002	(4 posts)	X11drv and Low Color Depth
6.	20 Feb 2002	(1 post)	Odin CVS Repository
7.	20 Feb 2002 - 21 Feb 2002	(4 posts)	Question about ToolbarWindowProc

Wine Traffic #116 For 24 Feb 2002

By Brian Vincent