Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins|
Table Of Contents
|1.||6 Dec 2001 - 22 Dec 2001||(175 posts)||Wine License Change?|
|2.||18 Dec 2001||(1 post)||NetBSD Port Working|
|3.||16 Dec 2001||(1 post)||Antitrust Remedy Proposal, Take 3|
|4.||18 Dec 2001 - 19 Dec 2001||(6 posts)||CryptoAPI|
|5.||22 Dec 2001 - 23 Dec 2001||(3 posts)||Windows Screensavers|
|6.||22 Dec 2001 - 23 Dec 2001||(9 posts)||Modal Message Boxes|
|7.||22 Dec 2001 - 23 Dec 2001||(3 posts)||Updated Wine Tasklist|
This is the 111th 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).
Is there more to Lindows than just hype? They've updated their website, though it still lacks any details on what they're putting together. A release is due out by the end of December, will they make it?
Merry Christmas and Happy New Year!
Mailing List Stats For This Week
We looked at 272 posts in 1076K.
There were 51 different contributors. 30 posted more than once. 24 posted last week too.
The top posters of the week were:
1. Wine License Change?
6 Dec 2001 - 22 Dec 2001 (175 posts) Archive Link: "RE: Installshield 6 (inter-proc) patches"
People: Alexandre Julliard, Patrik Stridvall, Gavriel State, Jeremy White, Ove Kaaven, CodeWeavers, , Transgaming, Patrik Stridval, Ove Kåven, Lionel Ulmer, TransGaming, Gerard Patel, Codeweavers
If you normally skip over anything that has to do with licensing, I urge you to read on. This won't be too painful. I promise.
Last week's episode left off with Gerard Patel mentioning that he didn't have an ETA for when some Transgaming patches might filter into the main Wine CVS. Alexandre responded with, " Well, this worries me. It sounds like you are planning to do the same thing you did with your DirectX stuff: by making the code available on your site, and promising to release it at some hypothetical future date, you remove all incentive for other people to spend time improving the main Wine, thus ensuring that it always lacks some features. I don't like this at all. "
Over the past week that thread has morphed into a wide ranging discussion how to best protect the free ("libre") interests of the project and how to ensure fair treatment of users, developers, and commercial interests. Before I dig into the positions of various developers, I think I need to provide a little background information. Almost two years ago there was discussion on the list about moving towards the X11 license, in case your memory was as foggy as mine you might want to check out KC Wine #20 and KC Wine #27. The license at the time had some requirements that may have made it incompatible with other software projects and possibly not even a true open source license. Back then the concensus was to use an existing license "written by lawyers instead of hackers". So the move was done to a BSD-like license.
Licensing will perpetually be a topic that you had best put a fireproof
suit on in order to participate. In the open source world there are basically
three style of licenses to consider. The first is
GNU's General Public License. The
GPL is perhaps the
most well-known open source license. If you write a program, release the source
code, and place it under the GPL then all future modifications are required to be
released back as free software. Then there is also the Lesser General Public
License (LGPL). One
of the main differences between the two is that the LGPL allows you to link in
proprietary (non-open source) code into the program when you compile it. Then
there's the Wine license which basically allows anyone to do anything with the
source. In particular the Wine license, based on the X11 license, which
in turn is based on the BSD license, specifies:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Of the three, the GPL is the least applicable. One of the main purposes of Wine is to allow Winelib to be used to compile existing Windows applications to run on a different platform. Very few companies would be willing to allow their application to be compiled on Linux with the restriction that their entire code base be open sourced. As much as Richard Stallman disapproves, it would work against the Wine project. So the debate comes down to allowing companies to co-opt the work of the Wine authors and create a proprietary product that gives nothing back to the community. Thus far, all companies that have worked with Wine have been very benevolent and contributed immensely to the project. Corel, Codeweavers, and Transgaming must all be congratulated for the contributions they have made. The LGPL license would ensure that continues, however there are concerns it is a deterrent to companies thinking of jumping into developing with Wine. As Patrik Stridvall put it, " The current license is something that is easy to understand and are unlikely to scare companies like Transgaming away, but can you really say the say same about LGPL?"
So let's dig a little deeper into what's going on and the various concerns people have. Transgaming's use of the AFPL license prompted the discussion at hand. The AFPL allows you to view the source code however it cannot be merged back into the Wine CVS tree. The next post after Alexandre's was from from Gavriel State. Gav wrote:
The DCOM issues had been ignored by other Wine developers for YEARS before we came along. It's not at all clear that our work there has discouraged anyone else from working in that area. To say that our work is preventing anyone from doing a free version of DCOM is completely incorrect. To the contrary: we have already contributed substantial amounts of this code to the public tree - thousands of lines, in fact. That can only help anyone with a sudden and unexpected interest in recreating our work.
Now, it is our firm desire to see *all* of that code end up in the main version of Wine. The fact is, unfortunately, that we simply cannot afford to give everything away as soon as we write it. We only got a minimal implementation of the DCOM code working six weeks ago. We are not a rich company, with millions in VC funding to burn; this means that our DCOM work has to remain under the AFPL until we can find a sponsor willing to defray some of the tens of thousands of dollars it cost us to develop it.
Furthermore, we are committed to writing quality, robust code. We don't think it's in anyone's best interest for the current version of the code, which is effectively limited to the requirements of InstallShield, to be used as the basis of future DCOM related work. We in the midsts of working on a much more flexible architecture which will permit more than just typelib based proxying.
I don't really think this affects individual users at all. They can simply download and use the code from our website, or apply the necessary patch to WineHQ wine. They can even redistribute it all non-commercially should they wish.
Without a doubt, we are committed to the Wine project and have already contributed a great deal of code to support it. However, to maintain the quality and integrity of the project, we stand by our decision of only contributing code when it makes sense to do so (in order to allow us to continue developing quality code) and when it reaches a certain minimal degree of quality.
Publicly questioning our ethics is certainly not the right solution nor is it in the spirit of the project, especially given how much we have supported it to-date. We believe that we ARE doing the Wine user and developer community a service and propelling it further. The only people that our lack of haste in contributing code back really affects are organizations that want to make immediate commercial use of the code. These organizations include the one you work for, and its clients. If you want to see the DCOM code Wine-licensed soon, you need to talk to your boss and your clients, not me.
At this point, I think it would be best if we were to take this discussion off-line so that we can determine a solution that works for everyone.
The discussion is very far ranging, but while we're on the topic of Transgaming's position it is probably helpful to include a later message by Gavriel:
Discussion on this topic seems to have somewhat bypassed what I believe are some key points:
1) Wine *needs* corporate developers.
Without the funding, code, and profile that the various corporate developers have brought to the table, the project could not be where it is today. Without continued support from companies able to afford to fund development, the future prospects of being able to keep up with Microsoft's API changes is very bleak indeed.
2) The current Wine license played a very significant role in the involvement of some of the past and current corporate players.
I can state categorically that if the Wine license had been GPL or LGPL, Corel would not have invested the millions of dollars it did into Wine development - I was the one who made that decision. There were three choices: Wine; Go it alone, based on the work we had done on the Mac; and Willows TWIN, which was LGPLed.
At the time, TWIN was much better suited for source-level porting. The reason we went with Wine was almost entirely because of the license. We knew that we would be able to take code we had developed for Wine and use it in our Mac work and elsewhere.
If the Wine license had been LGPL, TransGaming would most likely not have been started. The LGPL would not have given us the flexibility to explore the subscription/voting business model that we're using.
3) Our work has not affected other DirectX work in Wine.
Except for Direct3D, all our DirectX work goes back to Wine. We have already contributed our major DirectDraw restructuring work, and many other pieces. There is ongoing work by non-TransGaming developers on non-3D DirectX related areas in Wine, including both the x11drv and dib code.
The only thing that we are keeping back here is the D3D code. The only other developer who has ever worked on D3D in Wine is Lionel Ulmer, and the last time he did significant work on D3D was in early 1999 - on much earlier DirectX APIs. Experience with 3D development is rare. There are very few developers who have the required skill-set, and fewer still willing to volunteer their time on Open Source projects. If there is anyone out there who has the experience necessary to do D3D work, please let me know: I want to hire you.
We do have a bit of merge work pending for non-3D components, which we hope to get to soon. The delays there have nothing to do with licensing issues though - they're more about development process and CVS policy.
4) We would not have been able to afford to do the DCOM work under the LGPL.
The DCOM problems with InstallShield had been kicked around for a very long time before we finally stepped up to the plate to do something about it. We poked around a bit to try to see if there was anyone willing to do the work on the Wine side of things, sponsored by us, but didn't have much luck.
In the end, we decided to go ahead with it in the hope that along the way we could find someone to sponsor *us*. If we had known how much work was going to be required, I'm not sure that we would have done it at all.
It took months of effort for us to get DCOM working with InstallShield, and cost us tens of thousands of dollars. We're a very small company, and much of that money came directly out of my personal pocket. I haven't had an income for over 18 months, and I have an 8 month old daughter to support.
The several months worth of effort we put into DCOM also had a huge opportunity cost: that was all time that we could have spent on improving Direct3D instead, which is, in the long run, where our primary business is.
If I had thought that there would be no possibility of finding a sponsor for the work because we would have been forced by the LGPL to make the code available immediately, we would very simply have ignored the issue entirely and just continued to wait for someone else to do it while we worked on DirectX. Given the complexity of the DCOM/InstallShield issues and the amount of effort required, I believe that we would have had to wait a very long time.
The fact is, I would *love* to release the code now. I don't want us to shoulder the burden of maintaining it - that's not where we should be spending our efforts.
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.
Note though that we *have* contributed substantially to all kinds of related code, including typelibs, rpc, safearrays, etc. I feel that the work we have contributed so far is fair reciprocation for the work that other commercial Wine developers have brought to the table.
5) Using the LGPL may limit the abilities of those who need to work on code that cannot legally have source revealed.
One of the other non-DirectX things that we have spent significant amount of effort on is copy protection. We have extended Wine to support both SafeDisc and SecuRom protected programs. For the moment, our work on this code is not even in our AFPLed tree. Until we have a chance to make a legal determination on whether or not releasing the source code would violate the US DCMA, we have little choice but to keep it secret.
If Wine was LGPLed, we might not have the option to distribute this code at all, which would thus severly limit the utility of our entire endeavour. It's not hard to imagine other commercial efforts where similar issues might occur.
6) Additional limited AFPL-style licensing of portions of Wine could be a *good* thing for the project, not a bad thing.
The more developers there are getting paid to develop Wine code, the better. Volunteer developers alone will not be sufficient to move the project along quickly enough.
An AFPL style license that restricts only commercial redistribution of code, but permits all other use and redistribution is an excellent way of making the code available to Wine users while still allowing developers to be paid for their efforts by forcing entities that want to make commercial use of the code to contribute something in return. Ideally, things would be structured such that code would be sponsored by a commercial entity to be relicensed under the Wine license.
I would *love* to see more of the volunteer developers working full-time on Wine, supported through such a sponsorship system.
Really, that is the ultimate goal of our subscription system. With a sufficient number of users contributing to our system, we want to begin spreading some of the funding around to developers willing to work on the features our users have voted for. In fact, we're basically ready to do this right now. Anyone who wants to look at this list:
and who chooses to work on one of the poll items is welcome to send me a proposal for sponsoring their work. They can make their code available under the AFPL while we determine if it fits the need, and if we like it and agree to the price, we will be happy to pay to make it available under the Wine license.
I firmly believe that this kind of arrangement is going to play a key role in financing the development of all kinds of Open Source projects in the future. I could be mistaken, but at the least, I think that it is important to run the experiment and see.
Got all that? Basically Gavriel's position is that the current license doesn't place any restrictions on how he runs his business. Most likely the LGPL would allow the same things, but with the X11 license it's a no-brainer. And, as Gavriel mentions, he was able to release a product when there were concerns over whether releasing source code would violate the US Digital Millenium Copyright Act.
Well, unfortunately it's not quite as simple. As Alexandre explains it, " But the thing that the Transgaming stuff should make us realize is that if that work is released under a free but non open-source license, it competes with Wine for user and developer mind share, and it hurts Wine no matter how much we try to ignore it. That is a new situation that I believe we didn't take into account when picking the current license. " Alexandre also wondered about the future, " What will happen if 5 different dlls are improved and released by 5 different companies under 5 different non-free licenses? " There was some debate over the details of how that would occur. There was also a lot of discussion on constitutes linking in foreign code and how companies could circumvent the LGPL by doing that. Now that the DLL separation is in place the Wine source is much more modularized and it's much easier to hook in other code that provides core functionality.
Jeremy White of CodeWeavers was neither for nor against a license change. He listed several reasons how it would both help and hurt his business. Jeremy wrapped up by stating:
With all that, speaking on behalf of CodeWeavers, I would neither call for nor oppose a switch to the LGPL. Since that change would impact me and my customers somewhat slowly, I think I could make the necessary adjustments in time. The most important thing is for us to continue to have a vital and thriving Wine community.
Finally, speaking strictly on a personal basis, and with no corporate considerations whatsoever, I would welcome a change to the LGPL; I have always preferred it to BSD style licenses (and to the GPL, for that matter); with LGPL projects, I feel more certain that I know exactly where I stand and how my code will be used..
Much of the rest of debate centered around the following issues (some of which have already been stated):
During the middle of the thread Ove Kåven broke in to mention why the InstallShield patches (the original subject at hand) hadn't been submitted back to the Wine CVS:
Well, not all of it is ugly, but some crucial bits are. Here is the biggest reason I never considered that patch eligible for inclusion into official Wine without a cleanup:
@ cdecl COM_ConnectProxy(ptr ptr) COM_ConnectProxy
An internal procedure exported from ole32, to be used by oleaut32... YUCK
Another big issue is CoMarshalInterThreadInterfaceInStream, which simply can't do the right thing with the way I structured things, and I believe that is why repainting doesn't work while installing. The correct functionality requires proxying between COM apartments, without any class activation being involved, which calls for a completely different communication structure than what those hacks use.
I'm still working on the restructure that is supposed to fix these issues. So it is my preference that the current InstallShield patches *not* be applied to WineHQ, but my new upcoming code be used instead. It should be ready within a couple of weeks.
As to the political issues discussed on this thread, I'm not supposed to give any kind of official comment, but I suppose I could tell you my personal view on the situation.
I'd personally love to submit all my code directly to WineHQ under the X11 license, without hesitation, even though it did take me a long time to get that code working. However, it was Gav who gave me money I could pay my bills with during the long hours I spent working on it, so I feel obliged to help him recoup that investment in any way he can. Whatever strategy he'll use to do so, is up to him. But in my opinion, my code (the rewritten code, that is, not the old code currently in WineX) is eventually destined for WineHQ, the only negotiable issues for me are when, how, and who pays for it.
As for the license of Wine, I was among the ones opposing the LGPL last time it was discussed, and I have not changed my mind. I feel that Wine is most widely useful if it keeps the X11 license, and usefulness is more important in my mind than making it 50% harder for companies to "steal" the code. If X11 is so bad for large projects such as Wine, why is the largest project of all, XFree86 (and associated projects like DRI), still using it, even though its maintainer would have the power to switch to e.g. the LGPL or even GPL with a snap of the fingers ("sublicensing" it)?
I think Alexandre is not quite correct in his projection that making Wine code available under a semi-open-source license unconditionally inhibits work on the free version of Wine. I think that there's a completely *different* reason that people do not work on the free version, which is the prevention of duplicate work, in order to preserve precious development resources. The code in WineX will eventually go back to Wine, hence there's no reason to duplicate development. If people thought WineX code would never go back to Wine, I'm sure they would continue working on the free Wine. I know I would. But when the code *will* go back to Wine, having people getting paid for doing it fulltime is better than wasting precious volunteer time on duplicating that kind of work for a much slower progress... I think Wine will do well by keeping the X11 license, and I'm not speaking for my employer.
I've periodically tried to merge most of the stuff we do in WineX (other than Direct3D) back into Wine, both to make the free version as usable as possible, and make it so that people *can* work on the free version of e.g. DirectX without fear of duplicating our work (and I think Marcus and Lionel wanted to add Xv support to the free version of ddraw/x11drv HAL, they're completely free to do so now without too many conflicts, I reckon they just haven't had the time yet). However, I only do such merges when I consider the official Wine to be in a relatively stable state, which it hasn't been recently due to Alexandre's rewrites of this and that, so I haven't had the opportunity to merge everything I wanted to merge back yet...
Well, I think that's pretty much what I wanted to say. But I only speak for myself; for official TransGaming position statements, look for postings by Gav...
After everyone had expressed their opinion, some several times (and in the case of Patrik Stridval even more than that), Alexandre announced:
OK folks, I think we are way past the end of the useful part of this discussion, and it's time to come to a conclusion. I'll ask people who want to continue arguing the fine points of the LGPL to please do it by private mail.
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.
Thanks to everybody who participated to the discussion, and now let's go back to writing code...
2. NetBSD Port Working
18 Dec 2001 (1 post) Archive Link: "NetBSD port is now working"
People: Bang Jun-Young,
Bang Jun-Young sent a patch into wine-patches with the following note:
3. Antitrust Remedy Proposal, Take 3
16 Dec 2001 (1 post) Archive Link: "Microsoft Antitrust Remedy proposal, take 3"
People: Dan Kegel,
Dan Kegel provided an update on his Microsoft antitrust remedy:
I've learned a fair bit since putting together my essay on the States' proposed remedies. In particular, Microsoft's response to the States was enlightening; it pointed out the parts of the Court of Appeals ruling that need to be heeded when fashioning a remedy. I now feel that the States' proposal has little chance of being accepted by the judge. The Proposed Final Judgment negotiated by Microsoft and the DOJ is probably the right starting point for any new proposals.
Accordingly, I've started over, and this time I'm sticking very close to the negotiated settlement, and paying close attention to the law.
As before, you can read my proposals at http://www.kegel.com/remedy.html
I'm looking forward to your feedback. I've set up a mailing list at http://groups.yahoo.com/group/ms-remedy/ (aka email@example.com ) for those who want to discuss this further. Together we can find a way to make the settlement more just and fair, or I'll eat my hat.
18 Dec 2001 - 19 Dec 2001 (6 posts) Archive Link: "CryptoAPI (no, this has nothing to do with licensing! YAY!)"
People: David Elliott, Alexandre Julliard, Travis Michielsen, , David Elliot
David Elliott announced:
A while ago I started hacking out an implementation of CryptoAPI. It sat idle for a while and a few days ago I decided to start doing a bit more hacking again.
The basics of ADVAPI32's CryptoAPI part is that it does nothing except provide an interface for applications to call into CSPs without actually loading the CSPs themselves.
At the moment the TESTCSP.EXE with its accompanying CSP.DLL is starting to work. These are from Microsoft's CSPDK and include source code. I have not tried compiling the source with Winelib, that is a later project.
At the moment this code keeps track of which CSPs are loaded and which CSP an HCRYPTPROV handle uses. This allows testcsp to load up csp.dll and do a few things, but not everything.
What bothers me though is that it does not get Intenret Explorer to load up the RSA CSP. The LoadLibrary fails because the DllMain function in the CSP returns FALSE. I speculate this has something to do with the fact that a real CSP needs to have its image verified before it will load. Or maybe it is something different entirely.
Anyway, still left to be done are to keep track of Key and Hash handles (trivially easy) and maybe some other stuff.
As far as putting this into the tree goes, I don't think it would harm anything, although I noticed that the GenRandom function had a useless implementation in it. It now has what I believe to be the correct implementation, but if loading the CSP fails that CryptGenRadom isn't going to work. Did somebodies appication actually depend on this behavior or was it implemented just to have something there?
In any case, this still needs to be cleaned up a bit, but I am hoping to get some input on why I cannot load a real CSP as this is all completely useless (well, not completely, but for my purposes) if a real CSP cannot be loaded.
Is this rsabase.dll? If so this is because of a problem with
LOAD_LIBRARY_AS_DATAFILE; I have a patch for this somewhere.
Actually, rsaenh.dll. I am running IE 5.5 and accessing
https://internetbanking.suntrust.com/. Not that this site doesn't work
with Galeon anyway, but it seemed like a fairly simple way to test the
Alexandre supplied the patch just as
Travis Michielsen jumped in to mention:
Actually I too, have been hacking away at the CryptoAPI (advapi32.dll) and was going to submit a full patch for it at the end of the week. My patch, however, has almost a completely different approach to the problem! Attached is my version (not quite complete or clean).
Anyway I think the correct thing to do right now is to co-ordinate our work to make a single patch and implementation.
David agreed, " YES, definitely. Sorry to be stepping on your toes here. Most of the CryptAcquireContext function, specifically the parts that look up which CSP we need to load, I implemented rather quickly months ago. I didn't have time to do anything until a few days ago when I wrote everything else and posted it on wine-devel."
Both of the patches are quite large. It'll be interesting to see how the approaches get merged together.
5. Windows Screensavers
22 Dec 2001 - 23 Dec 2001 (3 posts) Archive Link: "Windows screensaver"
People: Gleb Natapov, David Elliott, , David Elliot
Gleb Natapov asked, " Is it possible to run windows screensaver in linux using wine? If not, how hard it will be to write support for this?"
The answer is yes. As David Elliott explains:
Well, there are a few issues:
XScreenSaver creates a virtual root window on top of everything which it then runs the screensaver program in. That way the screensaver program still thinks it is just drawing in the root window, but in reality it is drawing on top of everything. XScreensaver also takes care of dismissing the screensaver when you move the mouse. I believe it does this by sending it a signal of some sort, although I am not entirely sure. You really ought to read its documentation to get all the specifics on this.
However, you /can/ add a line that runs wine to run the screensaver in your .xscreensaver file. In fact, I just tried this. If you run in demo mode you get the expected behavior, it won't go away until you click a button. If you set it as your screensaver and do a normal blank (i.e. not lock) then it'll go away when you move the mouse. However, if you do a lock screen it'll clear the screen to black when you move the mouse, ask you for your password (which for some reason it didn't accept the first time, but maybe I just typed it wrong). Anyway, once you type a valid password you are still looking at the screensaver until you move the mouse again.
So basically it already does mostly work. One way to decrease the startup time would be to start the wineserver in persistent mode before hand. Then the first time you load the screensaver (or some other windows app) it'll take a while, this is because the first client to connect has to set some stuff up. However, after that the wineserver is running and ready to go so it doesn't take very long for the screensaver to start up. (I just checked this, and that is what happens).
One thing you could maybe try to do to decrease this is make a very lightweight wine configuration in a different directory. You can use the WINEPREFIX environment variable to do this. With a bit of configuration you could have a wineserver running permanently listening on a socket in $WINEPREFIX instead of in the usual ~/.wine directory. Also that way when you run windows apps it doesn't affect your other wineserver.
As far as fixing the behavior goes, I have a few ideas. Wine supports a "Desktop" mode where a desktop window is created and all wine drawing is done to that window. You could maybe change wine a bit to allow wine to draw into an already created desktop window (e.g. draw into the root window). That might make things behave a slight bit better. In fact, doing that alone might fix everything. And I also think that doing that should be simple (and maybe there is already a way to do this).
Hope that helps you to figure it out!
6. Modal Message Boxes
22 Dec 2001 - 23 Dec 2001 (9 posts) Archive Link: "fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet."
People: Laurent Pinchart, Ove Kaaven, , Ove Kåven
Laurent Pinchart wrote:
When trying to install The Longest Journey (an adventure game), I ran into a problem with modal message boxes.
The installer displays at some point a task modal message box, but for some reason the box disapears almost instantly, and I'm stuck with a focused installshield screen on which I can't do anything as the task modal msgbox is invisible and unfocused.
I'd like to implement the modal message boxes to fix my problem, but I don't know where to start. Could someone give me a few indication about what would be required to achieve a proper behaviour or modal message boxes ?
Ove Kåven replied, " This has been discussed before, most recently on wine-users, I think... Are you running in managed mode? Then try this patch: http://www.winehq.com/hypermail/wine-patches/2001/11/0126.html"
That didn't seem to fix the problem. Laurent began looking at a lot of code and eventually figured out his problem:
Sorry for all of those who were looking forward for MB_TASKMODAL support, but I fixed my problem without having to implement that.
The problem came from
which didn't react properly to the
I attached a patch to this e-mail, comments are welcome.
7. Updated Wine Tasklist
22 Dec 2001 - 23 Dec 2001 (3 posts) Archive Link: "Wine Tasklist"
People: Francois Gouget,
Francois Gouget has updated his "Call for Volunteers" tasklist:
I would like to establish two Wine tasklists in Wine's bugzilla.
For the first list, refer to my previous 'Call for Volunteers' emails. I think I will start it from there and we can update it after that. For the second list, I included a first draft below. I would like your comments on it, especially with regard to the status of some of these items, and suggestions if you see missing items.
I know we already have a 'Wine 1.0' and 'Wine 1.x' tasklists'. There may be some overlap but I think the intent is different.
My intent with these two new tasklists is to advertise what we want to do to potential contributors. So the idea is to then add a page to the WineHQ web site that would list all the ways one can contribute to Wine: maintaining an application entry in the Application Database, helping users on the mailing lists, buying Wine based applications, and of course contributing code. And for this last item, these lists would provide a good starting point, both for developpers with little time and for developpers who want to invest themselves more heavily in Wine.
Then unlike the 1.0 and 1.x tasklists, these new lists would not be tied to a specific Wine release or date.
I hope to produce a draft of this web page in the coming days. In the meantime let me know if I missed things in the list below. For each item I tried to indicate the rationale behind the task, and point to the corresponding bugzilla report if there is one.
Make the registry loadable on demand
Cross process messages
Out of proc COM
Better multi-user support
UNC path handling
Native Alsa support
Write a regedit replacement
Write a regsvr32 replacement
Fix the desktop mode
Compile with STRICT on
Move the winsock16 code to wsock32
Check .spec file completeness
Winedbg expression handling
Winedbg g++ 3.0 support
Better memory allocator
Winelib richedit support
Visual C++ project support
Specify how to compile and package the MFC
Sharon And Joy