February 2002 - Wine-devel - list.winehq.org

FW: Patch: Double-click support
by Michael C. Maggio 15 Feb '02

15 Feb '02

It looks like this patch wasn't applied to CVS and I didn't see any comments here in wine-devel. Before I resubmit I just want to make sure that it wasn't turned down for any particular reason. =Michael C. Maggio http://www.voyd.net/ -----Original Message----- From: Michael C. Maggio [mailto:voyager(a)voyd.net] Sent: Tuesday, January 15, 2002 1:27 AM To: wine-patches(a)winehq.com Subject: Patch: Double-click support This patch adds support for double clicking in Wine. The added function, _is_dblclick(), is invoked with each button-down mouse event. The event must be the same button (left, middle, or right), at the same X,Y position, and occur within 500 milliseconds from the previous event. The original button-down event is still invoked regardless of the double-click. Tested in Starcraft. :) Ideally, we may eventually want to determine the double-click delay time from the registry, as it is a configurable Windows setting. But this should serve the purpose in the mean time. One last tidbit of info - I did not add a function prototype to any header files given the limited scope of this function. Whether this deviates from the Wine Development Standard (tm), I do not know. Perhaps a local prototype is more suitable in this case for the sake of ANSI-C compliance. I would appreciate knowing, at least, what the preferred method of prototyping is. ChangeLog: Adds support for double-click events via _is_dblclick(). =Michael C. Maggio http://www.voyd.net/

2 1

Re: Dr. Seuss, licensing, and WINE
by Brett Glass 15 Feb '02

15 Feb '02

