This is the 115th 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 was a relatively slow week on the wine-devel list followed by the past week of intense debate over licensing. Alexandre continues to integrate patches sifted from the large CodeWeavers patch Jeremy White posted a few weeks ago. There were a ton of changes made to the Listview code that were done over a series of 4 commits. Marcus Meissner, in a quest to get DreamWeaver 4 to install, submitted a huge patch to implement local server COM and a typelib based marshaller. This is a duplicate of a lot of work done by Transgaming, but that code is never made it into the Wine CVS (in part because it's in Transgaming's AFPL'ed WineX tree and partly because Ove Kåven thought it was rather ugly.)
Seen at the bottom of Daniel Schwarz's signature was a reference to a Wine Wiki. Check it out over at http://www.winecentric.com and add a page or three.
Also of note this week are several postings by Lindows.com. Several emails arrived from them, perhaps the most interesting one came from Michael Robertson explaining Lindows.com's involvement:
Just to set the record straight.
Lindows.com has had a partner company producing the majority of our WINE code. The vast majority of the code that came from that partnership is in the public tree already.
Lindows.com has contributed code to open source projects. We have hired open source companies (spending over 500K) to help us reach our goals with the majority of the code going back to open source. Lindows.com has given financial support to several open source initiatives (such as KDE). Lindows.com has made significant investments in linux companies. All told, we've spent about 2 million in the 5 months that we've been a company.
Linux (and all the other pieces) does 95% of what people want to do today, but only has 1% market share. Our belief is that the code is largely not the limiting factor for adoption now. It's all the pieces that go around the code. It's education, it's marketing, it's lobbying, it's business development, etc. These are big tasks which are critical to success, even more so than the code itself (think AOL). I know this won't be a popular thing to stay on a mailing list with "devel" in the title, but it's where we believe linux is and what we believe needs to happen to get to the next level. This doesn't mean the code isn't important, it is but there are other critical elements.
We need Lindows.com and 10 more thriving companies to help with the expense of educating, lobbying, marketing, etc. desktop solutions. It's expensive to do those things and a burden that needs to be shared by several companies because the job is so enormous and the competitor so strong. The Linux community, especially the desktop community needs healthy ongoing companies to put in capital, organization, and other support. If we can put a few million more people running Linux on the desktop, then magical things will happen. Drivers for linux will be available, higher quality linux software will emerge, more OEMs will offer linux as an option, devices will have linux interfaces, governments will view linux differently, etc.
There are some small, but meaningful for-profit companies out there today in linux (such as codeweavers and transgaming). The more companies in the linux desktop space there are, the more companies that will be able to pay their rates on an ongoing basis and hire them to code great products. There's tremendous opportunity and the more companies out there the better.
As for our marketing message, it's designed for my Grandma. Anytime there's a word on the website she doesn't understand she calls me up. Try explaining a recursive acronym to your Grandma. Yikes. Our goal with Lindows.com is to bring Linux to the segment of the world who thinks linux is spelled with a 'y' and is a small bobcat.
A little over a month ago a discussion spawned about possibly
switching Wine over to using an LGPL license rather than the
current X11 (BSD-style) license. Alexandre effectively ended
the debate with,
My conclusion is that there clearly isn't enough support in
the developers community to justify changing the license. So
I'm not going to proceed with any change, either now or in
the foreseeable future. Please refer to the
previous discussion for details of the various positions.
Perhaps the forseeable future was only a month? Jeremy White of CodeWeavers posted a lengthy note and opened discussion again. This post was also linked from Slashdot and the corresponding discussion ran the usual gamut of ill-informed to somewhat interesting. Jeremy wrote:
Some recent events have occurred that have made me change my opinion about a Wine license change.
During my involvement in the Wine project, I have always striven to make sure that I, and my company, did what was best for the Wine project. I believe Wine's success will help to make the world a better place. To that end, often through difficult personal negotiations, I have always insured that all of my contracts require that all code changes be returned to Wine. This, in effect, treats Wine as an LGPL product.
You can argue that the flexibility granted by the Wine license has meant that I received some business I would not otherwise have had. Gav, for example, has pointed out that Corel would never have worked on Wine if not for its license. There are two ironies there - first, Corel has always been a great Wine citizen, IMO, never 'abusing' the license. Second, while we did work with Corel to help them with Wine, we never signed a contract with them. Their lawyers and I were never able to agree on a contract that we thought would sufficiently protect Wine. Fortunately for me, we were able to work with Corel without a contract, but this issue to this day creates unnecessary friction between my company and Corel.
However, with some recent events I cannot disclose, it is clear to me that the opportunity for Wine to be used in a proprietary product is too tempting and has caused some harm to the Wine project. Based on experience, I feel strongly that the potential for harm is great enough that CodeWeavers needs to take two actions. First, we would like to release all new code we develop under an LGPL style license. Second, I would like to open another call for a license change and thereby strongly add my voice to Alexandre's.
Thus, I would like to call for a change in the Wine license. I think we all agreed that the LGPL formed the basis for a good 'alternate' license strategy. Eben Moglen, the counsel for the FSF, has kindly offered to help review licensing strategies for Wine. The goal is to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine. I think it it is great that we have, in Eben, not only the leading legal scholar on free software licensing, but a great hacker to boot. I think he will clarify exactly what is possible and what is not possible with GPL style licenses and insure that the license we choose will meet our goals.
When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license.
I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows:Should the Wine project switch to a license which has as its goal to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine?Please privately let Alexandre (firstname.lastname@example.org) know what you think, and then publicly respond to this thread as you feel appropriate.
Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend.
Wow.. that's a pretty big announcement from a big contributor to
Wine. Of course the current Wine license allows anyone to to do
anything they wish with Wine - including opening a new tree with a
different license. Keep in mind that Alexandre Julliard works for
CodeWeavers, so a lot of code would ultimately make it into the "xGPL"
tree. One can only
imagine what "recent events" prompted this from Jeremy. As James
I think Codeweavers' actions over the past two years or so more than
sufficiently establishes the fact that they deserve to be given the
benefit of the doubt in regards to statements like these.
It appears over the past month or so a lot of thought has gone into what a license change would mean. This time the discussion tended to be more focused and offered some new ideas. JÖrg Mayer threw out the first:
OK, when the last discussion was going on, I started out with the opinion that the change would be good and changed it to not so good, because if proprietary stuff that *is* part of the windows kernel (or drivers) needs to be implemented, this can't be done with an LGPLed wine. My final idea (which I never mailed) was, that maybe a X11-licensed kernel (including wineserver and driver emulation) and LGPLed dlls for the rest would be the best solution.
A few people didn't really understand why licensing some parts different than others would be necessary. But, having two licenses isn't as strange as it seems. For example, it's been discussed recently that perhaps the test framework should not be under the X11 license.
And in regards to forking the code, Steve Langasek felt,
One thing to bear in mind is that others already ARE forking the Wine
code. Given the nature of their work, Codeweavers must maintain a
separate CVS tree locally; although we're fortunate in that their fork is
open to backporting to the official tree. Other companies are forking
with no intention to contribute back (see Lindows.com); still others
(Transgaming) have made reintegration of their work contingent on turning
an profit. Jeremy is at least being courteous enough to let us know
where /his/ company is going with the Wine code, and is inviting the rest
of the Wine community to come along with him.
Dimitrie Paun responded to Dan Kegel's vote for changing to a GPL-style license:
This is a fundamental point which we haven't had a chance of discussing last time as we argued over silly future (unlikely) possible changes in copyright law.
One important argument was that building a thriving economic environment around Wine is essential for its success.
Everybody agreed on this premise, IIRC.
The argument followed that BSD license is better for creating such an environment, and hence better for Wine, since more business will contribute more code back.
This, I'm afraid, is entirely false.
I argue that in fact, the BSD license is a STRONG DETERANT for businesses to contribute code back, while the LGPL provides an INCENTIVE.
Note that I do not care, for the purpose of this discussion, about businesses which don't intend to contribute code back. They are of no help to Wine, and thus irrelevant (if not a little harmful, for reasons so eloquently explained by Alexandre).
A BSD license is a STRONG DETERANT for a business to contribute code back. The reason for this is that they have no guarantee that another business will not improve a little the code, and thus get a competitive advantage. Or that other companies will not use that code on top of the code they wrote but not released, and thus again, get that edge. This is a fantastic deterant for releasing code back. In fact, Gav validated exactly this point when he tried to argue for the BSD license last time:<talking about the DCOM work> But there are companies out there who will benefit significantly from commercial use of this code, and who can afford to sponsor a portion of the development cost. Until such a sponsorship happens, we cannot apply the WineHQ license to that code.
In other words, they needed that code. They invested some money do get it. They are happy with the results. Why not release the code? They have what they needed in the first place? The reason is clear -- it cost them to get there, they can not aford to bring everybody there for free. I can 100% understand that. But if the code was under the LGPL, it would not matter, because even if they brought everybody there, other companies could not step ahead of them, since if they did, they themselves could have used that code.
In other words, TG could have kept Direct3D proprietary, released everything else back under LGPL, and they could have _known_ they still have the competitive edge in the D3D work! This is why the LGPL is in fact an incentive for such colaboration.
Bottom line is clear: as the project matures and becomes more useful, the deterant of contributing code back from a business perspective is going to greatly increase, while at the same time, the incentive under the LGPL would have also increased.
Gavriel State disagreed and felt he'd been quoted out of context:
While I do want to contribute further to this debate, I need some time to gather my thoughts. In the meantime though, I want to address Dimitrie's quote - and fundamental misunderstanding - of me below.
Quite the opposite: It is not 'competitive advantage' that concerns us, or others using our code without contributing their own code. It is simply that we could not and cannot afford to do our development without monetary compensation. If the OLE DLLs had been LGPLed, we could not have been able to afford to do any DCOM work, since we would have had no prospect of getting paid for it.
Under the LGPL, the only possible business model is this:
- Find someone who might need some piece of code
- Sell them on: "We can do this for you, and release it under the LGPL for $x dollars. We're really good at what we do, honest"
- Do the work, and hope to actually get paid.
The current license, by contrast, allows many other alternate models that are worth trying. In the case of the DCOM code, there was something that we had a need for with our current subscriber base, but we could not afford to do the work just for that base, since it is not yet large enough. Instead, we have this business model:
- Do the work up front, proving that it works, covering a small portion of the cost from our current subscribers.
- Talk to potential sponsors who need the work
- If they agree on a price, release the code under the Wine license.
The TransGaming subscription model is simply this writ large, trying to get the individual users to act collectively as sponsors of the work.
The LGPL simply slams the door shut on that whole model, saying in effect "It's my way or the highway".
At the same time, I believe that I understand the main concern of the LGPL proponents: the current license allows the possibility of benefiting from the project without any contribution. Where I differ from them is that someone else's code is not enough to keep my employees eating. What I need as a contribution is not code, but cash.
Anyhow, I'm going to go and put my thinking cap on, and try to see if I can think of some arrangement that might work better for everyone.
Andreas Mohr read through some of the Slashdot posts and found
one idea interesting enough to pass along,
One guy made an interesting suggestion:
a "dual license" scheme (like MySQL uses) where you switch to (L)GPL,
but certain companies are allowed to take code without contributing
everything and their arms and legs back...
Then he added,
Another drawback of a license change might be that reverting from
(L)GPL license to previous licenses is said to be very hard.
This time the debate centered more on what a license change
would mean rather than copyright issues and possible legal interpretations.
Several people pointed out that only a strict interpretation of the LGPL
would disallow wrapper functions - namely, have an open source function
simply call the actual function linked in a proprietary DLL, hence it
would be easy to get around. Views on licensing ranged from,
Putting Wine under the xGPL is the best way
I can think of to ensure its future. The xGPL makes it possible
for competitors to cooperate for their common good - which is pretty amazing.
(Dan Kegel) to
The fact is that both the GPL and the LGPL
were written for the express purpose of destroying commercial software
vendors and hurting ALL programmers' livelihoods. (Brett Glass).
Ove Kåven posted a rather amusing
"Wine Developer License Test" to help everyone figure out where
they stand. (Full text at:
After much discussion, Alexandre interjected to thank everyone for emailing him their opinions. He asked for more developers to write him so that a conclusion could be reached. Ideas continued to flow. Gavriel State had one of the most interesting: set up a non-profit organization to manage the code and license it to corporations. Under this arrangement it would be possible for companies to gain exclusive access to the code for a royalty fee, or require that all modifications be submitted back to the main tree, or whatever was deemed appropriate. This isn't as strange as it seems - idSoftware has done this with the Quake 1 and 2 code it's released ( http://www.idsoftware.com/corporate/idtech/index.html ). Under this arrangement, developers that don't want to operate under the GPL can download the code from idSoftware, pay $10,000, and have the ability to keep their modifications confidential. Gavriel proposed:
As I mentioned, I have been considering the license issue for the last several days. It is a matter very near to my heart, as I believe that it affects not only TransGaming, but really the entire software industry. This posting is somewhat lengthy, but please bear with me.
Open Source software has made enormous strides in the last several years, and incredible amounts of great code have been produced. At the same time, it has been unable to compete effectively with proprietary software vendors like Microsoft, except in those areas where sufficient well financed companies have been able to direct full-time developer resources to the problem.
With the wellspring of dot com VC funding going dry, the question arises: where will the money come from to pay full-time Open Source developers? Just imagine where Wine would be without the code contributed by the half-dozen or so companies that have been involved. Imagine where Linux would be without the efforts of the companies paying for dozens of full-time Kernel hackers.
And imagine where we could be if just one or two percent of Microsoft's annual $25 Billion in revenue were being directed at Open Source projects.
The business models capable of supporting traditional Open Source projects are really rather limited: consulting services, technical support, and selling ancilary products with the software. None of these come close to delivering the levels of revenue that traditional mass-market shrinkwrap software can. So far, it is unclear whether they can support much profit at all for their proponents: RedHat, VA, and others bear witness to that.
TransGaming, for one, is working with some new ideas on how to do things differently, and profitably. There are a number of interesting possible approaches out there, and it is important to the entire world that we find models that work. Otherwise we are going to be stuck with the kind of information police states envisioned by the RIAAs, MPAAs, and Microsoft's of this world.
Now we are all here because we think that there are better ways to do software than the wholly proprietary approach. We want to be able to look at the code, tear it apart, fix the bugs, and make it cooler. And we want others to have the freedom to do the same.
Ultimately, the questions that need answering are these:
- What freedoms are important to the community?
- Can those freedoms be achieved without sacrificing other goals?
- What is the best mechanism for ensuring those freedoms, and ensuring the continued development of the code?
The Wine X11-style license essentially allows the code to be used anywhere, in any way. Users don't need to pay, Developers can take bits and pieces as they deem appropriate, and corporations can sell the product in whatever way they feel like. But it also has no legal mechanism to try to coerce further development of the project.
Current proponents of an LGPL license switch believe that a legal mechanism is important to protect the project.
Frankly, I am at a loss to understand the reasoning behind such a switch. I don't see any way in which any company could maintain their own fully proprietary fork of Wine without doing periodic merges into the public project. It's hard enough for TransGaming to do it despite the fact that we deal mostly in very specific areas. And even if someone was able to do so, how does it affect the Wine project any more than the existence of Windows or MainWin does? At most, it would affect the userbase, but in the current model that doesn't matter, since that userbase doesn't contribute significantly to the project. Only the developers contribute, and it is not at all clear to me that they would stop.
Marcus Meissner has already shown that the existance of our AFPLed DCOM code didn't stop him from going ahead and doing it himself. On the contrary - it helped him, since he got hints from our design. It's a shame that he had to, since we've been working hard to find a way to contribute that code back, and now we may have no way to recoup our investment. We still have a 2nd pass, more complete DCOM implementation under development, so it is possible that we be able to get a sponsor for that. But regardless, it clearly shows that having code outside the WineHQ tree is no impediment to the community reimplementing it if necessary.
The LGPL would severely limit a number of possible commercial applications of Wine, such as:
- Companies or groups that might want to take a small bit of Wine code here and there without taking the whole thing. IE: Corel's Mac porting work, or projects like MicroWindows or Odin (similar projects like Xine and ReactOS use parts of Wine this way, though they're GPLed, and thus would not be affected).
- Porting Wine to platforms with NDAed APIs. Or commercially oriented ports to other platforms which might not be viable under the LGPL.
- The work that TransGaming has done to support copy protection. Releasing that code all at once - as would be required under the LGPL - might violate the DCMA, since it reveals something of how the copy protection systems work.
- New business models like TransGaming's, with conditional-future- release of code.
While I am open to considering license changes that have the potential to benefit the project, I am very very concerned about the LGPL. Going that route is a one-way street with no turning back.
I've been thinking about these problems for a long time. As much as for any other reason, I started TransGaming with the desire to try to find good long-term solutions to the problem of how to fund Open Source development through the people who are actually using the code.
I have the germ of an idea that might be useful to address some of the concerns that the LGPL-license-change camp has had, while at the same time leaving the doors open for a much wider variety of different commercial activities. I have been trying to flesh it out while at the same time working to some very tight deadlines, and I have not had time to really think through some of the the possibilities that it entails. I am posting it to the list now anyway so that it's out there for people to think about.
Here's the quick and dirty version:
- A new non-profit company is created: WineCorp
- Developers contribute their work to WineCorp - possibly assigning copyright, or at least giving WineCorp the rights to do with the code whatever it pleases.
- WineCorp distributes the code under an AFPL-like license - no commercial redistribution allowed.
- WineCorp has a set of standing licenses allowing for commercial redistribution. A company can redistribute commercially if it does one of the following things:
- Releases source modifications to WineCorp immediately.
- Releases source modifications within a preset timeframe (maybe one year).
- Releases source modifications with some appropriate prearranged condition (ie: the TransGaming subscriber limit).
- Pays WineCorp a pre-set royalty, which WineCorp can then use to sponsor other Wine development
- For cases that don't fall into the above conditions, the WineCorp board of directors can vote to allow some other licensing arrangements. This helps prevent the kind of one-way ticket we have with the LGPL.
- WineCorp could also serve as a way for the userbase to direct funding and attention to different parts of Wine. To my mind, this is one of the biggest problem Open Source projects have. The end users get everything, but many don't contribute: no code, no money, no bug reports, nothing. The more they can be encouraged to contribute, the better off everyone is. WineCorp could solicit donations from users who can't contribute otherwise and possibly institute a subscription/voting system similar to TransGaming's.
One hard question the above idea creates is how does money gets split fairly amongst different developers working on particular parts of the code? I am sure that there are other problems as well. That said, I think that the importance of new models like this go far beyond the Wine project. Ideally, I hope that methods like these can be profitable enough to make proprietary software companies begin to consider opening up their code in a similar fashion.
Just imagine the day that Microsoft makes their first contribution to Wine, openly and without coersion by the government, because they recognize that doing so is in their own best interests.
Food for thought, anyway.
This thread is far from over. I'll try to publish the next issue as soon as there's an answer.
Someone wondered what was involved with using a program that required
ODBC access to a database,
has anyone used wine with a program that conects to an ODBC database? How
have you set this? I was thinking about FreeTDS but i configured it and
doesn't know what to do nexe. Any help?
Steve Langasek replied,
Based on what an ODBC driver actually does, and assuming a technically sound model, I see no reason that you shouldn't be able to use an existing Win32 ODBC driver under Wine to talk to a SQL server.
In practice, the issue may be far more hairy than that. :)
If the Win32 ODBC doesn't work for you, maybe the next thing to look at would be compiling FreeTDS's ODBC driver using libwine...
Bill Medland offered a quick suggestion,
unixODBC and DB2. It's easy enough for that.
Patrik Stridvall submitted some patches to allow compilation with
Microsoft's compiler. Gerhard Gruber asked,
Is this correct that tests are made to compile Wine on MSVC?
What good is this for? I thought Wine should be an emulation of windows
code on a Unix platform, what good is it to run Windows on Windows?
It would be quite nice to have all non core DLL compiling and working and with winetest ported. Then you could just run winetest through the debugger and be able to set breakpoint and step through the code in Visual Studio in order to get all to tests to run properly. :-)
Also note that this would make it possible to debug each dll in an enviroment where all other DLLs except the DLL tested were real Windows DLLs.
Michael Robertson of Lindows.com has invited many of the key
Wine developers to attend a conference in San Diego next month.
The agenda and speakers will
be the members of the WINE community. It will be a two day event on Friday
and Saturday where new ideas can be shared, new connections made, and you
can hear from the best and brightest pushing the WINE initiative forward.
Several people expressed interest in attending. As Alexandre
Just to clarify my position, I'll be going, provided that there are
enough other developers to make it worth it. In fact that seems to be
the general sentiment around here: "I'll go if you go" <g>
Mr. Robertson also posted a tentative agenda:
Transgaming, Success To Date [Transgaming/State]
ReactOS - Where it's at, where it's going [ReactOS/Filby]
Corel, A Look Back [Xandros/Tranter]
Crossover Strategy [Codeweavers/JW]
Macadamian - Making It As A Software House [Macadamian/???]
WINE's "Most Wanted": Features To Make WINE Great [???]
Developer Funding, Who Pays The Rent [???]
Future of WINE licensing [CW/White]
Development Model [CW/AJ]
NORM - The secret weapon [Codeweavers/???]
Making Fonts Not Look Like Crap [CW/Timoshkov/Davies]
Multimedia And WINE [email@example.com]
Regression Testing [???]
How To Improve The Debugger [Meissnerfirstname.lastname@example.org]
Maximizing performance of WINE [???]
Package streamlining of WINE [???]
WinNT APIs (Odin, ReactOS, winNT wine, WINE) [???]
WINE as a porting tool [Macadamian/Jacques]
Native user.dll [Dr. Ulrich Weigand]
API Standardization [???]
Jeremy White pointed out that he hadn't agreed to any of the topics with his name or Codeweavers.
Michael Cardenas had a question about implementing a new DLL:
Hello everyone. My name is Michael Cardenas and I'm working on Wine for Lindows.com. I'd like to start a lot more communication with all of you and I have a couple of questions.
I'm working on an app that uses a custom dll which requires msvcp60.dll to be loaded at launch time and won't launch without it.
Currently there's no implementation of msvcp60.dll in wine. Is that just because no one has needed it yet? Or has someone looked into this and seen that it's too large to do? Or is it just not needed and there's some substitute dll? Doing some research, I see that on a fresh install of Windows98, the dll is present, so it seems to be a common windows dll. MSDN mentions the dll in this article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/sidexsidewinxp.asp"A good example of this is the Microsoft Visual C++ Runtime assembly, which includes atl.dll, mfc42.dll, mfc42u.dll, and msvcp60.dll."
Also, there's been basically no discussion of this dll on this mailing list. So, to proceed, I'm going to create a stub dll and hope the app will launch and not need many functions from that dll. I'd like to know if there's a good way to make a complete stub for the dll. Right now, I just made a stub dll with one function.
Uwe Bonnes replied,
There is no "good way" know yet. It seems msvcp60.dll exports a huge number
of entries ( >2000). So I guess it falls in the mfc42 category (nearly
impossible to reimplement because of sheer size).
also has some good explanations around that redistribution license.
Andreas Mohr suggested:
Well, you might want to create an export table with the *real* function names...
Use pedump for that.
Also, it contains some common functions like mbrtowc() and such, so maybe it should be based on msvcrt. Most functions have mangled names and appear to be different, though. There was a way to demangle these function names. (I think winedbg includes demangling support)
Ove Kåven's suggestion was to just run something like
winedump spec dllname.dll -I/dir/to/headers -c -t -D
Damjan Lango pointed out the following news item:
Just found this on http://www.osnews.com/:
Direct 3D 8.0 Wrapper for OpenGL Open Sourced http://www.osnews.com/story.php?news_id=613
Not sure what is the license, but maybe it could be incorporated to wine as an alternative to the transgaming's version.
Patrik Stridvall pointed out the copyrights on the files weren't consistent and it was also unclear what the license status of the whole thing was. Gavriel State didn't seem too concerned:
Well, you're welcome to try, but their 'library' seems to consist mostly of stubs and Microsoft's own code. There is very very little there. The prospect is certainly not keeping me up at nights. 8-)
It might be better to help find us more subscribers so that we can release our real, working code to the WineHQ tree.
Dusko Rusmir needed to access a serial port at a speed of 5726, 5760, or 9600 bps. When he tried 9600 he got an error, so he assumed he needed to use a different speed. Lawson Whitney thought those were really bizarre speeds, but Dusko assured him the application required 5726 or 5760. After looking into it, Lawson determined that 5760 was possible, but Wine wasn't capable of handling that speed natively. He explained a little trick that could be done with setserial to get the desired speed:
Oops, 5760 is physically possible with a custom divisor of 20, I think. 5726 is not. You set the speed of a UART by loading an integer valus into the divisor regisgter. The UART then divides its maximum speed by that number. If the divisor is 2, it runs at 57600. There is no integer you can divide 115200 by to get 5726. There is also no provision in Wine to use a custom divisor, I think, but combined with linux system commands, there is. Set the app to use 38400. Beforstarting the app, do
setserial /dev/ttyS<n> spd_cust divisor 20
when the app asks for 38400, it should actually get 5760. If it doesn't work, show me the output of:
setserial -a /dev/ttyS<n>
<n> is the number of the comm port -1, unless you have ~/.wine/config set oddly. You can make "Com1" = "/any/damn/thing/index.html" but it might not work, or "Com1" = "/dev/ttyS3/index.html" (if the serial port you mean to use is on com4, that will work, but it will confuse me unless I see your .wine/config)) and
wine --debugmsg +file,+comm blah.exe 2>&1 |tee ~/logfile
(a copy of the debug messages will be in ~/logfile) gzip it before putting it in the mail, please.
Then Lawson turned to the wine-devel list for an explanation of how it might be possible for a UART to run at 5726 bps. Gerard Patel explained:
If you have access to Google, search for the following Usenet posting, for example: UnHy6.600095$JT5.email@example.com
If you can't use Google, you could see that this is a common request under Windows. quite a few programmers need to access devices with non-standard crystals, or even non 8251 chips with specific drivers. In this post, you could see that SetCommState accepts any baud rate up to 9600 bauds, and that over 9600 bauds the idea is that the Windows driver should accept values that are inside a +-1% interval of the 'correct' value (although the poster says that the calculation is bugged and works only for negative differences).
The Windows code for the 8251 family is probably always rounding to the next integer value under 9600, and if the wanted rate falls to +-1% of the 'normal' value over 9600. As I understand it, the 1% tolerance is explained because such a small difference don't matter for asynchronous serial communication.
That made sense to Lawson and he offered to take a stab at fixing SetCommState to behave like the native one.