Slashdot Mirror


Corel Puts Internal WINE on CVS

I'm pretty pleased to see this one: Corel has put their internal CVS tree up for read only access so that they can more easily sync their code with the official branches. You can see more at the Corel Open Source Web site.

5 of 130 comments (clear)

  1. Re:About time! by Ian+Schmidt · · Score: 4

    Corel has been contributing to WINE for over a year now - this tree consists only of changes they've made since December 12, 1999 and/or patches Alexandre Julliard and the WINE team rejected.

    If you think no progress has been made because your favorite app doesn't run, please read documentation/bug_reporting and let us wine-developers know about it. We can't fix your stuff if you sit and stew about it!

  2. Changes to Wine: by Non-Newtonian+Fluid · · Score: 4
    The things Corel has worked on in Wine seem to include the following:

    • COM & OLE
    • Multi-threaded messaging
    • CommDlg and CommCtl
    • Header files and definitions
    • GDI & Printing

    The also seem to have created a new look-and-feel theme: KDE.

    See their description of changes here.

  3. Give COREL the credit they deserve! by ddstreet · · Score: 4

    I think the fact that Corel is willing to PAY its employees to write open source code is GREAT! The only reason they forked (temporarily, to get a specific product done by a deadline - see Their WINE page) is because they wanted a UI (they used KDE) and the real WINE team wanted an abstract UI layer (so WINE wouldn't be stuck with one UI, or have to maintain multiple UIs in the codebase). Of course any programmer (should) know that the real WINE team is right, and I'm sure the COREL team knows that too, but I am very sympathetic with them needing a UI by their deadline. Ok, fine; they develop one, but it shouldn't go into the core WINE, it's just to get the UI job done until the abstract layer is in place (then plug the KDE UI into that). I think COREL's decision to develop exclusively on their own fork is just due to deadlines. Remember, open source projects don't have corporate deadlines, but companies do! Be glad these people are team players, and let them meet their deadlines - then (hopefully) they'll work with the real WINE team to integrate the forks! Give COREL the credit it deserves, they are paying people to write open code. They're ok in my book.

  4. Aiiiieeee! Corel is NOT FORKING WINE! by Ian+Schmidt · · Score: 5

    Corel is NOT forking Wine!

    - Their tree is a whopping 6 weeks out of sync with WineHQ's. There was last a sync on December 12, 1999 (coinciding with the Wine 991212 release). All their work prior to that date that the Wine developers would accept is in WineHQ's tree already.

    - The reason they maintain a separate tree for the moment is that they are beta testing and finalling their apps and need a stable tree (WineHQ's is being updated near-daily, in sometimes architecturally major ways, and certainly doesn't fit that definition).

    - There are already patches pending at WineHQ that bring in the 2 interesting items in their tree that are not in WineHQ's (system tray bugfixes and partial WinInet/URLMon DLL implementations). Conversely, there are some features in WineHQ's tree since 991212 that aren't in Corel's, particularly for multimedia.

    - Please note that their list of what they've done for Wine on that page represents ALL their work, and is not the differences between their tree and WineHQ. 99.6% of their work is in the WineHQ tree right now.

    - There are a few items in their tree that won't ever be merged into WineHQ because Alexandre Julliard (Wine's "Linus") doesn't like them. This primarily includes the KDE look and feel patches.

    Please, if you don't understand what's going on, don't make things up. If you must flame someone, head over to ZDNet and check out "Coop"'s hatchet job on Linus, LiViD, and the DVD fiasco...

    -Ian Schmidt
    wine-devel, in the AUTHORS file, and damn proud of it.

  5. Re:Improvement? by DeathBunny · · Score: 5

    There are 2 parts to Wine: The Wine program loader the most of us have tried at one time or another, and winelib. Applications compiled with Winelib *ARE* native Linux apps, they just use Winelib as thier widget set instead of using something like GTK or QT. Programs compiled with Winelib should run as fast as any other Linux apps.

    Corel has stated that their main interest in Wine is in using Winelib to allow their apps to be compiled for either Win32 or Linux/Wine with just a re-compile.

    So yes, they are using Wine as a "backend" for thier Linux apps. But they are *native* Linux apps, and should have all of the speed and stability that Corel apps have (or don't have, as the case may be) on any other platform.