Folks,

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

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.

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?

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.

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.

1. Get all the modifications to our code back (copyleft license).
2. Allow reimlementation of any call of Windows API under different license
3. Allow products under different license to link against Wine
4. GPL, LGPL compatibility
5. 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.

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:

PA = Programmers who see no need to earn money from writing code under the license.
PB = Programmers who wish to have at least a chance to earn money from their code.
C = for profit companies investing in software development.

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.

CPL(T=0) = GPL
CPL(T=infinity) = BSD.

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.

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?

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

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.

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.

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

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

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?

1. 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.
2. 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.

IMO, the undocumented functions comctl32.410 to comctl32.413 are some kind of a subclass manager. They seem to be the functions DefSubclassProc(),SetWindowSubclass(), GetWindowSubclass() and RemoveWindowSubclass() which are documented in the new Windows XP Platform SDK.

Having just read the MSDN artical at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/CommCtls/Userex/subclassingcontrols.asp I agree. The things being done are the "Subclassing controls Prior to Comctl32.dll version 6". I still feel that the subclassing is done by the "nativefont" control.