Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Corel

Corel Puts Internal WINE on CVS 130

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.
This discussion has been archived. No new comments can be posted.

Corel Puts Internal WINE on CVS

Comments Filter:
  • by Anonymous Coward
    Is it being actively maintained? The original coder, Thirot, has basically abdicated and i can't tell if the new hosting sites are making updates to it. It basically barfed on my 2000109 WINE install, but that's probably my fault. Anyone know?
  • by Anonymous Coward
    I like WINE with some malicious html tags, crackers and various hor d'oeuvres followed by some CERTs.
  • by Anonymous Coward
    Am I the only one who doesn't want my applications to look, feel, and work like in windows? I mean, the kernel isn't the only thing that sucks about microsoft's offerings; the ui blows too. Although I respect Corel and others for bothering with Linux, I think that using wine is a cop-out and ends up making Linux a second-class citizen in the application space. X just isn't that hard to code for. There are plenty of good toolkits out there to use. Wine isn't one of them, the best efforts of the authors notwithstanding. I very much wish they had spent their time working on more worthwhile projects ("worthwhile" in the eye of the beholder of course). Much like StarOffice, Wine is a reimplementation of a bad idea from Microsoft, and unfortunately both of them are even worse than the originals.

    Thus I will boycott any such half-assed "ports" and use only true native applications. Do it right or don't do it at all. (Of course, if Corel's WP8 for Linux is any indication of Corel's skills, I doubt I'd ever use it anyway.)

    Since it seems I'm nearing rant mode anyway, why is it that every fscking binary-only application vendor seems insistent on linking dynamically with a 3-year-old unsupported C library that no current distribution is based on? Even Slack finally ditched libc5. Everybody will be distributing glibc 3 and these fsckwits will still force us to have fscking "compatibility" libraries installed just to run their crap. How long until libc5 can't be compiled on a modern system? However long, it's too fscking long. That's it, time for a total boycott of closed-source apps. I am Richard Stallman and you claim your leather-bound GNU emacs bible.

    Much better.

  • System V printing is an absolute mess, with considerable differences between HP-UX, Solaris, and other UNIXen flavors. I can't tell you how much of a pain it is supporting heterogeneous UNIX printing, even in a straight Postscript environment.

    Agreed. That's why I use LPRng. It acts and works like BSD, except it's much more powerful and less archaic. It also replicates most of the SysV functionality if some sickos like to use that. I've not used CUPS, so I can't say much about it, only that I know of another solution that seems to work pretty well.

    If you think this isn't a serious issue which compromises the potential adoption of Freenix at the consumer level, then we have nothing to discuss.

    It is. But unlike almost everyone else here, I'm not of the opinion that every consumer on Earth should be using Free Unix...or computers at all.

    CUPS is a reasonable solution to this problem, and I'm pleased it's evolved to provide both a GPL foundation ALONG WITH support for proprietary printer drivers. I challenge you to detail how this is different from Linus allowing proprietary binary only loadable modules in Linux.

    No sucker bets here. It's essentially the same. It's just that I think Linus made a mistake. :)

    As a former NeXT Cube and NeXTStation owner I argue that they were the most elegant computers I've ever had the pleasure to own. The damn things still work well and still hold up as excellent (if somewhat slow) workstations.

    Yep. The NeXT cubes were exceedingly cool, and NeXTStep was pretty groundbreaking work. But MOSX doesn't look quite as good to me right now. Too much emphasis on the "MacOS" part, which, despite raves about its beauty and consistency, has repeatedly earned my "worst ui" award, even beating out windoze 3.1, which says a lot. JMHO, but after 7 years of using Unix, the more it emphasizes a gui the less likely I am to tolerate it. I'm sure MOSX will be better in this regard, and I'm equally sure Apple will try to hide it, which makes me ill.

    While they've kept much of the core Apple products closed and proprietary, the fact is that this option is left open to them intentionally by the BSD coders.

    I'm not trying to say that they violated the BSD license. Just that I don't much care for their particular products and licensing schemes, that's all.

  • Actually, printing in Unix works great if you have a reasonable printer. If you paid less than $200 for it, good odds it's going to suck. Of course, those printers are usually just crap under any os, but that's not at issue here. A printer that speaks languages like postscript, pcl, pjl, etc. is a good choice under any Unix. In spooler-land, I find that LPRng works wonderfully, in concert with ifhp if need be. It may not be intuitive for newbies, but it works just fine, and is exceedingly powerful.

    Boy, MacOS X looks pretty good from this vantagepoint, eh? :-)

    Not really. No source == not for me. If I'm going to use something for which I can't get the source, I'll use IRIX. At least IRIX doesn't try not to be Unix. Doesn't try too hard, anyway. Display PostScript? Sure! OpenGL? Fast as hell! A real X server? Of course! No thanks, Apple. Now we just wait for SGI to finish open-sourcing the remaining good parts of IRIX and go to town.

  • How is this different than what's been contributed by any other company? The company and the Wine develpers more than likely have different short term goals with varying degrees of overlap. I'm sure that Corel's main goal was getting something into shape that would allow them to get WordPerfect Office 2000 for Linux out the door. So instead of trying to keep their changes in lockstep with the other developers, they just forked it for a little while. Sure there is going to be some time wasted in trying to get both sets of code back in sync. Big deal, it's getting merged and because of the licensing, they didn't have to, but they are.

  • Actually, printing in Unix works great if you have a reasonable printer. If you paid less than $200 for it, good odds it's going to suck. Of course, those printers are usually just crap under any os, but that's not at issue here. A printer that speaks languages like postscript, pcl, pjl, etc. is a good choice under any Unix. In spooler-land, I find that LPRng works wonderfully, in concert with ifhp if need be. It may not be intuitive for newbies, but it works just fine, and is exceedingly powerful.
    I'm well versed in setting up printing under both System V and BSD... frankly I consider both archaic, though at least BSD is simple and consistent across platforms. System V printing is an absolute mess, with considerable differences between HP-UX, Solaris, and other UNIXen flavors. I can't tell you how much of a pain it is supporting heterogeneous UNIX printing, even in a straight Postscript environment.

    Regarding various consumer grade printer support: your position seems to suggest that we shouldn't bother supporting that "...crap." If you think this isn't a serious issue which compromises the potential adoption of Freenix at the consumer level, then we have nothing to discuss. I'd like to think that soon enough Linux and BSD distributions will near the level of end-user configuration friendliness that NT and MacOS share. If this isn't your goal then of course lpd and lpsched can be coaxed by a professional into providing reasonable service in a commercial setting, and that's probably enough. Otherwise, I'd argue that Christopher Browne is correct, that printing under UNIX is a complete mess, and that the Freenix community better pay attention to this issue otherwise it will bite us in the ass pretty hard. CUPS is a reasonable solution to this problem, and I'm pleased it's evolved to provide both a GPL foundation ALONG WITH support for proprietary printer drivers. I challenge you to detail how this is different from Linus allowing proprietary binary only loadable modules in Linux.
    Boy, MacOS X looks pretty good from this vantagepoint, eh? :-)
    Not really. No source == not for me. If I'm going to use something for which I can't get the source, I'll use IRIX. At least IRIX doesn't try not to be Unix. Doesn't try too hard, anyway. Display PostScript? Sure! OpenGL? Fast as hell! A real X server? Of course! No thanks, Apple. Now we just wait for SGI to finish open-sourcing the remaining good parts of IRIX and go to town.
    Don't expect the Display Postscript extensions in Sun's OpenWindows and SGI's X environment to continue for much longer. Adobe has made it clear that Display Postscript is depreciated and that they will not support this technology any longer... this is why Apple developed their own Display PDF technology. As a former NeXT Cube and NeXTStation owner I argue that they were the most elegant computers I've ever had the pleasure to own. The damn things still work well and still hold up as excellent (if somewhat slow) workstations. If Apple can provide that kind of environment again, with modern hardware, I'm there. But this is personal taste.

    That's not to say the IRIX is junk... if you prefer IRIX to MacOS X in the commercial world, well so be it. But to argue that you won't buy MacOS X for free software reasons doesn't give Apple the credit they deserve WRT keeping the OS internals open and free. They had no obligation to release their BSD code changes back to the *BSD projects, yet they have. While they've kept much of the core Apple products closed and proprietary, the fact is that this option is left open to them intentionally by the BSD coders. That's what they want, otherwise they would have chosen to release under the GPL. I respect their right to do so and consider that whatever Apple shared back to the community to be a gift we should thank them for, rather than cynically taking them to task for not releasing core Apple technology with which they expect to turn profits.
  • by cout ( 4249 )
    It is possible to go the other way, running the VNC server on the Unix machine and getting multiple users to connect, but X seems to be much better for that anyway.

    You can also run multiple VNC servers on the Unix machine, but they don't work the way you would expect.

    I do like the VMWare idea you suggest. Perhaps a small change to the server would allow that? The only problem I see is that the Win32 API isn't reproduced across VM's; it would be nice if VMWare supported a copy-on-write policy for its VM's, then you don't have the memory consumption problem you'd have otherwise.
  • I'm eager to see what Corel's new Office suite looks like. Does anyone have any screenshots?

    Jason.
  • Get a clue: what Corel is doing with wine is to use it as libwine, to ease the porting, so they don't have to reimplement everything.
  • Doubt no more. I can confirm this. I just got my Corel Office Linux beta 1 CD. It says in the docs that WINE is in fact used to run the system. I haven't had time to install it yet, but I'll get it up and running to kick out a few screen shots.

    You better make sure that the NDA (or BTA as corel calls it) allows you to do that. It was pretty restrictive about what you can talk publicly about their betas as I remember. I have to check it over again once I get my beta to see what I'm allowed to discuss.
  • Where can I download and intall the corel filemanager onto my Redhat 6.1 box ?? -doog
  • Citrix Winframe/Metaframe solutions are a heck of a lot faster than VNC. I get better performance connecting to a Metaframe box over DSL than I do connecting with VNC to a machine on my local ethernet.
  • just as soon as wine reaches v1.0 levels of reliability (meaning: production quality), M$ will go and change things so that their new o/s will have special innards that the new apps are counting on.

    That is true, and has certainly restricted previous attempts at window emulation. But there should be a "critical mass" situation, where if a large enough percentage of users are using a windows emulator, it will make it harder for Microsoft to change the API.

    I think this is what is so great about UNIX. To a first approximation, code that works under UNIX works under Linux, FreeBSD, etc. The presence of multiple implementations has kept the API stable and the presence of relatively strong third party developers has also helped to keep it stable. Windows doesn't have any major competing implementations or third party developers that can compare to Microsoft itself.

  • -managed (which IMO should be Wine's default) allows your window manager to fully control Wine's windows and should fix your problems.
  • Does that make Corel's version a fork?

    Strictly yes. Since the features that differ are quite minor (for the KDE look n' feel, basically WineHQ wants to do correct clean theme support and Corel just kinda hacked it in) it's not different enough to really get alarmed though.
  • patches Alexandre Julliard and the WINE team rejected.

    Does that make Corel's version a fork?

  • There is a <EM>big</EM> difference between the meaning of `release early, release often' as it comes from MS (et al), and what it means when you're talking about (typical?) CVS repositories.

    That fact is that the word, `release', means two <EM>very</EM> different things in these different scenarios.

    When we talk about MS, we talk about `production releases', which are supposed to be finished products for <EM>end-users</EM> (or some sort of `preview release', which is made to whet appetites).

    When we talk about CVS `releasing code to the public', we're talking about something completely different--it's more `exposing to the elements' or somesuch.

    The most `extreme good' case is when you make your full (non-teaser) code available to the public (exposing it to the elements), and then accept patches from them public. In that case, rather than being done to get more users, the `release' both empowers the users of the software, and makes the software universally better.
  • Listen, Corel doesn't have to give back ANYTHING to this project. Corel had internal deadlines they had to meet so keeping in sync with the main tree was impossible. Now that their tree is public, they are going to allow the main Wine developers to pick and choice what they want to put back into the main tree.
  • The current WP2000 beta is actually a WIN32 binaries tuned for Wine WIN32 binary mode. They are not native apps.
  • Or you can use AbiWord [abiword.com] which reads word files (but doesn't export them yet), or wordview (no url handy) which is the library we(abiword) use to import Word .doc.
  • Is it just access to the source code, or is it the fact that they're not Microsoft, that makes the "release early, release often" mantra a good thing?

    Seriously.

    Microsoft goes through a HUGE public beta and all that happens is that they get completely ragged on. Corel does the same and it's a *good* thing. Don't bash me as being a Microsoft employee or anything, i'm genuinely curious.
  • why do you doubt everyone's motives that helps linux, unless they're a pure linux company?

    Corel's been moped around quite a bit by Microsoft. Since Linux looks like it could actually be a viable alternative to Windows, it's not at all suprising that Corel helping it all it can to erase the definciense that Linux has on the desktop.
  • They already have with Win2000. But so long as developers are targetting 9x, those apps should run fine. Is there a single app in existance that refuses to run under Windows 95 yet runs fine on Windows 98? I mean, once IE4 has been installed. And the next consumer windows will still be based on the Win 9x codebase, so the current incarnation of WINE should have quite a bit of life left to it.
  • Let me guess: You don't follow the Wine development at all, but like to complain? If you would have read the wine mailing list, or looked into the Wine CVS tree every once in a while you would have noticed that Corel did work on the project and contributed to the code base.
  • I think they're motives are pretty straight forward, they want to port their software to linux with the least ammount of effort (read: money). This way is by taking wine and enhancing it to the point where their apps will compile for linux. Just be glad they are publishing their changes, wine IIRC is under the BSD license which allows for people to make closed source forks. I really can't see of any underhanded movites they might have.
  • How dog indicates, that one we?
    They must here have extinguidolo, it plow were ready for ** of the sincronismo of ** of the uses
    that every thing demands cold is in it
    which it has worked with it, equally has worked with to other an ace.
    The full product is randello of the officials of the forces fortified revolutionary to the product of imcomplete.
    It chases to an other elasticity, that with that one with time?
    To the aids of the company this, to happen.
    The LU not informed with an extremity, that age, this?

    Got to love babelfish :)
    ArsonSmith
  • With any luck, this version will have some noticable improvements... Bearing in mind of course that this version was undoubtedly used to help port Corel Office 2000 to Linux...

    Doubt no more. I can confirm this. I just got my Corel Office Linux beta 1 CD. It says in the docs that WINE is in fact used to run the system. I haven't had time to install it yet, but I'll get it up and running to kick out a few screen shots.

    ---
  • But there should be a "critical mass" situation, where if a large enough percentage of users are using a windows emulator, it will make it harder for Microsoft to change the API.

    ms gives a bull about users using windows emulators. BUT they have to look at the users which use _native_ but older windows versions after whose API's those compability layers where built.
    And there's without doubt a critical mass ;-).
  • >but it does bridge the gap for those in business who [unfortunately] have
    >to be able to read those stoopid .doc files from a unix host.

    Funny I have no problem at all reading those stoopid .doc files people send me in my native linux version of StarOffice.
  • how much better is this version than the one over at wine.org or whatnot?
  • Corel announced their involvement with the WINE project a very long time ago... Nothing appeared to come of it however. WINE made steady, incremental improvements but no major progress...

    With any luck, this version will have some noticable improvements... Bearing in mind of course that this version was undoubtedly used to help port Corel Office 2000 to Linux...
  • Run your windows .exe with -managed, eg.:

    wine -managed program.exe

    and your own window manager will be used in favour of the standard wine one.

  • What does open source have to do with forking? It seems that one of the points of open source is that IF the standard product doesn't do the job, here is the source and modify it to your liking.

    What's so hard to understand?
  • Funny. Our business is dumping a bunch of ICA stuff in the next few months (have to write the letter to break the heart of the leasing company tomorrow:) Unfortunately, we were using it to run apps on some nice laptops (IBM 360p's) that weren't up to running the entire program locally. What really killed us on keeping the technology is having to spend money on both MetaFrame and Terminal Server. Yeah, I've looked for some linux/unix/mac/"anything but M$" solutions, but FreeMed [freemed.org] isn't quite there yet (hard to tell from the demo, and I've been too lazy to install it locally yet.
  • Problem is that M$ makes money from selling licenses to new products, NOT by selling support (who the hell would pay for that support???) So they have to role out Win 95, Win 98, Win NT 4, Win2K, Word 95,97,98,99,2000, etc. If they convince GM (just a name pulled out of my arse) to upgrade their entire operation from Win 95 (or NT 4.0) to Win2k, that's big. And, since you have this new OS, buy these new office apps. Oh, BTW, there's new API's all over the place, but don't worry about that, since you have all new stuff.

    Now, to shift gears a bit: M$ has a lock on the office app market. They stop offering Word 2000, and start selling 2001. Unfortunately, you must have Win2k to run it. Your argument would say that the consumer would balk at the idea and continue running Word 2000 on Win 98. But, unfortunately, the marketplace has shown that what will happen is that Joe doofus Consumer will buy both the new OS as well as the new version of Word.

    Trust me, I wish things work the way you say. Honestly. At my work, (before I started and also before I 'saw the light') they locked into a program that is M$ only. No clients for anything but. And as they upgrade the system (adding core functionality, BTW) they use the new API's, etc. and force us to upgrade our entire setup. Luckily, they haven't said we'll have to switch to Win2k (yet) as our hardware would turn into a cinder at the requirements.

    Now that I am totally off topic (sorry:) if anyone knows of any open source medical records software (and medical billing software) please email me ASAP (ghowell@familyhealthcarepa.com) as we are close to a point at the company where we have an opportunity to jump ship.

    Back to the main point: M$ can force new and incompatible API's on the public. Don't support software that only runs on the old stuff (And they don't. Show me one instance where M$ still releases bug fixes on a product that has been discontinued for... three years), force people to upgrade one item, and let that requirement cascade into purchasing other items. There's a reason for the DOJ suit and there's a reason to be afraid of the UCITA.
  • Corel are incorporating the ability to
    give wine-programs the KDE look and feel,
    which also means, the same thing could be done for
    Gnome.
    But I give you one point.
    The availability of programs for Linux, that
    is obviously worse than the windows ones,
    because it doesn't integrate well with the desktop
    environment is actually bad for Linux.
    Because it slows down development of REAL
    applications for Linux, and creates the situation
    where people just say:
    "why use Linux, when all the applications work
    better with Windows".
  • >Wine windows currently look like they don't really belong there, as if they have been transplanted from another system, erm... wait a second, they HAVE been transplanted from another system.

    Yes, that's intentional. If you want Wine windows to look like normal windows, use "wine ./app.exe -managed" and the apps will be managed by whatever window manager you have running (including KDE's kwm).
  • If you are using VMWare, you might as well leave it running on the local machine (for the purposes the original person wanted). (And VMWare is $300.)
  • Well some of them anyway. It has an X viewer, or it can spew out ascii, or it can create tex files so that you don't lose (all) the formatting.

    Dunno if it'd be good enough for what you want, though. It should be available as part of your favourite linux distribution. Type "apt-get install catdoc" in debian.
  • The AC reply to this states that I am on the WordPerfect 2000 Office Beta testing program. They are not using Winelib as you claim. They are using the Wine program loader. However, regardless of whether they use wine, or winelib, is this really the way Corel should do their Linux coding. I would expect this from a predominently Windows shop which is dabbling with Linux, but Corel are positioning themselves as a Linux player, with their own distribution and the like. The simple fact of the matter is that apps written for Windows and then run through Winelib would not be as effective as apps written to compile for both Windows and Linux. I would expect Corel to be making native Linux versions of their applications, taking full advantage of Linux libraries and with command line functionality. If this is an iterim measure until Corel can write full Linux versions, then that is cool, otherwise I'm not impressed. PS. is WordPerfect for Linux native Linux, or Linux/Wine?
  • I have to give credit to Corel for the great amount of work they've done and commitment they've shown to the WINE project. I also applaud them for wanting them to port WINE's look and feel to be more like that of KDE, since they're heavily pushing their modified version of KDE on the desktop. Integration with a user's default environment is crucial, IMO.

    But I don't like how Corel has done it. This is stereotypical of how software projects fragment and code becomes huge, bloated, slow, and incomprehensible. I'm all for WINE apps having a KDE/GNOME/whatever look and feel. But if you're going to do something, do it right.

    I recognize that Corel is under a deadline. That's never an excuse for poorly planned code. And I think that's why their KDE patch was rejected from the main source tree. But, indirectly, that means that a whole bunch of code already exists to be used if the main branch of WINE goes modular(Thanks Corel :)

    I think some real thought and initiative has to go into WINE to make its use of graphic toolkits more modular. Personally, I'd like to see a GNOME port, but making things more modular would let some ambitious hacker make a KDE port just as easily(well, ok, neither will be easily :).

    I'd like to poke around what would be involved to incorporate a modular look and feel into WINE. Maybe lots of #ifdefs. Maybe dynamic libraries. Definitely lots of code. Any thoughts? I'm interested in feedback.

    the Dominator
  • Forget about Winamp - use XMMS [xmms.org] instead
  • somewhat OT, but here goes:
    i recently built wine, vintage 2000/01/30, and it works great. However, i dont exactly like the way wine works with my windowmanager. a wine window will be always on-top essentially, although if i open a drawer in gnome, all wine windows get dumped to the bottom of the focus layer. Also, some wine programs will minimize - and their icon wont show up on the desktop. (never to be seen again). So, i can run programs through wine, but i have to click on my gnome panel to regain the focus for the rest of my X apps. Weird, annoying, and id like it fixed. Could wine apps eventually be made to run inside a regular window?

    using WindowMaker (latest) and gnome 1.1.2

    cheers to the wine team ;)
  • So, are the main branch maintainers going to merge the changes?

    Do we have a list of things Corel has
    improved/added in their private tree?

    Could we see a merge of the trees sometime?

    anyone who can answer these questions, i invite you to please reply.
  • Well, the idea here is that corel is working on WINE to improve it. Without the CVS, you have to wait weeks between each version to download their work.

    CVS, on the other hand, can be updated daily. This means that you can watch (and download) the work that Corel's been doing, without waiting for them to pretty it up package it, and distribute it

    If used properly, CVS is the ultimate "release early, release often" -- you have as much access to in-progress code as one of the corel programmers. This is a Good Thing (tm).

  • > trying to emulate win* crap on linux is a losing proposition. I will only run NATIVE apps on my linux box.
    > I am not sure I really see the value of emulated apps - especially when more and more native apps are starting to become 'serious'.

    Well, in my case, I have to support many WINXX only apps, but I want to run a better os....
    I could, and currently are trying, to put WINE to good use in running these apps untill a) they are ported to Linux, b) there is an opensource alternative that can replace the current app , for example VNC replaced pcAnywhere for me.
    Of course I'd rather run a native app, but believe it or not, there are developers out there that don't know what Linux is. (Poor, lost souls...)
  • Speaking of wine, dev release 20000131 is out now.
  • There are a lot of fixes especially for the needs of corel in it. Some of these fixes have be be cleaned or implemented in a cleaner wey before going into the wine-cvs tree back since some of these are workarounds for special cases needed by corel applications. This does not mean these fixes are not important since they show the places where some more work is needed. Most of these stuff is not cruical for other applications. juergen (wine-developer)
  • >2. What huge pain will it eventually become to >merge it all into one thing again. It gives us the occasion to review/extend some code done as 'quick fix' for their needs. >4. Since the Wine team rightfully can claim that >their code represents the main trunk, isn't >Corel's offering their branch code in the fashion >they have (available to check out, but closed to >outside commits) actually an assult on the Open >Wine team? No a bit ;-) juergen (wine-developer)
  • Wine Is Not an Emulator. It actually implements the Windows APIs in Linux, last time I checked. M$ can still change their APIs, but they'll lose some compatibility.
  • WINE has always seemed to be a great windmill-tilt, and even moreso today. How long did it take 'em to get Win32 support?

    I would think that a more practical use of time would be trying to get the companies who have the products that you'd be WINEing to release Linux versions. Change the sickness rather than getting around the symptoms.

  • it may turn out to be as useful as the broken kde sources they have up for 1.0, i'm suprised nobody seemed pissed about the kde sources... they did make alot of changes to it and made it more windows-ish, anyways isn't that part of the gpl you have to provide the full sources?
  • The current version of wordperfect for linux is native.
  • If you don't mind switching window managers fvwm95 [uia.ac.be] looks just like Windows.
  • I am waiting for some of the macromedia stuff to work in wine.

    Fireworks saves about 5 mins for every image on a webpage over Gimp, and as for Flash and Director I need to use those for university.

    Macromedia products at the moment almost work (ignore the 5's at winehq).

    Still even better would be native ports (I would get the cash out for one) I am going to a Macromedia conference in the UK at the end of the month with some of my fellow LUG members, we will ask the questions.

    Sparkes

    *** www.linuxuk.co.uk relaunches 1 Mar 2000 ***
  • >>> Corel's been moped around quite a bit by Microsoft. Since Linux looks like it could actually be a viable alternative to Windows, it's not at all suprising that Corel helping it all it can to erase the definciense that Linux has on the desktop

    see also IBM
    " Netscape
    " Compaq
    " D.R.
    ... the list goes on (wheres AOL?)

    its funny how Microsoft keeps making enemies and they all forge together through linux, its like the software "promised land"

  • Well, surely it is in their best interest to work together with the "pre-fork" maintainers. Merging in changes from a different tree (whether it's from Corel to Mainstream WINE or vice versa) is a major undertaking.

    Netscape is doing a tremendous effort at integrating "outside" patches even if they come with no immediate added value to themselves, and if you track netscape.public.mozilla.* and look for the Netscape internal developers comments on that situation, you'll realize just how formidable the task is.

    I am extremely relieved to see companies like Netscape and Corel sticking it out, trying to meet the conflicting goals of keeping the shareholders happy (release on time, on target) and the goals of the open source community (release when it's ready, and fix *this* bug now even though it doesn't hamper customer acceptance of the product).

    Hail Netscape! Hail Corel!

  • yes, Star has possibilities. I've not explored it completely yet. if it reads powerpoint and word files (maybe excel, too), then I'm totally happy. for home use, at least - where things aren't as critical as they are at work.

    I'm just not 100% confident that Star will be a full replacement for even just _reading_ word (etc) files. corel wordperfect, as one example, was supposed to be able to read and write .doc files. but for all the ones I tried (while at work), it failed horribly. that's why I don't have much faith in Star.

    again, the context is: while I'm at work. I need to know that the file that some Word-happy bozo sent me can be read faithfully. I know 100% that when I run Word on NT I'll be able to read all that the bozos send me. and exporting the screen, keybd and mouse (which is what citrix does) isn't nearly as tricky as trying to emulate windows and ALL its api's. so I trust citrix's ability to get the total job done better than some emulated thingie.

    --

  • by Anonymous Coward
    REDMOND, WA -- Today's most surprising news is perhaps the document that was leaked from deep within the local software giant this morning. Delays in the bug fixes to the company's upcoming release of their own operating system have not been going well according to this internal memo, dubbed the Groundhog's Day Document. They are experimenting with putting their own brand name on an unnamed distribution of Linux using the Wine emulator. The memo stated, "[I believe] we can do this with about a dozen programmers instead of thousands. We can use the same ones who replace the names of other competitors we've bought out on the products we've acquired from them." It goes on to point out that the only hurdle is if they get caught putting a shrink-wrapped license on Open Source software. "UCITA will make possible a few strategic non-disclosure clauses which will eliminate that possibility." Industry experts indicate that it is too early to make specific predictions, but layoffs are expected.
  • by Anonymous Coward
    The real address of the WINE you're thinking is http://www.winehq.com [winehq.com]
  • Hopefully, the lessons Corel learns in binding the KDE UI to Wine will be useful to be abstract UI team for working out what the abstract layer should look like.

    --
  • Take a look at the page Application Print Services Library [corel.com]

    It is intended as a "printer-agnostic" scheme for getting at printing capabilities.

    It is somewhat unfortunate that there have been few realistic attempts to really upgrade printing; this is a weakness for business applications.

    I don't know but that Corel is creating another "island" not unlike CUPS [cups.org]; I'd be more impressed if Corel was putting some programmers into something like Display Postscript so as to both make it functional and to help provide whatever integration is possible with XFree86. (There's some "license impedance" that, regardless of any flaming that might take place on Slashdot, is unlikely to change any time soon...)

  • It's kind of an apples v.s. oranges thing.

    MS beta = closed source = you can't see what they did differently

    Corel beta = open source = you can see what they did differently = if you find a bug you can go fix it yourself and send the idea back to the developers!
  • And there have already been patches posted to wine-patches porting some of this stuff over. The announcement sent to the wine-devel list by Gavriel State (one of the Corel people who has been working on wine) states:

    <i>We plan to start merging our changes back into WineHQ (ie: making patches out of our CVS commits) after we release. In the meantime, if anyone wants to do any of that work for us, please feel free to submit any patches you want from our branch so long we get credit in the changelog. 8-)</i>

    I'm planning to merge in the x11drv/dib fixes if noone gets to them before the weekend, to see if that fixes the problems I've been having with msvideo stuff.

    Look in the Changelog if you want to find the sort of stuff Corel has been submitting.

    Note - extrans mode isn't working in the preview. Don't know if it'll show up in the post.
  • Corel just doesn't get opensource. Am I really the only person posting on this article who sees a problem with Corel forking the Wine project (for that is what they've done)? Granted, under the BSDish license being used by Wine, it's legit: but it seems indicative that COrel are not really on the ball in terms of cooperating with the community.

    If they were, they would work as part of the Wine team, and use the Wine teams CVS server. How much time is going to be wasted re-integrating their changes into the existing Wine tree? How much time has been wasted on duplicate bugfixes.

    *sigh*

  • Well, to be precise, WP 2000 are native apps. They are simply compiled using the libwine libraries that ease migration from windows. Wine is both an "emulator" in the sense that is can be use to fool the application into running under Linux, and a library that allows easy compilation of windows apps as native apps. I fail to see how this could be a problem. Haveing an easy port path from windows to Linux can only be a good thing, and thats all libwine is, and port path.
  • Yeah, I agree. Printing is a mess in UNIX... it's received such little attention over the years that the system now seems seriously broken. CUPS is nice, but it's just a reaction to the balkinization of printer standards from straight Postscript to proprietary protocols. Ghostscript can't keep up with the new stuff out on the market. While lpd is constantly being updates for security fixes, I don't see many new features, and certainly no thought of integration with proprietary printer drivers (nor should they). CUPS looks pretty nice in this regard.

    I understant patent issues are preventing direct inclusion of TrueType support into XFree 4.0, requiring the use of a font server instead. That seems to leave some kind of Display Postscript X server extension as the best alternative. Since Adobe is never going to play ball, what about the Display Ghostscript project over at GNUStep? I understand there's a new release coming soon, and that the DGS and xdps stuff is getting close.

    Boy, MacOS X looks pretty good from this vantagepoint, eh? :-)
  • As I understand it, Corel is using WINE as a way to make porting windows applications a lot faster, so that someone already heavily invested in Windows software won't have to spend as much time creating a product from scratch if they want it also available for Linux.

    At least, that's what I _think_ they're doing.
  • Wine maintains it's own registry files, and it can read (not write) Win95/98/NT 4 registry files directly. So in a dual-boot situation Windows stuff sees all the registry info it expects, but any changes go only to Wine's copy of the registry so it can never hurt your Windows files.
  • Pretty much the same idea, albeit on a much smaller scale, IBM NetObjects TopPage for Linux [ibm.com] has links to download a base version of Wine required as well as the patches which must be applied on top of it.
  • I totally disagree. Microsoft is a victim of its own success, it can not change the API as fast as you think. The installed base of Windows NT 4.0, Win95, and Win98 boxes is too huge for Microsoft to consider making drastic changes. Microsoft's strategy has been more making more APIs and has not made too many changes. Any of the changes that have been made to the API, the Wine community has been very fast to respond. That is the beauty of Open Source.
  • This is a common misconception about WINE. Part of WINE is a Win32 API "interpreter" that translates Win32 API calls to their equivalent Linux/*NIX library calls, etc...

    However, WINELIB, which Corel has based it's Office2000 suite on, is a Win32 API layer for Linux/*NIX. It's a library that provides the necessary API calls for natively compiled binaries to use. This is analagous to Cygwin and Interix for WinNT. They provide the completePOSIX/*NIX API layer for Windows. Although MS claims that they have a POSIX layer, it is minimally implemented for compliance only, and does not provide the complete layer.

    Heh, I can't diagree with the fact that MS has done this several times in the past. However, most of the changes are at the C++ level, inside MFC, rather than at the Win32 API level. Granted, there have been a bazillion Win32 API's...

    - Ken
  • I'm glad to see Corel do this. Quite recently the project leader of the Corel division responsible for porting their Office suite over to Linux using WINe accidently posted a message to the Wine-Devel mailing list instead of their internal Corel Wine-devel mailing list. In it he stated that as the were hoping to push for a Beta release of Corel Office that they would have to lower priority on handing patches back to the wine devlopers from their own internal version of wine.

    With this announcement Corel have shown that even though they may not currently have the time to submit patches back, they want to give back something to the developers who have worked so hard on WINe. The BSD-like license of WINe means that they legally dont have to do this.

    Kudos to the Corel Wine Developers!

  • Well, the BTA I signed (The second one they sent me) only has restrictions regarding "Confidential information". It goes on to say that it is not confidential if a) it's WINE b) you had it before c) it will be disclosed after the beta test regardless of what you do.

    Tat's simplifying the legal-ese, but seems to cover it. Anyway, a screen shot I can't see as being confidential under any circumstances. Since it gives you no info about the software. And they are going to sell this stuff anyway, right? Screen shots are fair game, IMHO. If they disagree, they'll say so.


    ---
  • It does in fact read Office 97 Word and PowerPoint documents at least. However, some stuff seems to be misaligned sometimes when it does Powerpoint.
  • A few things about this are really great:
    - KDE look and feel. Man, I HATE the way WP8 looks on Linux. It's so obviously not a Linux application. The KDE look and feel allows WINElib-based programs to integrate nicely with the desktop. Even if you're a GNOME/GTK+ fan, you've got to admit-- a KDE L&F is better than a Windows one.
    - Results. Ok, we can complain about companies using wine instead of Qt,GTK, or whatever. But with the expensive of rewriting in one of those widget sets, we'd be MUCH less likely to see these Linux ports, and we certainly wouldn't see them very quickly. I just saw a demo of Corel Office 2000 at LinuxWorld today, and I was VERY impressed. This is also coming from someone who deleted WP8 pretty quickly. The new stuff looks far nicer, and it just blew away the new Applix 5.0 beta, even though Applix even uses some GTK+ widgets now.
  • Add to this x2vnc (which is available here [hubbe.net]) which allows you to have a dual-head system with Unix and whatever else. I can just roll my mouse over to my NT box, and do stuff there!
  • According to http://opensource.corel.com/wine.html, Corel forked the code tree so they could get WINE working with more apps, sooner. WineHQ was taking way too long with modular toolkit support, so Corel split off and developed their own WINE for Qt.

    Anyway, Isn't that exactly what this project needs? I would have hoped that WineHQ would be putting more time and effort into important stuff, not fluff like look & feel. Maybe that's why WINE has so far to go.
  • by drivers ( 45076 )
    Dude! You need to try this program:
    http://www.uk.research.att.com/vnc/ [att.com]

    It has different benefits vs. disadvantages than citrix of course.

    Here's a screenshot of what you want. :)
    http://www.uk.research.att.com/vnc/vinci1.gif [att.com]

    Oh yeah, it's GPL'd too.

    I'd be curious to know if it works out for you.
  • You can get it via anonymous ftp, here [corel.com]. It's actually linked to from their webpage, but it's not very obvious. They probably didn't want to scare non-technical people.
  • Not necessarly, when MS changes their API, it still has to remail backwards compatible. They can just add new features. But those features have to be relatively well documented for new programs to use it. The result: old (before API change) applications will still run, while WINE will have time to catch up for the API change at the same time as new programs use added functions.
  • Work is already underway on merging the two trees back together, as Corel have done periodically in the past. (Previously, they just submitted patches to sync the two, rather than opening their own tree.)

    The two trees were last resynced in Wine-991212 (i.e. a little under two months ago).

    If you are interested in what's changed, you can try here [cam.ac.uk]. That gives some idea of the difference (the statistics quoted are for a diff -u between the current Corel tree and Wine-991212). Essentially, it is a 32 000 line patch, totalling just over 1Mb and affecting 251 files, so it should keep us busy for an afternoon or two :-)

  • I agree. Corel is showing that they ARE getting free software, as much as a corporation can. They can't justify spending money so that programmers screw around with free software, that wouldn't be in their investor's interests. However, they are contributing to the WINE community in the same way as they are taking from it. IIRC, WINE is BSD-licensed, not GNU, so they don't even have to. They COULD just make the changes and keep them to themselves, but they would rather give to WINE so that WINE moves foward.

    I'm really impressed. If Corel becomes a "Linux company" (i.e. Red Hat, Caldera, etc.) then they will probably maintain programming staffs to do generic Linux work like Red Hat and Caldera do. Until then, they are looking at Linux as a way to reposition WordPerfect. Because MS refuses to port their apps, Corel and Netscape will probably utilize Linux to gain marketshare.

    Corel is showing how a company that makes traditional software can try to profit in the Linux environment while supporting the community.

    Alex
  • This is the first version of wine that allows me to run Napster, winamp (!!!) and FreeAgent.
    It seems to mee that the wine-developpers are finally far enough to release a pre-production version.
  • Corel's life blood has been keeping up with the Windows API changes (although M$ shenanigans along these lines are always a problem), so what Wine does for them is allow them to use the code base of the Windows apps to quickly port to Linux.

    I'm sure that Corel is as eager as you to see the day when their apps are Linux-native first, then get ported as an afterthought to the legacy MS OS. Until then, there's a purpose to Wine, namely being a stepping stone for Windows apps to Linux land.
  • A big problem with VNC [att.com] in the corporate enviroment, compared to Citrix, is that you are remotely controling a single windows machine.

    If you have 5 users who may need to access windows at the same time, you need 5 windows boxes to connect to using VNC. You could not get by with 1 "VNC Server" machine to serve separate windows desktops to multiple users at the same time.

    An interesting implementation I would like to see would be a Linux box using VMWare [vmware.com] to 'spawn' windows machines as people needed them and dynamically assign them out VNC requestors.

  • According to their WINE page, Corel's programmers have been working only on the internal WINE source tree, mostly for buxfixes. They claim to have been focusing on it because of "release deadlines for our Linux applications approaching..." Does this mean that they're using WINE as a backend to their Linux apps? I hope not ... I'd much rather run natively complied code. More stable, and a whole lot faster.

    Speaking of speed, they also say that they've integrated some KDE-like code to do UI-management and themability. It'll be nice to have more options than "look-like-win31" and "look-like-win95" but what is this going to do for performance? Already, WINE runs anything more complex than Minesweeper pretty slowly -- ever wanted to see Mathematica really crawl?

    Still, I'm looking forward to checking out what they've done to the code. Hopefully, WineHQ will start picking through the code right away to merge the good bits with the main tree.

  • Until then, there's a purpose to Wine, namely being a stepping stone for Windows apps to Linux land

    our company bit the bullet and bought citrix to deal with the M$ world. so when someone mails me a .doc file (argh!), I can run a real windows app on a real windows box, only the display is redirected to my linux desktop box.

    no need for emulation at all - other than piping the 'doze display over the net to my host. yes, its not cheap (citrix is a commercial and expensive product) and it does need a big box to run on but it does bridge the gap for those in business who [unfortunately] have to be able to read those stoopid .doc files from a unix host.

    --

  • by pb ( 1020 ) on Wednesday February 02, 2000 @01:55PM (#1310396)
    Microsoft, public, and beta should not exist together. In fact, they don't.

    Corel is freely releasing their contributed source code changes to an open source project, even though they don't have to.

    The WINE license allows you to incorporate the entire WINE project, modify it, not release the changes, and sell it. That's fine, but Corel isn't doing that.

    The WINE project is a reimplementation of the Windows libraries and environment on top of Linux, (and *BSD and hopefully all of Unix with a little x86 emulation... :) allowing easy execution and porting of Windows applications on/to Linux.

    Microsoft, on the other hand, places their products on a very restrictive license, sometimes charges people for beta releases, (and for that matter always charges people for "gold" releases that would be better called beta releases ;) and wouldn't dream of freely releasing Windows source code.

    Heck, they wouldn't even give you access to an ftp archive, and say "check out the alpha Windows daily builds", unless you're a WaReZ d00d. (anyone remember Windows '97?)

    I'd be happy with Microsoft if they decently ported *any* of their apps to Linux with WINE, and contributing to the WINE project would be a plus. Because MainWin blows on Solaris and HP/UX, and I've run IE 3.0 and Photoshop 3.0 under Wine so far, so I don't think it would take that much work on their part, and they'd get a decent software port.

    The only reason for them *not* to port to Linux is their OS monopoly, because a lot of people would still buy their software. Especially if they tried giving back to the community for once, instead of just taking our money and giving us substandard products.
    ---
    pb Reply or e-mail; don't vaguely moderate [152.7.41.11].
  • by maynard ( 3337 ) on Wednesday February 02, 2000 @05:33PM (#1310397) Journal
    ... quit your whining.

    Corel was in their rights to fork off the open Wine tree at any time and not even share back. I'm certain the project heads at Corel responsible for the winelib portion of the Corel Office for Linux product certainly supported the notion of their control over the release flow and which critical bugs to squash. Corel is producing a product on a time schedule for sale in the commercial world. I'm sure this set a somewhat different agenda than the Wine project leaders might pursue; I doubt the Wine team feels the slightest wrong'd as well. Nor should they. Why choose the BSD license otherwise?

    Don't bitch, they gave back.
  • by Ian Schmidt ( 6899 ) on Wednesday February 02, 2000 @05:56PM (#1310398)
    You are misinterpreting. All non-UI support and fixes Corel's come up with up through Dec. 12, 1999 is in WineHQ's tree already. The remaining items were submitted earlier today as patches to WineHQ, and will likely be in WineHQ's CVS by Friday. WineHQ was NOT stalling Corel - Corel simply wanted a stable base for their commercial apps.

    WineHQ is currently fixing the last major architectural problem that prevents full Win32 compatibility ("address space separation"), and there will be earthquakes in the tree for the next 2-3 months :) Since Corel's apps aren't running on the emulator portion of Wine and don't need that feature they're fine with a more or less out of date tree.

    As for "important stuff", I assume you're bitter because you have some favorite app that doesn't work. Read documentation/bugreports that comes with Wine, subscribe to comp.emulators.ms-windows.wine, and start throwing out some useful bug reports. We can't fix what you don't report.

    Thanks,
    -Ian Schmidt
    wine-devel, in the Wine AUTHORS file, and proud of it
  • by XNormal ( 8617 ) on Thursday February 03, 2000 @01:19AM (#1310399) Homepage
    Wine windows currently look like they don't really belong there, as if they have been transplanted from another system, erm... wait a second, they HAVE been transplanted from another system.

    A KDE theme should help them blend in more nicely with my desktop. It would be really great if they could be made not only to look more like native windows but also cooperate more nicely with the window manager. I want them to appear on my taskbar, minimize using the window manager conventions instead of minimizing to a rogue desktop icon, etc. I guess the wine team have their own reasons for doing it the way they have, though.


    ----
  • by thimo ( 36102 ) on Wednesday February 02, 2000 @01:04PM (#1310400) Homepage
    From the same page, this is what I extremely like:

    Corel has been working with the WINE community since late 1998, concentrating on those areas of WINE that are required to allow us to complete WordPerfect® Office for LINUX®.

    No BS, straight forward: Just develop the things you as a company are going to need in this piece of OS software and release it back to the community. Cheers to Corel! :-)

    Thimo
    --
  • by drivers ( 45076 ) on Wednesday February 02, 2000 @01:53PM (#1310401)
    Releasing source code to developers is not the same as releasing buggy binaries to end users.
  • by Ian Schmidt ( 6899 ) on Wednesday February 02, 2000 @01:57PM (#1310402)
    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!
  • by Non-Newtonian Fluid ( 16797 ) on Wednesday February 02, 2000 @12:56PM (#1310403)
    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 [corel.com].

  • 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 [corel.com]) 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.
  • by Ian Schmidt ( 6899 ) on Wednesday February 02, 2000 @05:36PM (#1310405)
    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.
  • by DeathBunny ( 24311 ) on Wednesday February 02, 2000 @01:28PM (#1310406)
    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.

For God's sake, stop researching for a while and begin to think!

Working...