Slashdot Mirror
Winelib Hobbled by Exception-Handling Patent
davidwr writes "UKBuilder.com reports that Borland's structured exception handling (SEH) patent affects Winelib. Winelib allows you to compile Windows-targeted code to run natively on Linux. Because of the patent, gcc does not include support for SEH, which is widely used in the MS-Windows world. There are workarounds, but you won't like them."
I'm sure that Wine was looking for a Microsoft-based patent attack, but this one probably caught many off guard.
Who else may have submarine patents might affect the development of Wine?
"Rocky Rococo, at your cervix!"
This is where Borland needs to step in by giving the patent (or providing a legal exception) to the OSS community.
Guess I've been doing too much Unix...
There are workarounds, but you won't like them.
Use Windows? (ducks)
E.
Never rub another man's rhubarb - The Joker
Since Borland USED Winelib in Kylix.....
Amazing how thing like this rear their head AFTER a company that holds the Patent actually used the app in their OWN product, can you say STINGY
Again, I hate software patents. There's no point.
Most of what you'd want to protect is covered by copyright. If it can't be covered by copyright, well, then it's something so basic (like "the dog is big") that it's almost impossible to express something without doing it that way.
Again, this is where the idea of a software patent is stupid. Don't allow people to do things in ways that you really couldn't cover with copyright?
Ok, now I find myself back to the argument that source code is speech, and hence not patentable.
Linux - because it doesn't leave that Steve Ballmer aftertaste.
Of course this was discussed on the gcc list, the thread starts here.
Links to an implementation of this can be found in this mail, the legality of this implementation is discussed in the followup.
The inevitable prior-art discussion begins here.
More likely is that Intel would arrange (ie. throw some money, tech, patent licenses, whatever) at Borland in return for such a thing. Borland doesn't have any motivation to make stack-based SEH available to free x86-targeting compilers [the patent's irrelevant on RISC], but Intel arguably does.
Winelib is covered by the LGPL. If Borland has shipped Winelib in Kylix, they may already have given people a license to use the code. Perhaps they can wiggle out of that, but they can't continue to ship Winelib if they claim a patent on something in it.
I am not a developer, but how difficult is it to create a space in Wine for a SEC patent legal module to "plug in" to Wine? Winers could either use Wine without SEC or purchase a licenced module. Of course, some good hearted soul would release the source code, and then those who wanted to run the module illegally could do so as well. (Did I say that out loud?)
Even worse, this makes it clear that using patent-encumbered software has a genuinely unpleasant viral effect on all your software.
The pro-patent folks will eventually realize that the best solution is to avoid ALL patent-encumbered software COMPLETELY -- and look even more skeptically at all proprietary software, too. This will have the opposite effect of what they had intended.
There is not nearly enough love in the world, but there is far too much trust.
gcc also doesn't support register allocation with interference graphs just because of a patent.
There are workarounds, but you won't like them.
Thanks Marvin!
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
This is the patent in question.
IIRC there is a version of DeCSS that works similarly:
/* */ style comment at the end of the file.
,that can then be compiled.
1. Take function.c, where function.c is the patented software.
2. Add a
3. gzip the file
4. Write a program that evalautes the entire contents of the file as a single number, and check if that number is prime.
5. If it's not, increment the crap inside the comment, repeat steps 3 and 4 and check again for prime. Eventually, you will find a prime.
Now, you have a prime number, that if you run gzip on it, will product a file, function.c
Since you can't copyright a number this works for DeCSS vs the DMCA.
Patent law and copyright law are different so this may not apply, but still, wouldn't Fedora be allowed to distribute a prime number in their distribution? How could that be illegal? Then, it's up to the end user to actually unzip it and use it. It's the end user then that is violating the patent. Catch that!
There are workarounds, but you won't like them.
Wow, sounds like he's depressed, like he has a pain in all the diodes down his left side or something.
-- If god wanted me to have a sig, he'd have given me a sense of humor.
I am sure that Borland might appreciate the opportunity to strike back at Microsoft in a substantial way.
LedgerSMB: Open source Accounting/ERP
Next, a wave of Slashdotters will hassle Borland to release the patent, or exempt Wine. The objective is worthy, the self-organized social wave of independent activists is meaningful. But the style will most likely be counterproductive.
I recently advised a graphic designer/artist friend whose Flash app (advertising a minor celebrity pool player) drew the ire of an OSS "advocate". They demanded that the Flash movie be replaced with something that didn't require any "closed source" software to use it. My friend and I replied politely with their cost:benefit analysis (>95% of desktops can use Flash), the fact that Flash is an open standard (SWF), and the reality of making choices that can't please everyone, so the best alternative is chosen. The "advocate" devolved into namecalling and refusal to accept any of the designer/artist's reasons as valid. Which not only lost that private argument on facts, but alienated any possiblity of the designer/artist exploring OSS possibilities, as long as reliable old Flash still works.
If you're going to request that Borland release its constraints on Winelib, remember that you catch more flies with sugar than with vinegar. And that invitations to a company to join the OSS "community" makes you an ambassador from your community. Which demands high performance in charm and persuasion, rather than represent the community as a barbarian horde.
--
make install -not war
Remember, patents don't mean you can't code it. You can code it. You can use it for personal non-commercial use. You can distribute the code. But you can't use it commercially, distribute binaries, or sell it.
So the coders can continue doing their merry work, producing code that would violate patents were it compiled and distributed, and the distributors can continue merrily distributing the code in Europe.
The only people who are left out of this are Americans who would have to buy licenses from Borland to use the code in the US. That's fine; Americans should either pay according to their laws or change their laws.
But we shouldn't let American laws affect the rest of the world where they don't apply.
We need to start doing this for all open source software. There is no way to avoid trampling on patents if you're writing any fairly large or complex piece of software these days, especially any software that involves codecs, pre-existing APIs, and pre-existing file formats. Well, just about any useful piece of large software involves such things. Rather than getting into a hissy-fit on Slashdot every time some patent issue is discovered, open source developers should just plan for the problem and plan to bypass it.
The patent situation is not like the copyright situation. Copyright laws are roughly similar everywhere in the world and they are enforcable everywhere in the world. There are wide divergences in patent law around the world and most of the world is not burdened by America's folly in this regard. Why should developers bear the burden of one country's legal folly? Answer: developers shouldn't, and should simply pick the right jurisdiction for hosting the project.
This isn't some radical idea here. MPlayer, for example, could not possibly exist as a US-based project. US coders can and do contribute to it, but it's based in Hungary, where it's safe.
Since this is a patented technology used in other compilers, I assume Borland licenses it but it can't be part of the C++ standard. This just seems to me like another great example of problems introduced when programmers rely on things that are not part of the standard. Whether it is Microsoft's custom portions of Java (which meant Java apps suddenly were no longer compatible with Sun's JVM) or vendor extensions to error handling, if you use a tool that does not meet defined standards, then you develop software that is much less useful (it may implement something cool but it has a more limited audience and an almost guaranteed shortened lifespan).
The patent is at
T O1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm &r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628,016&RS =PN/5,628,016
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=P
The Patent Number is 5,628,016
There are two dates:
May 6, 1997
and
Filed: June 15, 1994
I assume the 1997 date is the "granted" date. Why is this problem surfacing now, almost ten years later??
Stephan
http://stephan.sugarmotor.org
Because Even Emulators Rock
From Microsoft,
.H and .INC files to piece together what constitutes Win32 SEH, one of the best sources of information turned out to be the IBM OS/2 header files (particularly BSEXCPT.H). This shouldn't be too surprising if you've been in this business for a while. The SEH mechanisms described here were defined back when Microsoft was still working on OS/2. For this reason, you'll find SEH under Win32 and OS/2 to be remarkably similar.
In digging through obscure
Article here:
A Crash Course on the Depths of Win32(TM) Structured Exception Handling;
Enjoy,
It's just the normal noises in here.
So all that's broken here, is the ability to complile code, that was written for Windows, into *nix binaries. That's all.
Is there really that much Windows code, getting ported to *nix? Seems like virtually all FOSS development flows the other way.
Large commercial companies that develop for Windows first, will have the resources to fix the code to compile the other direction.
And is WINE/WINELIB really a good solution? By taking something written for a particular platform, and just recompiling it straight over to a new platform aren't you going to end up with horribly unoptimized code no matter what? Rewriting the code to use non Windows specific calls will buy you a LOT of speed, and whatnot, I would think.
"Politicians are interested in people. Not that this is always a virtue. Fleas are interested in dogs." P.J. O'Rourke
I know most of us here assembled are sick of all this software licensing crap. Slashdotter jokes notwithstanding, we are some of the most intelligent people on the planet. What say we combine that intellect and come up with a way to combat all this software patent madness?
First suggestion: Elect a steering committee to form an organization/lobbying group.
What do you think?
Ignorance is curable, stupid is forever.
AFAIK, SEH is a method for doing structured exception handling in any language.
C++, Java, whatever... they all have exceptions. How does the compiler actually HANDLE the exception? SEH is a patent for how to put that exception information on the stack in an x86 environment.
It's pretty specific and pretty proprietary; If you ask me this is an example of a good software patent for once. I'm sure SEH took a lot of work for the folks at Borland (and Microsoft?) to get working right. This isn't like Amazon's Oneclick patent; SEH is difficult and non-obvious.
I am disrespectful to dirt! Can you see that I am serious?!
Man, I wish I knew what that meant. It sounds pretty frickin' sweet.
--grendel drago
Laws do not persuade just because they threaten. --Seneca
Hopefully somebody investigates OpenVMS as potential prior art here. The OpenVMS Condition Handling Facility provides substantially the same exception-handling functionality as SEH and has had much of it since the 80's. http://h71000.www7.hp.com/doc/72final/5841/5841pro _038.html#chf_vaxalpha
Funny, but its current home page doesn't exactly give me warm and fuzzy "safe" feelings. Methinks you chose a bad example there :-)
Now, discussions whether that should apply to physical inventions only or software is a topic I'm not getting into here.
I'm not going to touch how long those patents or copyrights should be - that war rages in enough other threads.
The financial gain for the inventor/creator is part of the motivation for inventing/creating. As much as I dislike MS, they are entitled to the rights afforded by their patents. Like it or not software is patentable around here, so we are stuck with the consequences.
-2, unpopular concept
Why, oh why, didn't I take the Blue Pill?
How about someone from GCC and/or Wine contact Borland and ask how much a license would cost to include SEH in these products? Or, ask them how much they'd be willing to part with the patent for?
If it's feasible, organize a fundraising effort from the OSS community, buy the license/patent from Borland, and immediately release the code under the appropriate xGPL. Many OSS contributors are corporations with a fair bit of money, so I see this as being at least worth discussing.
If nothing else, this is a straightforward way to 'play fair', rather than all the wrangling about submarine patents and how the patent system is so obviously broken. I personally agree with these sentiments, but we've never going to get anywhere yelling about a currently unsolvable problem. Rather than bash Borland in this instance, why not give them a chance to demonstrate how reasonable they could be?
eskwayrd = m^2c^4
Since this problem only affects porting existing windows code to Linux, it could be solved by
using the MS tools and linking the app with winlib.
Before you flame this, consider who would be doing this....someone who has a closed source application already working on Windows and wants to sell his application to the Linux market. IIRC, winlib is licensed under the LGPL, so this approach would be legal. (and this is EXACTLY how Coral ported Wordperfect 2000 from windows to Linux).
My first thought was, gee, that's not been my experience--as I recall, although it was complicated, it was rather well documented. So I did a bit of Google and found that other people seemed to agree with me (i.e., they say things like "Furthermore, compared to the other compiler projects, GCC offered the most comprehensive documentation for backend porters." and so forth).
The only thing I could find that even sort of suport your claim was RMS's thing about not wanting the backend to drift into becoming an LGPL black-box (thus chilling the development of new GPL'd front ends).
So, do you care to back your claim up?
--MarkusQ
Both groups make the same points for the same reason: the terms on patents and copyrights are ridiculously long---far too long to avoid interfering with the continued evolution of technology. Patents in the field of computing should be at MOST three years, not twenty.
Twenty years makes sense for some physical inventions because it may take several years to go from a working design to mass manufacturing. For software, five years later, a product is not only old news, more than 90% of the time, it has been completely superceded by other products on the market and is no longer even being manufactured. Having the same patent term for computer software as for physical inventions is patently ridiculous (no pun intended).
Check out my sci-fi/humor trilogy at PatriotsBooks.
This is completely untrue and misinformed. The original patent on graph coloring has expired (or will expire soon), and IBM granted the right to use it in any GPL'd software anyway. Rice University also granted the use of the patent on Preston Brigg's improvements to GPL'd software. So GCC could, and in fact has, implemented graph coloring register allocation (see the new-regalloc branch), over 2 years ago.
That should be in the past tense. Kylix is toast. Has been for a year or two. Borland screwed the pooch royally with it.
Reason #372 to never trust anything important to a proprietary platform.
I used to work for a large bank, the largest investment bank in the world in fact. A couple of years ago they sent an internal memo around proclaiming that they had just lodged their first patent and were well proud of it. They said something like "we have another several hundred in the pipeline". I wrote an semi-anonymous email back to the global head of the division of IT where I work, basically saying that that he'd better be ready to reap the whirlwind once all the banks started realising that they could patent ridiculously simple concepts (like using a PDA with realtime updates to enhance the productivity of specialists on the floor of the exchange, which was we had apparently 'invented').
I never heard another thing about software patents and a few months go I left.
> This is a story about a shortcoming of gcc and Winelib because so many
> Windows C++ developers use SEH instead of sticking to standard C++.
There are a lot of things that standard C++ does not cover:
UI, Device I/O, Threading, Synchronization, Async I/O, Interprocess Communications, Virtual Memory management, Registry access, Networking, etc.
For that, you must use the underlying OS features (either directly or via a library that abstracts it).
SEH is one such element. It allows you to catch "system" exceptions such as access violations. It is an OS feature that standard C++ does not address.
Quoting form the MSDN:
[The] difference is that the structured exception handling model is referred to as "asynchronous" in that exceptions occur secondary to the normal flow of control. The C++ exception handling mechanism is fully "synchronous," which means that exceptions occur only when they are thrown.
Let's just start our own country and be done with all these stupid laws.
what sig?
...here's an idea that maybe nobody has tried yet.
Ask them.
Rather than do the collective F/OSS thing and lose our minds about a software patent that's in the way...how about asking Borland if we may write something their patent covers?
Has it at least been tried yet?
Yes, software patents are evil. And yes, exception handling has tons of prior art. And still yes, this is freaking obvious. But still. It's only a problem if they complain, and they're less likely to do so if we just simply do the good manners thing and ask first.
Weaselmancer
rediculous.
It's neither the SEH syntax nor how the compiler works with the SEH syntax that's patented. In fact, the patent has nothing whatsoever to do with syntax.
The C++ language specification describes something that it calls "exceptions." It describes what is supposed to happen when you say throw X, and it says what happens when you say catch (Y). What the specification does not say is how a compiler implementer is supposed to make a program do what the specification says the program should do. The specification doesn't say, for instance, that i = 2 must be translated into the (Intel) machine code mov eax, 2, and it doesn't say what machine code the compiler should generate for throw X. Those choices are left to the compiler implementers, such as Microsoft, Borland, and the authors of GCC.
The patent describes how Borland managed to implement part of the C++ language by using Windows Structured Exception Handling.
(I think I should point out that there may be other kinds of exception-handling that are also structured, but the term "SEH" in this context refers to the particular way that exceptions work in Windows (and OS/2). An earlier comment refered to Matt Pietrek's 1997 Microsoft Systems Journal article, A Crash Course on the Depths of Win32(TM) Structured Exception Handling. Readers of that article will notice that there's really very little in it about C++. Instead, it describes how Microsoft's __try, __finally, and __except work, not the C++ try and catch. That's because Windows SEH and C++ exceptions are completely separate concepts. You can have each without the other. It's just unfortunate that they both use the term "exception," so many people think it's all the same thing. The Microsoft extensions allow the programmer to hook into the OS's SEH facilities.)
The patent does not cover SEH itself. For anyone reading the patent, you need to realize that nearly half the text of the patent is dedicated solely to background information. It gives an overview of what exceptions are; it briefly describes another way of implementing C++ exceptions by using special return codes that compiler-generated code interprets after every function returns; it goes to great length describing how SEH works in OS/2 and Windows.
Eventually, the patent document gets to the meat of the patent, describing exactly how Borland devised a way to use the native OS exception facilities to implement C++'s notion of exceptions. It's certainly not the only way to implement the feature, but it seems like a pretty good way, so I can see why someone would want to patent it.
(We now enter the part of my post that I'm unsure about; I welcome clarifications anyone cares to give.)
Now, how does this all apply to GCC and Winelib? I'm not really sure; I've never used Wine or Winelib. Winelib is for taking source code written to target Windows and instead compiling it for Linux without having to change all the code, right? The way I see it, unless that source code was taking advantage of SEH directly, there should be nothing to change. Direct use of SEH is just foolish; it's very complicated, and you're liable to get it wrong. Instead, the code should be using language features like throw and catch, which GCC is free to implement however it wants, or the code should be using API functions like RaiseException, which Winelib is free implement however it wants (but which should probably be compatible with how GCC implements exceptions).
And Wine itself is to make already-compiled Windows programs run on Linux, right? So its job is different from Winelib's. Wine needs to not only implement API functions, but also mimic various OS behavior that the programs will be expecting. Specifically, it needs to mimic Windows SEH so that the programs can raise and handle exceptions properly. I figure
Rob
Great idea, but er... what would be our new country's native language? C? Perl?
*ducks*