wine-devel

wine-devel@winehq.org

84463 discussions

How do interrupts in wine work?
by Nog 19 Feb '02

19 Feb '02

Hi, I got this feeling that I'm absolutly wrong in this but here goes... The way that I see Interrupt handling in wine is that when a real-mode dos executable is loaded, the processor (or the os mabe?) is forced into v86 were the int xx intruction is not privilaged. In this mode an exception is issued when an int xx is encountered and is then handeld by the exception handler is dosvm.c. Which in turn checks if the we have a builtin handler for the interrupt and if so then we simply call its handler as defined in real_mode_handlers. But when the app switches to protected mode, the int xx instuction becomes privilaged and gets handeld by EmulateInstruction. In this function the 32-bit version is not implemented but the 16-bit version is (Is this correct (the one is 16-bit the other 32-bit)? If not then what does long_op symbolise?) Is it likley that this piece of code will ever get called? And if so then why does it assume that the insterrupt it is emulating is not builtin? What all of this probable garbage came from is: What will it take to emulate int xx from 32-bit code? nog.

2 6

Re: Jeremy makes a persuasive argument for LGPL (MS Kerberos stuff)
by Igor Furlan 19 Feb '02

19 Feb '02

On Tue, 19 February 2002, Sean Farley wrote: > > On Tue, 19 Feb 2002 12:17, Roland wrote: > > > At 09:07 PM 2/18/02 -0500, Anthony Taylor wrote: > > <snip> > > > >Take, for instance, Microsoft's attempted hijacking of the Kerberos > > >protocol. MS almost took an accepted standard, and almost perverted it > > > > Well, I think we are still better off as when M$ would have created their > > own protcol from scratch. They certainly have the money to do that. The way > > it is now, we just have to implement the extensions to be able to use > > M$-Kerberos. I don't see where the BSD license has brought any kind of > > disadvantage here. > > Actually, the open-sourced implementation changed their specification > and forced Microsoft into explaining what they changed, but my memory > about it is not the greatest. > > Sean > -------------- > scf(a)farley.org Yes.. they published their change... but they said in the same time that you are not allowed to implement it anywhere, because the changes are copyright-ed by them. It is basicaly the same as their "shared source" approach: you can see it but you are not allowed to use it. Igor

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 19 Feb '02

19 Feb '02

> First, and formost, we have now heard the oppinion of two big > (from Wine > POV) commercial players: Gav and Jeremy. Now, it was > painfully obvious to > me that Jeremy had the power of reason on his side, while Gav only a > strong emotional impulse. Since choosing the LGPL is a one way street, it is hard to not be emotional, when arguing against it. It is much easier for the LGPL propenents to be emotionally detached. If you lose now, ou can come back next month, next year or whenever and try again. The LGPL oppents can't for obvious reasons. > And there's reason for that -- the > LGPL make a > lot more sense for Wine. Still think that after reading my reply to Jeremy? > We've heard countless arguments why that's not that case. A > lot of them > where simply nonsense. The few that made some sense, were ALL > based on a > false premise: that Wine is a monolithic product. I have never believed that Wine is a monolithics product. > Now, this is a _fundamental_ point that is ignored over and over > again: Wine is a _collection_ of products, just like a Linux > distribution. Which means that the viral aspect of the LGPL _stops_ at > every DLL boundary. Very true and this significantly weakens any "protection" that the LGPL offers. > It is easy to see now that this does not > preclude most > commercial implementations. In fact, it encourages them givin > them a level > playing field. Just like Linux does. Perhaps, but at a terrible price. Read my reply to Jeremy. > People, for crying out loud, _think_ about it, and the conclusion will > jump right out at you. THIS IS WHAT WE WANT: > -- if a company invests a _little_ to improve a DLL, we > should have no > moral problem requireing them to contribute that back. Since > it's just a > little contribution, no business will be destroyed because of it. > -- if a company makes a huge improvement (like > Transgaming), they can > simply drop the original Wine code, and keep everything > propriatary. Now, > compared to the _huge_ improvement, the cost of > reimplementing the mostly > non-working Wine code should be trivial. > > Bottom line is: > -- are we raising the bar for comercial companies with a LGPL > licence? YES! > -- how _much_ are we raising it? BY A TRIVIALLY SMALL AMOUNT! > -- do we invalidate TG business model? NO! Somehow you seem to believe that all reasonable business models will strictly following DLL boundaries, but you have given. absolutely no proof of this, you just assume it. Face it the design of the Windows API are a terrible mess that doesn't follow DLL boundaries.

