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.
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?)
gcc also doesn't support register allocation with interference graphs just because of a patent.
I am sure that Borland might appreciate the opportunity to strike back at Microsoft in a substantial way.
LedgerSMB: Open source Accounting/ERP
Since the patent postdates Windows NT 3.1, and even references the NT SEH implementation, it must be possible to implement NT-compatible SEH without infringing the patent.
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.
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.
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?!
Or Microsoft licensed it?
It works for DeCSS because that algorithm's so ridiculously short. It would be hard to express a longer program as a number.
All's true that is mistrusted
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).
so how does this C++ SEH stuff differ from the elaborate
exception handling that PL/1 has had since the '60s, '70s ??
and wouldn't almost any PL/1 implementation have used
the the patented technique ??
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.
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