Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Corel

Corel at LinuxWorld Conference and Expo this week 35

Mark Lipson wrote in to tell us that Michael Cowpland of Corel will give a speech about Commercial Software and Hardware in the Open Source Marketplace and a demo of the Quattro Pro spreadsheet running under Linux, at LinuxWorld on March 2, 9:30-10:15 AM. The speech will be webcast on Wednesday. In related news, Eugene Lacey wrote in with an article claiming that IBM is dissing Corel's Wine plans.
This discussion has been archived. No new comments can be posted.

Corel at LinuxWorld Conference and Expo this week

Comments Filter:
  • I'm going to make a script to auto-post my standard Wine response to comments such as these, but in the meantime, here is my latest variation on "you don't know anything about WINE":



    Corel's intention from the beginning was to use components of Winelib to assist in native ports to Linux. In this respect, it's like using gtk or qt (actually more like gnome-libs or kde's equivalent). They haven't backed off from anything, and they have contributed a lot of time and people towards Wine so far. I would expect later versions of their applications to move to more cross-platform development. In the meantime, fixing Wine is much quicker than rewriting their apps from scratch.



    Also, WINE alone won't attract uninterested Windows users. People who have wanted to use Linux, but were dependent on a Windows only program, would be more inclined to switch. Lotus Notes is a good example of this. Eventually, the market demand will result in native ports.



    And finally, Microsoft can't change APIs without annoying their developers. Basically, nothing goes away, just new stuff is added. And most of the time, the new stuff is just a new wrapper over the old stuff, with a few extensions. Once Wine is fully functional with the current Win95/98/NT base, keeping up with Microsoft changes won't be hard. And it will only be necessary until the Win platform loses its monopoly.



    So, in conclusion, Wine won't hurt you or Linux. The worst case scenario is a bunch of developers end up wasting their time on a project they code for fun (primarily). The best case scenario is a bunch of Windows users and developers use Wine to run/port applications on Linux, giving us more market leverage to get open hardware drivers and the latest games (which, ultimately, is the ONLY reason I care about our marketshare).

  • I recognize that the Wine developers are a very talented group of people, but I think it's a mistake to hang the future of Linux on a reverse engineered clone of the Win32 API.

    Getting all those Windows apps running on Linux seems like a good idea short term, but unfortunately it will prolong the life of that broken API from Redmond.

    If you think running Windows apps on Linux is a great thing, then go get yourself a bigger vision of what Linux can achieve on it's own without dragging Win32 along for the ride.

    Windows is a disease that can't be cured, let's stomp it out while we have the chance.

    TedC

  • exactly, and even using Wine it should be as fast, or faster.

    I wouldn't be surprised if the underlying calls were better written, and faster, on Linux, due to the compiler, lack of API coverage, (stub calls are faster, when they work :) and better-written underlying OS.

    I remember when I'd defragment my DOS partition under DOSEmu because it was faster, Linux would cache that space and DOS would just churn the HD. Those were the days, now everything is ext2. :)
  • Yeah, so what's the gig with the Netwinders?
  • They sold it off for part ownership of a hardware manufacturing company... So that *should* mean that the Netwinders are proceeding full steam...

    Instead, I've not heard "boo" about them since then... What, are they dead? Shouldn't they be advertising like nuts? Shouldn't they be at LinuxWorld? Although the site suggests that you can still order them, something is very wrong.

  • Corel is beating a dead horse. If ANYONE would know about trying to emulate/port win apps it would be IBM, which did one hell of a job trying to support win 3.1 and derivatives on OS/2.

    IBM even tried to get Lotus to deliver SmartSuite using a similar angle (Open32 vs. Win32). It exists, years after the promises...now that no one cares. Corel has nowhere near the deep pockets IBM has and does not have the commitment IBM did have (they promised OS/2 for 10 more years to large corp customers, and to IBM's credit they keep such promises). Promises are a dime a dozen at Corel.

    Corel is grasping at straws and Copeland always gives good press.



  • ...given that they have themselves done a (fairly reasonably) Windows box for OS/2. Yes, I know that's a slightly different situation, but even so...

    He seems a little anti-Java, too, which is not at all the way IBM as a whole seems to be doing. Earlier poster has it right, this guy really isn't authorative.

  • Can someone give me more information or point me to all currently available information on porting Windows apps to Linux?

    (Yes, I'm a Windows vendor looking to port to Linux, one of 1000's more to come, I am sure).

    Thanks for any help. It looks like a daunting task. Microsoft has us really tied into their MFC, but I think it's worth doing.


    [speaking as an occasional wine user, not a developer]

    Check out www.winehq.com for the primary wine homepage and comp.emulators.ms-windows.wine for the primary newsgroup. You may find wine is 'good enough' already for a porting project, but it's nowhere near a functional Win32 runtime library. What that means is that you may be able to tailor your codebase to the API already available on wine to get a working product now; of course, maybe not. The wine folks would prefer you fix problems with the wine API instead of retrofitting your application codebase to work with wine. I'd say you should fiddle with wine a bit, decide if it's the proper porting tool for you, and if so let your software engineers decide what parts of your codebase should be mangled to work with wine and what parts should be fixed within wine itself.

    And, as I'm sure the wine developers would say, please pass those patches and bug reports back to the wine community!

  • Also, both Motif and qt are commercial and as such require commercial licensing (for qt only if you're planning a commercial product).

    ...and many Linux users might not have Motif on their systems, as they may not have wanted to pay for it (or may only want free software on their systems, but those folks aren't worth worrying about if you're making commercial software, obviously).

    There is, of course, LessTif [lesstif.org], which is a free-software Motif clone, and which at least some Linux users might have installed. I've not used it, so I can't say whether it's "close enough" to Motif for most purposes; I have the impression it might be - check out the LessTif site for more information.

  • especially the part about haphazard directory structures (I can't wait to see WINE apps installing stuff to my root without letting me change it).

    However, wine is still good. Even if I had every major application NATIVE to linux I would still need wine for all the little piddling things people around here run on a daily basis -electrical code software, vendor catalogs, none of this will be ported to linux until linux takes over completely. Until then we'll need wine for the little things.
  • Problem that Corel has is that they want to keep support of their Applications on the various platforms. From Linux to Windows and all Operating Systems in between.

    To accomplish this they are writing a means to use WINE code as an interface between their generic code and the system dependant code of the Operating System. An example of what they at Corel are putting together.

    Corel Draw Corel Interface WINE Code

    Quote from Derek Burney:

    Exactly, if we write what we call a portability layer, which allows us to write non platform-specific code on the one platform it
    minimises the amount of platform-specific code on the other and makes our job much easier to move from platform to platform.
    And we've already done quite a bit of that because we've done several applications and ported to the Mac, for example. So we
    have a lot of experience in writing so-called portable code.
    (http://www.zdnet.co.uk/news/1999/7/ns-7106.html )

    My opinion is this is a good short term means of getting things done. If we could find the specifications to the Corel Interface to the Operating System and it become Open Source, (LGPL or BSD), then this could be enhanced to the point of being Linux, *BSD, or Unix specific.

    The source of my insight or guess is from the article from ZD Net UK. Where the quote above is from.

    Other purpose of the WINE idea is that it will allow the porting of other comercial applications.

    End all is for Corel, "Go for it." For IBM's position, it is true it would be better if you reduce the layers, there fore increase efficiency. So I say put the interface under LGPL or other, Corel over sees the project and lets the world contribute. Note is I see the other interface packages could be use for this end, or as a starting point if the packages are ported to other Operating Systems, namely non-Unix OS systems.

    Iain
  • Using WINE should be a method of last resort for porting apps to linux. Yes, I will be very happy when it works. But, it encourages developers to continue to do things in the MSWay, terrible directory structures... no available underlying cli, filenames with all capital letters.... basically, a lot of the really minor and insignificant things that I hate about MS*.
    On the other hand, if the app runs, run it..

    I'll bet by the time wine/corel/everybody else is through with it, it'll be comparable performance to win*.
  • by Axe ( 11122 )
    If you are reach enough to by commercial Qt [troll.no] library, then you can make your application to compile under Linux and Windows without any change and with a consistent and very pleasant look and feel. But this is, of course, for your future development, not for the port from MFC.
    Qt is much nicer to use than MFC. Download the free version and try. Commercial version includes some sort of OpenGL support - know nothing about it.
  • I just tried to view some of the videos at the ZD webcast URL given above. I get a compression error which may indicate that I need RealPlayer G2 (I have RP 5.0). If this is the case Linux users may have trouble watching the webcasts.

    Anyone have a url for the Linux beta of RP G2?
  • (Yes, I'm a Windows vendor looking to port to Linux, one of 1000's more to come, I am sure).

    You might also check out Willows [willows.com] which produces Twin, which is a commercial (albiet free in some circumstances) product similar to Winelib. It includes an implementation of the Windows APIs and MFC.
    I'd like to see Winelib be successful in the long run, but in the short run, Willows' product may be a better fit for you.

  • I guess nitsuj is right. If you only need to make a change to WINE when there is a change in the Win32 API, then I guess this is a good deal. I also guess I wasn't quite understanding of what Corel was doing in using it port rather than just use on the emulator. If this is the case, then I guess it is a good idea.
  • One more dumb question.

    How do we post fixes we make to Linux and to Wine. I.e., what's the procedure of sending the modified files.
  • So what's the best choice if your a Windows developer wanting to also have your app ready for Linux?

    This should be an important topic. If everyone is serious about Linux, there are a great many ISV's heavily (and unhappily) stuck with Windows. The easier it is to port, the faster Linux is going to win market share.

If it wasn't for Newton, we wouldn't have to eat bruised apples.

Working...