The IDC report in question shows numbers from '98-'99. Corel Linux wasn't *RELEASED* until late '99. This is an utterly bogus report. How it became 'news' is beyond me.
The product that Corel just released is PhotoPaint *9*, not 8. PP9 has lens flares as one of the built-in effects, so you don't need PhotoShop for that anymore....
The place where PhotoPaint shines over PhotoShop is it's brush support. You can do some extremely cool things with orbits, for example. You can tune pretty much any brush parameter you can think of, and even have some of the parameters vary randomly (within set limits) over the course of the stroke. And you can paint butterflys with the Image Sprayer. 8-)
PhotoPaint for Linux also comes with a tutorial that shows you how to put together a custom KDE desktop theme.
There is no appreciable performance difference between applications using WineLib and applications run using the WINE binary loader. The *only* distinction is in the way the code is initially loaded - with an ELF binary linked to WineLib, it's loaded by ld.so; with a Windows.EXE binary, it's loaded by WINE's loader.
WINE based apps are no less 'native' than QT or GTK apps - they're all using an API layer on top of plain Xlib. It's just that WINE's API happens to be identical to the MS Win32 API. There's no CPU or other hardware emulation involved - just the loader and the implementation of the APIs.
There is no significant performance penalty for using the PE (.EXE) binary loader vs using winelib - the *only* difference is that WINE is doing the work of loading the binaries instead of ld.so.
In fact, the binary loader can be *faster* than using g++ compiled native ELF code, for a couple of reasons:
1) code produced by g++ isn't generally quite as optimized as code generated by MSVC. Things are evening up with the new intel backend on gcc, but it hasn't been in an official release of gcc yet as far as I know.
2) Inter-DLL calls in PE binaries are generally just direct branches. The only work the loader has to perform most of the time is mmaping the binary into memory. In ELF, by comparison, all the symbols have to be looked up by name, and calls are made through indirection tables.
These are both really minor speed impediments, but they server to demonstrate the sillyness of declaring something 'native' or not based on what binary format it uses.
That said, we do plan on moving to g++ compiled binaries as soon as possible, since it will give us somewhat more flexibility for using.so libraries directly within our apps, rather than indirectly via WINE.
In case anyone's interested, Deneba has picked up on Corel's lead and is the second major app vendor to use WINE to port their apps. Check out the winehq mailing lists for more info - they've been asking a fair number of questions but have so far contributed no code of their own.
1) We contribute regularly to the WINE CVS tree. I have no idea why you think that we "haven't contributed anything in months". Check out the wine-cvs mailing list
2) We also have a parallel internal branch where we do some things that the WINE community doesn't want to see integrated into the main tree. For example, we did a KDE look-and-feel patch that the WINE community wanted to see turned into a full modularization of WINE theme code. We weren't prepared to do that work, so it just stayed in our tree. The patch is our there on the development lists, it just hasn't been commited to winehq cvs. Our tree also has other fixes that WINE developers have made that haven't made it into winehq CVS - Ove Kaaven's pthreads patch, for example. We haven't sent in many patches in December and January because we're working on our beta release, and don't have the time to spare to do a back-merge.
3) We also have contractors doing work for us - much of the work that Alexandre Julliard is doing on WINE right now is being paid for by us, for example. That work goes into both winehq and our internal branch.
4) We're planning on making our internal WINE tree available externally soon, so that other people are free to extend and merge some of our changes back into winehq.
5)We're not "just talking" about WINE. Check out this link for screenshots of our apps running on WINE.
6) All of the work that we did for Corel Linux is open sourced. All of the installer, KDE, and apt related code is GPLed or LGPLed. Code that we wrote from scratch is under the Corel Public License, a name-changed version of the MPL. The source code is all up here
--- Gavriel State Engineering Architect - Linux Development Corel Corp
This is exactly the kind of thing that we did to get CorelDRAW 8 Mac looking good in the MacOS environment. It's on our radar for Linux, but probably won't make the first release.
This is one area that we will almost certainly improve before we ship. Internally, C:\ will be mapped to / and anywhere the user sees pathnames, we will print the UNIX path, not the DOS path.
Slashdot Mirror
The IDC report in question shows numbers from '98-'99. Corel Linux wasn't *RELEASED* until late '99. This is an utterly bogus report. How it became 'news' is beyond me.
So run PhotoPaint 8 Mac using Mac-on-Linux...
It's also a free download - and on the Mac you get Draw as well!
PhotoPaint has support for CMYK, LAB, and 48-bit RGB color, in addition to the standard RGB, greyscale, 8-bit paletted, etc.
It's also got full support for ICC color profiles, which means you can now do professional color output from Linux.
The product that Corel just released is PhotoPaint *9*, not 8. PP9 has lens flares as one of the built-in effects, so you don't need PhotoShop for that anymore....
The place where PhotoPaint shines over PhotoShop is it's brush support. You can do some extremely cool things with orbits, for example. You can tune pretty much any brush parameter you can think of, and even have some of the parameters vary randomly (within set limits) over the course of the stroke.
And you can paint butterflys with the Image Sprayer. 8-)
PhotoPaint for Linux also comes with a tutorial that shows you how to put together a custom KDE desktop theme.
There is no appreciable performance difference between applications using WineLib and applications run using the WINE binary loader. The *only* distinction is in the way the code is initially loaded - with an ELF binary linked to WineLib, it's loaded by ld.so; with a Windows .EXE binary, it's loaded by WINE's loader.
WINE based apps are no less 'native' than QT or GTK apps - they're all using an API layer on top of plain Xlib. It's just that WINE's API happens to be identical to the MS Win32 API. There's no CPU or other hardware emulation involved - just the loader and the implementation of the APIs.
There is no significant performance penalty for using the PE (.EXE) binary loader vs using winelib - the *only* difference is that WINE is doing the work of loading the binaries instead of ld.so.
.so libraries directly within our apps, rather than indirectly via WINE.
In fact, the binary loader can be *faster* than using g++ compiled native ELF code, for a couple of reasons:
1) code produced by g++ isn't generally quite as optimized as code generated by MSVC. Things are evening up with the new intel backend on gcc, but it hasn't been in an official release of gcc yet as far as I know.
2) Inter-DLL calls in PE binaries are generally just direct branches. The only work the loader has to perform most of the time is mmaping the binary into memory. In ELF, by comparison, all the symbols have to be looked up by name, and calls are made through indirection tables.
These are both really minor speed impediments, but they server to demonstrate the sillyness of declaring something 'native' or not based on what binary format it uses.
That said, we do plan on moving to g++ compiled binaries as soon as possible, since it will give us somewhat more flexibility for using
-Gav
In case anyone's interested, Deneba has picked up on Corel's lead and is the second major app vendor to use WINE to port their apps. Check out the winehq mailing lists for more info - they've been asking a fair number of questions but have so far contributed no code of their own.
-Gav
1) We contribute regularly to the WINE CVS tree. I have no idea why you think that we "haven't contributed anything in months". Check out the wine-cvs mailing list
2) We also have a parallel internal branch where we do some things that the WINE community doesn't want to see integrated into the main tree. For example, we did a KDE look-and-feel patch that the WINE community wanted to see turned into a full modularization of WINE theme code. We weren't prepared to do that work, so it just stayed in our tree. The patch is our there on the development lists, it just hasn't been commited to winehq cvs. Our tree also has other fixes that WINE developers have made that haven't made it into winehq CVS - Ove Kaaven's pthreads patch, for example. We haven't sent in many patches in December and January because we're working on our beta release, and don't have the time to spare to do a back-merge.
3) We also have contractors doing work for us - much of the work that Alexandre Julliard is doing on WINE right now is being paid for by us, for example. That work goes into both winehq and our internal branch.
4) We're planning on making our internal WINE tree available externally soon, so that other people are free to extend and merge some of our changes back into winehq.
5)We're not "just talking" about WINE. Check out this link for screenshots of our apps running on WINE.
6) All of the work that we did for Corel Linux is open sourced. All of the installer, KDE, and apt related code is GPLed or LGPLed. Code that we wrote from scratch is under the Corel Public License, a name-changed version of the MPL. The source code is all up here
---
Gavriel State
Engineering Architect - Linux Development
Corel Corp
It will be up to the GCC maintainers to decide when the code gets integrated into the mainline releases.
-Gav
This is exactly the kind of thing that we did to get CorelDRAW 8 Mac looking good in the MacOS environment. It's on our radar for Linux, but probably won't make the first release.
-Gav
This is one area that we will almost certainly improve before we ship. Internally, C:\ will be mapped to / and anywhere the user sees pathnames, we will print the UNIX path, not the DOS path.
-Gav