9 18

Re: Licensing Open Source in General
by Roland 19 Feb '02

19 Feb '02

At 10:03 AM 2/19/02 +0100, Bernhard Rosenkraenzer wrote: >It *IS* a fair point of view - if someone just adds a bit of value, why >should they be able to make loads of cash of the much bigger original work >without giving anything back? No one will make loads of cash by just adding a bit of value. Why? Simply because no one would pay them much for that. It would be simpler to add that bit of value yourself or hire a programmer to do that in a weekend. People would only pay for big improvements, like Lindows, they invested around 5 million AFAIK. >Selling a proprietary fork of an open source application is much more like >stealing a car, giving it a new paint, and then selling it. >The thief added value (the new paint), so by your argumentation, he >should be able to make money of it and what he's doing is perfectly ok. First of all, you cannot steal something that is already free. But lets apply the rest of your analogy: Suppose the car is under a BSD license, which means everyone can get one for free. Now, someone gets the car, gives it a new paint and sells that product. How much would you pay him? Of course, since you can get that very same car for free also, you would only pay him the amount equivalent for the paint + the work involved in painting. If he wanted to charge you 10.000 for the painted car, you would laugh on his face, get that car for free and paint it yourself over the weekend(or pay someone else to do that). But if he charged you 40 $, you would probably pay him, since he as a professional would do a better job and you wouldn't have to make your hands dirty. In effect that 40 would probably be cheaper than the money it would cost you to do the job yourself, if you also count the time investment necessary on your side. So I think this business model is perfectly ok! This is the great advantage of the BSD license. It enables business. With the BSD license applied to your analogy we soon would have lots of businesses created to enhance the car: Painting, Putting sound equipment to the car, increasing the engine power, etc...Customers interested in one enhancement or the other would be willing to pay for it. Eventually one enhancement would be so popular that a group of volunteers would integrate it into the original car. What would be the GPL equivalent in your analogy: you can have the car for free, but any enhancements you make have to be given back at 0 cost also. Now suppose a guy wants to make the paint job. He will have to make it for free! So no one would do that of course. The result of this would be that if you want to paint the car you will have to do it yourself. Or you have to wait till someone else wants to do it and give it back for free afterwards. The GPL discourages business... Of course there are still business models possible, though restricted, for example: you hire the guy for painting the car as you wish. But that means you pay him in advance. And if this has been done once...no one else has to pay for it again... > > The GPL prevents this from happening but where is the advantage in > > that? > >Forcing everyone to contribute, preventing this type of theft. As I said, you cannot steal what is already free. >They are, if they choose to go by sane licenses. >Releasing products as Open Source certainly hasn't hurt companies that >aren't scared of doing it. Hmm, that might be true in some cases, especially where the software requires some kind of specialized support, where you pay more for the support than the software itself. >The problem is that many companies refuse to even consider sane licenses, >not that they couldn't do it. I don't consider the xGPL to be that sane anymore. > > Personally I keep wondering if it would be that bad if we had a company > > producing a better version of WINE than the free one. Why should this be > > bad? > >- it would take users (and therefore potential developers) away from the > real version. If that was true no one would be making Mozilla, OpenOffice, even Linux. When Linux started the proprietary Unix was MUCH better. History showed, that the opensource Linux was capable of catching up with UNIX and even become better. >- why should someone who made just a couple of changes make lots of profit > from (mostly) someone else's work without giving anything back to that > someone else? It's certainly not fair. Read above again. If you want to make big money you will have to invest MUCH. It is fair to get a corresponding return for that. I dare to claim that Linux distributors have done a lot more for Linux >than Apple has done for the BSDs, partially because licenses forced them >to give back rather than just keeping things closed. I wonder how profitable the Linux distributions are...and will be in the long run... Roland

1 0

Jeremy makes a persuasive argument for LGPL
by dschwarz＠bellatlantic.net 19 Feb '02

19 Feb '02

Well, I'm fairly convinced after reading his argument that LGPL is the right way to go. I think it's better for the Wine project over the long term. For those companies who have built a business model on closed source enhancements to Wine, there is still a way to play the game: At some point Wine is going to improve to the point where the core code works well enough to do almost everything we need. There will always be room for improvement, but the action may shift to reimplementing Microsoft applications that have important APIs (Internet Explorer, Windows Media Player...). I'm sure that Microsoft will change its EULAs to prohibit use of applications such as MSIE on a Non-Microsoft OS. It has already started doing this for some programs. Companies could respond by selling open or closed source reimplementations of these applications, bundled with a LGPL Wine. There will always be plenty of ways to add value on top of the core Wine code. Meanwhile, LGPL ensures that core code improvements will flow back to benefit all, not just those individuals and companies that have an altruistic bent. Regards, Daniel Schwarz dschwarz(a)bellatlantic.net http://www.winecentric.com http://winecentric.com/wiki

