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.
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.
This is the patent in question.
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).
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.
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?
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).
Hey - why not do this with the MS Windows XP distribution ISO file?
:-)
Lets see. XP is probably about 650Mb, so that's 5.6x10^12 bits. Let's round down for GZIP and call it 10^12 bits.
So we just need a prime in the order of 2^(10^12). That can't be hard to do, can it? Just because the highest prime so far is in the order of 2^(10^7) just means that those mathematicians have been slacking it a bit! Lazy bums! And no doubt their software is lousy and totally inefficient. I'm sure Slashdotters could fix that.
But why bother with those pesky prime numbers anyway? Why not just gzip it, stick it on a CD and explain that it does not contain a gzip file of someone else's IP, but is in fact a particularly interesting finite number of about 300 million hexadecimal digits. That it just happens to evaluate, via the mathematical GZIP operator, into another large hexadecimal number resembling someone else's IP is pure coincidence! I'd go for that. Seems reasonable to me.
But why bother with GZIP? Just copy the original - we know it will fit on a CD - and the argument still holds! Brilliant! Ebay here I come!
Does anyone have a list of email addresses I could use to see if anyone is interested in buying a very special, large, very large, hexadecimal number with unusually useful evaluation properties?
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
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.
> 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.
...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.