Slashdot Mirror
Corel at LinuxWorld Conference and Expo this week
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.
Corel is phat.... Hope they can profit from all this Linux stuff. If somebody made some cash then we would have a bunch of commercial apps in no time!
The Wine libs are the equivalent of Win32 on Linux. This makes porting Windows apps easier. The resulting binary IS a Linux binary, not a Windows EXE, it won't run on Windows.
I don't know if this is a deliberate FUD, or misunderstanding (I'd guess #2)
Most people who have been exposed to Wine view it as a way of running Windows binaries on Linux. That's it's main point, and IBM is right, performance is bad when used that way. But if you take your sources, you should be able compile against the Wine libs without the performance loss.
tony_occleshaw@uk.ibm.com
What the article left out is that Occleshaw is only a marketing manager in Europe. He has nothing to do with IBM global marketing.
Not only that, he only has four people working underneath of him (none of whom are management) and is essentially a "very small fish" in a "very big pond". I wouldn't hold too much weight on what he has to say with regards to IBM's policy and stance on issues.
Linux, normal RV player.
That IBM guy knows not of what he speaks.
In fact it seems he does not even know the name of the software he is talking about.
Right. How does Wine compare to IBM's own Open32 libs?
Cause if it's the same, stuff done in Open32 tends to run...well...not so hot.
I religiously download the daily binary builds
to try them out with various applications. I
admit while it is not *ready* yet, it holds alot
of promise. I can run Excel and MS Word. They
dont work rock solid *yet* but seeing them run
is a great feeling. And they do not run slow at
all. The load time is a little longer. But hey
we haven't started doing performance tuning yet.
If we can get here, I am certain we can go
much farther.
Please do whatever you can, to support the Wine
project!
Amazed that even IBM havn't worked out yet that Wine Is Not an Emulator.
i on.src.tgz
I think the Wine folks have over estimated the ability of us lunatics to grasp that Winelib is just some library we can link against. Maybe they should have released two packages Winelib_which_is_only_a_library.src.tgz and A_handy_program_that_might_run_a_windows_applicat
Regards
Mark
Sad to see the death throws of a failed company grasping at Linux in a pathetic attempt to stay alive.
hmm, I know something that runs windows apps. its called windows. suckers
I'm fairly certain that his opinions don't reflect those of the company. If wine works well, IBM will be happy.
Lets not pay to much attention to what ibm's marketing manager had to say about a technical issue.
Marketing Manager, Says it all really.
Running Windows apps sounds really cool at first. But smallworld1 is right. As a developer, if my Windows app runs under Linux, that just means that I don't have to pay attention to Linux. I can just keep developing strictly for Windows.
I think OS/2 for Windows attracted a few more users, but no more developers. In the long run, no developers means no users.
If Corel is resorting to WINE, that's a hint that they are hedging - scaling back on their commitment to Linux. This is probably not a reflection of their confidence in Linux so much as the state of health at Corel.
GNOME is the best GUI, but it doesn't matter much
to an app developer. It would get you drag-and-drop,
nothing more. Widgets ("controls") are part of
the Wine library or Willows library.
OpenGL works properly, but it is slow.
I don't suggest doing a complicated 3d game
with OpenGL. CAD would be fine.
It would be better if companies porting software made 'native' (well, Ok, it is native if it's simply compiled with Winelibs, but still...) ports of their software rather than just taking the Windows version and squeezing it to fit. Of course, that doesn't make the Wine project worthless by any means. Anyway, in an ideal world, we wouldn't need the proprietary stuff (note: different from 'commercial'), because everything would be free software. And, in my corner of this ideal world, it would all be Linux/***BSD compatible software.
Microsoft has referred to the win32 api as their "Crown Jewels." All windows apps are built on top of it. Because microsoft controls and defines it, they can shape it to work best with their own apps. One way of doing this is by creating hidden calls which perform a function more efficiently than a similar documented one. Microsoft has already done this, starting as far back as windows 3.0 and probably earlier. Reverse engineering these calls is one of the challenges facing the wine team. Wine is good because it brings this fact to light and keeps it in the spotlight. If it is successful it will help windows developers because those calls will now be known and MS will lose its artificial advantage. Obviously it will help to port windows apps to unix as well, which is nothing to be sad about regardless what some zealots might say. The more apps linux has the better and at this stage in the game it makes little difference how those apps are ported.
Lee
leereyno@hotmail.com
Attacking their position in the marketplace is a good thing for everyone. They dominate so many different software markets right now and that is not a good thing because it gives them the ability to stifle competition and do things which are not in the best interests of their customers. Sound like whats happened already? The hidden api call story is not a lie, although I wish it were because the wine team has a longer road ahead of us. Linux may someday take over the desktop. Not in its current form however. The thing about linux which makes it different from other operating systems is that it can mutate and change very rapidly. Features which cater to the computer illiterate aren't really in place yet, but that does not mean they cannot and will not be added. This does not mean that linux _will_ take over the desktop market, it only means that the possibility does exist for that to happen in the future.
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).
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.
:) and better-written underlying OS.
:)
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
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.
pb Reply or e-mail; don't vaguely moderate.
Yeah, so what's the gig with the Netwinders?
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.
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!
...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, 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.
support gun control: take guns from cops
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.
l )
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.htm
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*.
If you are reach enough to by commercial Qt 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 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.