9 11

RE: Licensing Open Source in General
by Patrik Stridvall 19 Feb '02

19 Feb '02

> On Mon, 18 Feb 2002, Roland wrote: > > > I think one of the main reason for the xGPL is that > developers have the > > fear that their project might be hijacked and their work > used to make > > profit by some companies. As Brett Glass pointed out, this > is not a fair > > point of view. After all if a companies adds value to a > project by creating > > new features why shouldn't it be allowed to sell it and > make money out of > > it? > > It *IS* a fair point of view - if someone just adds a bit of > value, why > should they be able to make loads of cash of the much bigger > original work > without giving anything back? If somebody just adds a _bit_ of value and are able to make loads of cash on it I or somebody else are very likely to be easily able to duplicate the effort. Try again. > Selling a proprietary fork of an open source application is > much more like > stealing a car, giving it a new paint, and then selling it. > The thief added value (the new paint), so by your argumentation, he > should be able to make money of it and what he's doing is > perfectly ok. First of all copyright and theft have very little to do with each other. Theft by it definition involves depriving somebody from his property. Secondly if the license is the current licence this is obviously legal. Thirdly if it just requires a little "paint" to it make money I or somebody else can duplicate that and make the money instead. > > The GPL prevents this from happening but where is the advantage in > > that? > > Forcing everyone to contribute, preventing this type of theft. What theft? There is no theft going on. With the LGPL copyright infringement might be going on but then as I have trying to explain in countless mails it is easy to circumvent it even with obviously "trickery" that is obviously legal. If you trust your lawyers there are even more "trickery" you can do. > > I think the GPL retricts software development because many good > > projects cannot be done by companies because they are not > allowed to use > > any GPL code as basis of their products. > > They are, if they choose to go by sane licenses. > Releasing products as Open Source certainly hasn't hurt > companies that > aren't scared of doing it. > > On the contrary: Stronghold used to be proprietary before Red > Hat bought > the company making it. Now it's open source and the moment > that happened, > the sales numbers actually went UP (and the price is still > roughly the > same). Stronghold was presumably a WORKING product. Wine is not. If you make comparisions compare situations that are similar. > The problem is that many companies refuse to even consider > sane licenses, > not that they couldn't do it. Well, if that is a problem a complex license like LGPL certainly isn't the answer. > > Personally I keep wondering if it would be that bad if we > had a company > > producing a better version of WINE than the free one. Why > should this be > > bad? > > - it would take users (and therefore potential developers) > away from the > real version. What potential developers? If the source is closed they can't work on it. If the source is available like Transgamings why should they work for them without pay. Why not do as Marcus did and look at the code and reimplement it in the main tree instead. :-) > - why should someone who made just a couple of changes make > lots of profit > from (mostly) someone else's work without giving anything > back to that > someone else? It's certainly not fair. Again, if somebody can make a couple of changes and make money I can duplicate it and make the money instead or for that matter post it on wine-patches.

1 0

Licensing Open Source in General
by Roland 19 Feb '02

19 Feb '02

Hello all, with the ongoing discussion about this topic has brought me to think about licensing open source(OS) in general. I think a broad discussion involving all major OS advocates is long overdue. I think there should be made a webpage somewhere to start discussing this topic on a serious basis. Two important licenses: 1. BSD-style 2. xGPL Many projects are started with the xGPL nowadays. It just seems natural. Any other license for open source looks unnatural at first glance. I think the popularity of Linux has contributed to this. But is the xGPL a good license? I think one of the main reason for the xGPL is that developers have the fear that their project might be hijacked and their work used to make profit by some companies. As Brett Glass pointed out, this is not a fair point of view. After all if a companies adds value to a project by creating new features why shouldn't it be allowed to sell it and make money out of it? The GPL prevents this from happening but where is the advantage in that? I think the GPL retricts software development because many good projects cannot be done by companies because they are not allowed to use any GPL code as basis of their products. The sad thing is that this affects mostly small companies. Big companies can allow themselves to reinvent the wheel, coding everything they need. I think a lot of small businesses could do money out of open source if the licensing allowed this. Linus Torvalds wrote: "But _personally_ I don't want to do significant work under that kind of copyright and having to wonder whether the best version of Wine will be free in the future.." http://groups.google.com/groups?q=Ingo+Molnar+group:comp.emulators.ms-windo… Personally I keep wondering if it would be that bad if we had a company producing a better version of WINE than the free one. Why should this be bad? If you don't like it, you still can use the free version. And look at FreeBSD. AFAIK there is no proprietary version better than the free version. Apple based his OS X on lots of free software and contributed back a lot: http://developer.apple.com/darwin/ This wouldn't be possible with Linux I think. Best regards, Roland

