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."

15 of 409 comments (clear)

  1. Is that ironic by MajorDick · · Score: 4, Informative

    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

  2. GCC list discussion by Bananenrepublik · · Score: 5, Informative

    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.

  3. What patent? by Anonymous Coward · · Score: 5, Informative

    This is the patent in question.

    1. Re:What patent? by hmckee · · Score: 3, Informative
      I lifted the following text from http://www.mega-tokyo.com/osfaq2/index.php/Doing%2 0a%20kernel%20in%20C++
      Note that, on x86, VC++ and most other PC compilers use a stack-based unwinding and handling mechanism known as SEH, common to OS/2, Windows and Windows NT and described in detail in a famous MSJ article, http://www.microsoft.com/msj/0197/Exception/Except ion.aspx. GCC and most other UNIX compilers, instead, use the same table-based mechanism that is the rule on RISC architectures on x86 too. Also note that any use of stack-based SEH may or may not be covered by USPTO patent #5,628,016, held by Borland International, Inc. SEH on RISC architectures is table-based, thus unaffected by the patent)
      Further searching for info on table based implementation reveals http://blogs.msdn.com/oldnewthing/archive/2004/01/ 14/58579.aspx that this would break compatibility with Windows. In other words, if you want to use SEH, you're screwed without Borland's help.
  4. Re:Ugly workaround? by Anonymous Coward · · Score: 2, Informative

    According to the article, either avoid structured exception handling altogether or use Microsoft's compiler to build the projects.

  5. Re:no, it's legally interesting by Anonymous Coward · · Score: 2, Informative

    Except that the "not implemented in gcc" implies this feature is not yet in winelib and won't be soon. So they wouldn't have distributed a version of winelib that contains an implementation of the patented algorithm(s).

  6. Why now? by sugarmotor · · Score: 2, Informative

    The patent is at

    http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PT 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

    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
  7. Re:C++ Standard? by Anonymous Coward · · Score: 3, Informative

    The Structured Exception Handling in question is purely for C, and is unrelated to exceptions in C++ or Java or any other language's implementation of them. It's hardly even the only C-based implementation around, so there's no shortage of source-compatible solutions. It is the one Windows uses, however, so binary compatibility would seem to demand it. However, I don't know if SEH even works across a DLL boundary -- usually its usage is even confined to a single compilation unit.

  8. VMS was doing this in the 80's by valderost · · Score: 4, Informative

    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

  9. Except even MPlayer isn't safe by rklrkl · · Score: 3, Informative
    "US coders can and do contribute to it [MPlayer], but it's based in Hungary, where it's safe."

    Funny, but its current home page doesn't exactly give me warm and fuzzy "safe" feelings. Methinks you chose a bad example there :-)

  10. FUD? by MarkusQ · · Score: 4, Informative

    until 4.0, gcc's backend was entirely and deliberately undocumented
    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

  11. Re:Wait a minute... by Dan+Berlin · · Score: 3, Informative

    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.

  12. Non sequitur by alexo · · Score: 3, Informative


    > 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.

  13. Re:There's an uber-workaround by perrin · · Score: 4, Informative

    > Europe (as of now) has no software patents.

    Wrong. The European Patent Office (EPO) has issued thousands of software patents. There are just doubts as to their enforcability, and several member countries do not accept them at all. This is what the new EU directive (CIID) is all about.

  14. Re:no, it's legally interesting by fm6 · · Score: 2, Informative
    That doesn't make any difference. The problem is not that you and I can't use SEH. The problem is that SEH isn't a feature of GCC, because like all GPL products, it can't include software obtained under a "non-free" patents. The GPL sez,
    We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
    So basically, Borland would have to give a free license for SEH to the GCC project, which would also apply to everybody who used GCC. If that doesn't happen, the only way GCC could offer SEH is to abandon the GPL. Not likely!