Rick Romero (rick(a)valeoinc.com) writes: >As long as I'm sending this, I might as well make a comment on the >license. We all know money makes the world go round. If the current >license makes WINE more enticing to businesses, it should stay with that >model. If the LGPL encourages investment (time or money), then WINE >should move that way. IMHO, it appears the current license is best in >the long run. I agree. >The biggest issue I've seen so far is people ego's going >out of control when they've shared their work with the public, and >someone else hasn't returned their share (and possibly making money off >of it). Perhaps a simple economic analysis would help to assuage those egos. If WINE is available at no cost to any user, its market value as a product (defined as what a willing buyer would pay a willing seller for a license to use it) is zero. No one will pay money for something that's readily available for free. (They might pay a small amount for the service of pressing it onto a plastic disc, but with today's Internet there's no need even to do that.) Yes, its intrinsic value is higher, but what matters to users is market value -- what they have to pay to get it. Given that the market value of WINE, as distributed at no cost over the Net by the WINE project, is zero, anyone who hopes to sell a version for money must add sufficient value to get users to pay for it. This added value must not only be worth the money that customers pay (or word will get around and the company will make no sales) -- it must also be enough to overcome the transaction costs that the user incurs (filling out a Web form, paying shipping costs, waiting for delivery, worrying about credit card fraud, picking up the package at the post office, etc). And the seller of the value-added product will have a tough time convincing the user that the added value is sufficient to warrant the purchase. Is the no-cost version "good enough?" As WINE improves, it will be -- for more and more users. Thus, anyone who hopes to create a value added version of the product has a tough row to hoe. He or she must add a LOT of value -- and also provide support services, infrastructure for distribution, a sales staff, marketing, and much, much more. And he or she must stay ahead of the no-cost version, which over time will likely duplicate the most important value added features of the commerical release. Finally (and most importantly), if users DO buy the value added product, every cent they pay will be not for the original product (whose market value, as entioned above, is tautologically zero) but for the value added by the vendor. Thus, no developer of WINE can claim that the vendor is "making money off of" WINE. EVERY CENT will be due not to what the WINE project did, but to the value added. If the vendor is able to make money at all (and it's a long shot), he or she thoroughly deserves it. And every copy sold will benefit the WINE project, because the project's reputation will be enhanced by the vendor's success and the vendor will become more and more able to contribute code back to the project. (The vendor MUST, of course, retain some of its code so as to provide unique value; otherwise -- again -- no one will pay and everything falls apart. But at the same time, it benefits from contributing code with less strategic value, because the project will maintain it.) It may be that the vendor won't be equal to the task of adding sufficient value to stay in business. But if he or she does, it's a win/win. The project benefits from an enhanced reputation and from code that's returned to it because it's in the vendor's interest to do so. It's thus in the project's interest to help, not hurt, the vendor. The (L)GPL destroys this delicately balanced symbiotic relationship by making it impossible for the vendor to add unique value. As a result, the scenario described above can't happen, and it's a lose/lose rather than a win/win. The only entity that wins is the FSF, whose stated purpose is to prevent any commercial software vendor from surviving. --Brett Glass

6 14

Re: Licensing response and an idea
by Lean Fuglsang 15 Feb '02

15 Feb '02

Thanks for an enlightening post, Gav. //DISCLAIMER - I AM JUST AN ORDINARY USER - SO DON'T READ IF YOU DON'T FEEL LIKE I am not a developer (yet). But I truly believe in the spirit of OpenSource Free software. I have reported some bug reports, but I would really like to contribute more. When I first heard about a (very) possible licens change to GPL I thought it was a great Idea, because I hate companies who take code and don't contribute back. With the current license this is possible. But I also think it would be a shame for companies with good intentions (as Transgaming) who (maybe:) will contribute all there code back, and make very fast directed code to wine. I would also be very delighted to pay money directly to the wine project because I like it and use it. An important note is that this is what I do with everything that I buy. When I by music, it is because I like it and have heard it and want's to support the artist. Same with movies. I know this is not the way the corporate world works at the moment, but I can pirate music/video/software very easily and therefore they have to trust me to pay for what I want's to pay to. Phew, hope I didn't confuse all of you (like I confused my self:) But the point is, I really like to make contribution to a gratis project if it is GPL'ed or dual licensed (for 'good' corporations). Many of the people I know has the same 'Ideology' as me, and don't pirate things they think aren't sh**t. And after I have changed to linux and opensource, I have actually pirated a lot less, because all stuff are free, and the things that aren't 'stands out', so to speak. Just my .02$ (and maybe more if it goes as I hope:) //lean Ps. Hope I send this mail to the right place

8 14

Re: Wineconf attendance
by Michael Robertson 15 Feb '02

15 Feb '02

We currently have 35 registered people not counting the inquisitive reporter who signed up. I believe all are from wine-devel list since that's the only place I've seen it mentioned. Companies represented include: - Codeweavers - Transgaming - ReactOS - Macadamian - Xandros - Cadlink Technologies - Caldera - DSSD Software Inc. - 2 Geeks Computer Systems - DeviceForge - Some big OEMs - Other companies - A bunch of unaffiliated people If you would like to do a company presentation, please let me know and we'll do our best to accommodate. On the technical track, since attendees will be the speakers please think about the topic that would be interesting that you are knowledgeable about. This is all about people leaving smarter than they came and that happens best with everyone sharing their information and ideas. One of the 3 people on the Frankfurt/San Diego express, Dr. Ulrich Weigand has volunteered to speak on the following two topics: - 16-bit Windows: how does the support for 16-bit in Wine work, how much 16-bit code is still there in Windows 95/98/ME, how are the various types of thunks etc. implemented, what are the chances of running native Windows 95/98/ME 16-/32-bit DLL pairs under Wine (this would include the user.dll question Uwe suggested) - Debugger: how does the Wine debugger work, details about the various debugging formats (including the undocumented .PDB format) ... The biggest request is to hear from Alexandre Julliard who is working on his keynote to open the event now which rumor has it is better than the opening ceremonies of the Olympics. Only one request for "fencing and WINE". Sorry Gav. :) -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

2 2

RE: drawtext should not split words on clipping
by Medland, Bill 14 Feb '02

14 Feb '02

> -----Original Message----- > From: Joerg Mayer [mailto:jmayer(a)loplof.de] > Sent: Thursday, February 14, 2002 2:42 PM > To: Medland, Bill > Cc: Wine patches (E-mail) I think we're supposed to discuss these on wine devel > Subject: Re: drawtext should not split words on clipping > > > I've only read the description, so maybe I'm guessing wrongly what the > path does. Sometimes it is preferrable to split a word in the > middle to > not splitting very long words (like URLS). Yes, but you don't split it by saying it should be clipped; you split it by specifying, for example, DT_WORDBREAK | DT_EDITCONTROL (which results in breaking within the word if the whole word doesn't fit) This is a small part of a long sequence of changes that, I believe, are required to make DrawText work correctly overall, especially when it comes to ellipsification and word breaking on multiple lines. (The current version believes that ellipsification is only done if DT_SINGLELINE is specified!!). Maybe there is some case where the existing code "worked" by accident and it doesn't now but if so then I believe it should be fixed properly (which won't really be possible until I've submitted a couple more major reworks). Actually it's getting difficult to figure out how to do the next stage without a 500 line delta, because somewhere along the line I think it requires a complete revamp of the core routine (and, tempting as it may be, I am not happy submitting 250 lines of code that aren't yet called but will be when I submit the next delta). I am perfectly happy to discuss this with anyone who wants to; otherwise please bear with me. I honestly believe I know what I am doing. Regards Bill

1 0

Re: WineCorp (was Re: Wine license change)
by Roger Fujii 14 Feb '02

14 Feb '02

David Elliott <dfe(a)tgwbd.org> wrote: > Thus what we really need is some entity that will always have an unlimited > license to the complete wine codebase to do with it as it decides. I > question assigning copyrights away from myself and to anyone else, is > there some reason why signing an unlimited use license wouldn't be > acceptable (and thus developers would still retain their own copyright) or > is that effectively how it works anyway? This scheme would make the license awkward, because you have to add in "oh, by the way, all the contributions you make will be given to winecorp with an unrestricted license" clause. It is far cleaner and simpler to require contributions to assign the copyright. OpenOffice does this. > Wine cannot stay X11 free-for-all forever. Reminds me of one of Roger > Ebert's columns about the movie "It's a Wonderfull Life". Because the > movie is now public domain, anyone can use the original print for whatever > purpose. This includes colorizing it and then selling the colorized > version for a lot of cash (thanks Ted... yeah right). The colorized > version is a bastardization of the movie and is one of those cases where > you almost wish that copyrights didn't expire. Especially considering that > the director and the much of the cast were still alive to see this > horrible, horrible thing. Wine is very much in the same position here. > While we are not quite public domain we are so close that any distinction > is a moot point. *GPL wouldn't prevent the above either. Any "open source" license would let the above happen. As I said before, "freedom means others can do what you don't like" -r

2 3

Re: shellexecute patch
by Andreas Mohr 14 Feb '02

14 Feb '02

On Thu, Feb 14, 2002 at 11:57:55AM +0100, Rein Klazes wrote: > > Needed for Visual Studio.NET installer. > > Changelog: > > dlls/shell32 : shell.c > In ShellExecute16, make sure there is a space between command > and parameters. Hmm, I suspect that might be wrong. (in case your ShellExecute16() is being called by ShellExecute(), that is) ShellExecute() was supposed to call WinExec() instead of WinExec16() (long filename support). I wrote a ShellExecute patch some weeks ago that didn't get applied, probably because there were compile warnings. But I might be wrong and your patch is completely independent of mine. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 2

Re: Wine license change
by Roger Fujii 14 Feb '02

14 Feb '02

Ian Schmidt <ischmidt(a)cfl.rr.com> wrote: > On Wednesday 13 February 2002 01:28 pm, Brett Glass wrote: > > > business. So, if the company was profitable at all, it was just squeaking > > through. (And $20M in annual revenues after ten years of existence is no > > one's idea of "good money" for a company that size.) > Sure, but they did stay in business for 10 years and were in no reported > danger of going out of it. Not bad by any metric for a license you can't > make money off of ;-) but I wouldn't use the word 'thrive' to describe a company that is barely profitable (which is what the original poster used). It's not my opinion (and probably not even Brent's) that it is *impossible* to eek out a living. I think the point is that it is DIFFICULT to do so. I don't mind hearing GPL advocates say that it is more socially desirable, equitable... (not that I necessarily agree with it, but it is a valid point of view). But I don't see any evidence that it is helpful to commerical entities (which is some of the reasoning behind a license switch). > Anyway to steer back toward my point, can you name any pure-BSD/X11 players > that are profitable? well, depends on what you mean by "pure". X.org presumably is. Usually, the business model for this is a common group that publishes a reference port for other vendors, which can build propriatary value adds on top of the reference port. Ximian's 'mono' model is based on this logic (I think). A better way of looking at it is companies that have 'free' licenses that are NOT *GPL. sendmail.org has a modified license and they seem to be doing ok. Apache would a another one. > See, I think there's a more basic problem, which is that no known business > model works really well for source-available software when the software is > targeted at technically savvy users. Things like the Aladdin license are a > nice compromise, but ultimately won't lead to Microsoft levels of > profitability. No one here is advocating for M$ levels of profitability (at least, not for wine :) ), but the point is correct. The problem is the *GPL highly limits what models can be tried. > The solution as I see it is for GPL/BSD/whatever programmers to actually > cough up something non-technical users not only would use, but would > *prefer*. *Then* support and selling binaries becomes a worthwhile > proposition. you cannot sell *gpl binaries. You can sell the media, but not the content. Think sun has a good idea with dual licensing and having assignment of the copyright. This allows them to change the license so that they can make a productized version. > Codeweavers is leaning in this direction with CrossOver - even > though you could probably duplicate their work eventually with the current > Wine CVS, the installer and overall ease of use make it well worth paying for > if you value your time at all (I bought it and I love it, if you can't tell). Isn't the whole reason this discussion was opened up again was because they want to release LGPLed code (the inference was that they thought that their code released under X11/BSD would harm them materially). The obvious extrapolation is that a more complete wine under X11/BSD is not in codeweaver's interest, regardless of where the code came from. > To put this back on topic, I don't see any immediate benefits from a LGPL > license. If we knew what the threat to Wine Jeremy hinted at was, it might > make for a more informed discussion. I also liked Gav's idea about WineCorp > a lot as a compromise, and I'd love to see more dicussion of that and less > licensing flaming. MORE?! AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!! :) -r

5 6

[patch] - add several structs to ntddk.h
by Ron Gage 14 Feb '02

14 Feb '02

Hi folks... I just sent the following patch to wine-patches. I thought it would be a good idea to let you folks beat it up before someone actually commit's it to CVS... The patch adds several struct definations to include/ntddk.h to assist getting the NtQuerySystemInformation routine working. It also adds several enumerations for the System Information Class. By far, these are not complete, and I can only hope that they are accurate. One thing you may notice is that HANDLEINFO and THREADINFO have been defined. I believe there is already a less complete defination of the THREADINFO struct (called THREAD_INFO) in the code already. This has been left untouched so that this patch minimizes the potential side effects. These are untested in that I have not tried to recompile with these changes in place. My only concern: do FILETIME and LARGE_INTEGER data types exist? Google is your friend - use it wisely! -- Ron Gage - Owner, Linux Network Services - Saginaw, Michigan - 989-274-8088 Your one-stop source for Reliable, Secure and Affordable Networking Solutions --- ntddk.h~ Wed Dec 19 14:16:29 2001 +++ ntddk.h Thu Feb 14 07:32:31 2002 @@ -147,6 +147,21 @@ MaxThreadInfoClass } THREADINFOCLASS; +typedef struct { +/* This is used by NtQuerySystemInformation */ + FILETIME ftCreationTime; + DWORD dwUnknown1; + DWORD dwStartAddress; + DWORD dwOwningPID; + DWORD dwThreadID; + DWORD dwCurrentPriority; + DWORD dwBasePriority; + DWORD dwContextSwitches; + DWORD dwThreadState; + DWORD dwWaitReason; + DWORD dwUnknown2[5]; +} THREADINFO, *PTHREADINFO; + /* file information */ typedef enum _FILE_INFORMATION_CLASS { @@ -220,12 +235,124 @@ /* system information */ typedef enum SYSTEM_INFORMATION_CLASS -{ Unknown1 = 1, - Unknown2, - Unknown3, +{ SystemBasicInformation = 0, + Unknown1, + SystemPerformanceInformation, + SystemTimeInformation, Unknown4, - SystemPerformanceInformation + SystemProcessInformation, + Unknown6, + Unknown7, + Unknown8, + Unknown9, + Unknown10, + SystemDriverInformation, + Unknown12, + Unknown13, + Unknown14, + Unknown15, + SystemHandleList, + Unknown17, + Unknown18, + Unknown19, + Unknown20, + SystemCacheInformation + } SYSTEM_INFORMATION_CLASS, *PSYSTEM_INFORMATION_CLASS; + +typedef struct { +/* System Information Class 0x00 */ + DWORD dwUnknown1; + ULONG uKeMaximumIncrement; + ULONG uPageSize; + ULONG uMmNumberOfPhysicalPages; + ULONG uMmLowestPhysicalPage; + ULONG uMmHighestPhysicalPage; + ULONG uAllocationGranularity; + PVOID pLowestUserAddress; + PVOID pMmHighestUserAddress; + ULONG uKeActiveProcessors; + BYTE bKeNumberProcessors; + BYTE bUnknown2; + WORD wUnknown3; +} SYSTEM_BASIC_INFORMATION; + +typedef struct { +/* System Information Class 0x02 */ + LARGE_INTEGER liIdleTime; + DWORD dwSpare[76]; +} SYSTEM_PERFORMANCE_INFORMATION; + +typedef struct { +/* System Information Class 0x03 */ + LARGE_INTEGER liKeBootTime; + LARGE_INTEGER liKeSystemTime; + LARGE_INTEGER liExpTimeZoneBias; + ULONG uCurrentTimeZoneId; + DWORD dwReserved; +} SYSTEM_TIME_INFORMATION; + +typedef struct { +/* System Information Class 0x05 */ + DWORD dwOffset; + DWORD dwThreadCount; + DWORD dwUnknown1[6]; + FILETIME ftCreationTime; + DWORD dwUnknown2[5]; + WCHAR* pszProcessName; + DWORD dwBasePriority; + DWORD dwProcessID; + DWORD dwParentProcessID; + DWORD dwHandleCount; + DWORD dwUnknown3; + DWORD dwUnknown4; + DWORD dwVirtualBytesPeak; + DWORD dwVirtualBytes; + DWORD dwPageFaults; + DWORD dwWorkingSetPeak; + DWORD dwWorkingSet; + DWORD dwUnknown5; + DWORD dwPagedPool; + DWORD dwUnknown6; + DWORD dwNonPagedPool; + DWORD dwPageFileBytesPeak; + DWORD dwPrivateBytes; + DWORD dwPageFileBytes; + DWORD dwUnknown7[4]; + THREADINFO ti[0]; +} SYSTEM_PROCESS_INFORMATION; + +typedef struct { +/* System Information Class 0x0b */ + PVOID pvAddress; + DWORD dwUnknown1; + DWORD dwUnknown2; + DWORD dwEntryIndex + DWORD dwUnknown3; + char szName[MAX_PATH + 1]; +} SYSTEM_DRIVER_INFORMATION; + +typedef struct { +/* System Information Class 0x10 */ + USHORT dwPID; + USHORT dwCreatorBackTraceIndex; + BYTE bObjectType; + BYTE bHandleAttributes; + USHORT usHandleOffset; + DWORD dwKeObject; + ULONG ulGrantedAccess; +} HANDLEINFO, *PHANDLEINFO; + + +typedef struct { +/* System Information Class 0x15 */ + ULONG CurrentSize; + ULONG PeakSize; + ULONG PageFaultCount; + ULONG MinimumWorkingSet; + ULONG MaximumWorkingSet; + ULONG unused[4]; +} SYSTEM_CACHE_INFORMATION; /* reading coffee grounds... */ typedef struct _THREAD_INFO ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Request for wine-license list
by Uwe Bonnes 14 Feb '02

14 Feb '02

Hallo, I repeat may proposal, as the license wars will probably rage on: Let us create a wine-license mailing list and discuss licenses there. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1