4 3

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 19 Feb '02

19 Feb '02

> At 02:19 AM 2/16/2002, Patrik Stridvall wrote: > > >> So now you've made your point, constantly, how about we just > >> take it for > >> granted that for every email sent to the list saying 'the > gpl is good > >> because...' you and Patrik will reply with 'No! It's evil, > >> RMS is satan, > >> viral licensing, noone will use it, blah blah blah'.... > > > >I have never said that. > >I do admit that Brett Glass have said that. > > No, I never have. You haven't? OK, perhaps not word by word, but I fully understand if people interpret your position that way. I'm sorry if I sound a little angry but it seems that some of people have found me guilty by association with you and that irritates me quite a bit. What you are doing IMHO is pure fear mongering, it will not help the case against LGPL. I firmly believe that the GPL and the LGPL has a place in the world. However that place is not in Wine project. The LGPL is IMHO for libraries that are pure libraries and have all functions implemented. Wine fullfills neither the pure criteria nor the have all functions implemented criteria. In such cases this allows bugfixes to go back, but new functions can be put in the application or in a new library not nessarily in the library itself that have to be under the LGPL. Then companies can choose for themselves whether they want the LGPL protection for their new functions or not.

4 6

RE: TransGaming LGPL clarifications
by Patrik Stridvall 18 Feb '02

18 Feb '02

> > My LGPL concerns are: > > > > 1) We support copy protected CDs in our WineX binary > releases. This support > > This is a valid issue, and I am sure that the Wine community > would more > than happy to provide hooks for you for exactly this purpose. > There's no > other option in this case, so I don't think it' even an issue. Hooks is not possible because it would violate the paragraph 2d of the LGPL. At least according to Alexandre's interpretation of it. Every LGPL:ed function must do what every application expects even if the application (read: execution enviroment) doesn't provide the hook function. Since the hook function in the Transgaming execution enviroment would cause copy protected games to work, according to Alexandre's interpretation copy protected games must also work in the normal Wine execution enviroment that doesn't have the hook function. Of course Alexandre's interpretation might be wrong. However in that case wrapper libraries if definitively allowed and thus the LGPL is all but meaningless for new functionallity. Just put a new functionallity in a proprietary library and add a wrapper that calls it. In that case almost everything most LGPL proponents claim is good with the LGPL is gone. > > 4) Most importantly, the LGPL is a one way road. > > But that's one of it's features, you know... :) It's what gives people > piece of mind, Peace of mind. Ha ha ha. Allow me to laugh. Please, you can weld stuck the rudder of ship and claim that now that the rudder is stuck since we needn't argue anymore and now we can have peace of mind from the endless debates on where we should go. This is not what I would call peace of mind. > and what I feel creates the level playing > field. Whether this is true or not is basicly what the whole debate is about so this is just a unsupported statement of opinion. > Just PD, > and BSD are manyway roads. That is, this is not a valid > point. If you want > to argue that, we're stuck with BSD, period. Of course it a valid point: We can always change to LGPL later it will NEVER be to late. However can you say the same about changing now? > > That said, I believe that my WineCorp suggestions address > both my concerns as well > > as the issues raised by the LGPL camp. > > I personally despise the idea, On practical, and > phylosophical grounds. > And if we go that route, I don't think I'll follow. For the record: I'm not particular fond of the idea either, but mostly for practical reasons. I'm prepared to talk about it though.

1 0

GetStdHandle problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

After having some problems, I could recompile and link my programs using Wine. When running, The call to GetStdHandle(STD_OUTPUT_HANDLE) fails. It return 0. In windows enviroment this functions returns a numeric handle I use later to print onto the console. What's happening ? Is this a bug ? Can I solve it changing code ? Thanks in advance. Ignasi Villagrasa.

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel