Slashdot Mirror

See Wine Hq. The license on Wine just (is in the process of?) changed from GPL to BSD to fit the goals of Wine better.

First of all, all old GPL code is still GPLed. They simply contacted all the authors they could find (and in fact gave them some time decide) Results were about 95% in favor, 2% opposed, and the rest unfindable. The 2% of coders were deemed insignificant in that it wouldn't be too difficult to re-code their contributions. The other will probably end up re-coded eventially if the authoers cannot be found.

There are pros and cons to all licenses, please do not get into an argument of should Wine have changed. They did, and unless you contribute code you have no voice in the change. The topic is can it be done, and obviously they have proven it can. If you want to do the same things read their archives, there is no point in repeating mistakes they made.

I finally found the link again. It is www.reactos.com. There are more than likely others, but this one is under the GPL. I think www.winehq.com has a whole list of such projects under the "other" link.

at least partially. The port is called wine (I'm sure you've heard of it). It runs plenty of Windows games already, e.g. StarCraft, Unreal, Half-life, etc. Native linux apps can also use DirectX, through winelib. Just FYI :)

WINE's liscense is BSDish, meaning that the source doesn't have to accompany the binaries. So no, Microsoft would not have to release its modifications. And anyway, there's really no reason why they'd have to, since they wouldn't be releasing a modified copy of WINE -- they'd be releasing the binary version of Office that they compiled against a modified copy of WINE that they kept entirely in-house. Remember: Wine isn't just a compatibility layer that will let you run existing win32 binaries -- it's an actual port of the win32 api, meaning that if you have the source to the win32 program (as MS does with Office), then you can compile it against wine and release a truly native Linux program.

As for all these "MS is porting Office to Linux" rumors, it's all old news, since slashdot reported on it 21 minutes from now, right? :)

From the Yahoo article: "... Gates told Time magazine in November: ``The only thing we know for sure would be bad for consumers is ... anything that made it so that when people buy Windows they don't know what's in it.'' "
Please correct me if I'm wrong, but isn't the problem with proprietary software that people don't know what's in it?! If the Windows source was open, people could begin to fix a few of the bugs that have been around since the earliest versions of Windows, or better yet, improve WINE to the point that we don't have to use Windows at all.
- Chris

One thing that would be good is to add kernel support for Windows binaries so that a Win32 emulator could be made.

"Kernel support" in what sense? Supporting exec-family calls being able to run Windows binaries (which may just involve telling the kernel to fire up Wine on them)? Or support in the kernel as necessary to make Wine work better? Or both?

Looking at the WINE app database it appears that Starcraft runs pretty well under WINE. This makes me wonder if the port could be done simply by using WINElib and fixing the few remaining bugs (mainly multiplayer stuff) that may be left. Any thoughts?

The real address of the WINE you're thinking is http://www.winehq.com

I have a windows box just to play games and run my scanner, I don't use it for any real work.

Just out of curiosity, would SANE be sufficient to handle your scanner under FreeBSD (or any other flavor of UNIX, including Linux, free or not), or does SANE have no driver for it or are there also Windows applications you need?

(There's also WINE, for some Windows applications, although I think they may still warn that it's alpha code and not everything will necessarily work.

I've noticed a lot of people asking for Games like Diablo, Starcraft, Warcraft etc. I'm wondering if these people know that WINE has been running these games since barely after they came out. PEOPLE: go download WINE. Maybe the game you want ported works already!

A little note: Most DirectX games will work flawlessly. Last I checked Direct3D did not work well.

Joseph Elwell.

Unfortunately, the same does not happen with either the Debian Project or the KDE Project, where you took their product, made a better product out of them and released back the finished products. In Free Software jargon, what you made is a fork.

Now, although Corel has released the source code to the enhanced forked products (as you were legally bound to, by the GPL), the enhancements made cannot be easily folded back into the respective projects because these projects have evolved since Corel's fork. So the original projects cannot immediately profit from the work Corel's engineers put on them.

Also, because the Free Software programmers are already commited to the original projects, Corel's forks won't benefit much from the Free Software advantages of constant peer review and bug fixes.

So, my question is: What was the motivation behind the decision not to fully cooperate in a Bazaar way with Debian or KDE projects but enhance them in a Cathedral way? At first I thought the answer was that Corel just didn't understand Open Source projects, but after seeing your comendable cooperation with the Wine Project I am now puzzled. Could it be that you needed a shipping product fast and could not afford to follow their release cycles?

And now that Corel Linux has seen the light of day, does Corel intend to work on folding its enhancements back into the original projects or will you keep on with the forking, thereby forfeiting most benefits from Open Source development model?

I understand that a question similar to this one was asked during your keynote speech at TheBazaar and your answer to it involved equating the number of download attempts of Corel Linux to the success and acceptance of your distribution, to which I am inclined to reply that such a high number of downloads is a good gauge of the amount of curiosity Corel Linux managed to gather or, at most, of the quality of your programmers, but not of the success of Corel in cooperating with the comunity.

Ok, i just ran the installer under wine, it worked fine, i used the latest release, you can grab it from here

1) This is a windows installer executable, and is faily useless on Linux... (although you may have some luck with Wine

2) Unlike Q2's compiled .dll's, which were platform dependent, Q3A's game logic source (note: that's all this source release is, not a full rendering/network engine source release) projects can be distributed as .qvm's, which are psuedo-C files parsed at run-time by Q3A's virtual machine, and thus can be run by Linux, Mac, or Win32 Q3A without any problems.

I've been trying to get in to news.lokigames.com of late, but no luck...

One interesting thing I want to pass on to the Loki folks is that (in case they haven't noticed, although I'm sure they have) WINE has a semi-complete DirectX implementation -- including DirectPlay (see dlls/dplayx/ in the source distribution). There may be some licensing issues, but one wonders if there's enough there to enable DirectPlay support under Linux.

It would be Really Nice to be able to play Heroes3 in the usual Heroes3 arenas...

DeCSS, though, does not contain any copyrighted code - it contains an independently developed implementation of CSS, and a 40-bit key that unlocks current DVDs. You can't copyright those five bytes.

The situation here is analogous to that faced by the developers of Wine - they aren't hacking individual applications, they're reverse engineering the overall system in order to bring about interoperability. The difference is that the CSS code can also be used to facilitate piracy (though DVD piracy is uneconomical). It has a legitimate use, though, and is therefore IMHO legally protected.

I don't think that WINE is a Linux-only project, is it? Currently it's definately x86 only, but it's my understanding that it runs under multiple x86 Unix-like OSes. In fact, from the WINE about web page:

Wine works on most popular Intel Unixes, including Linux, FreeBSD, and Solaris.

Hence, that the WINE project is aimed at providing binary compatability on Unix like OSes, including Linux, FreeBSD, and Solars, is not comparable to the FreeBSD kernel programmers providing binary compatability for Linux programs. Your point is meaningless.

The article does not indicate anything about WINE being downright eliminated, only that the GraphOn software will get added in.

It is not self-evident that WINE becomes of no value; a major value to WINE to Corel should in permitting Win32 software to be recompiled using libwine so that they may be deployed as native Linux applications.

In contrast, the GraphOn Linux Client to Bridges software is not a tool to allow Windows software to run on Linux; it is merely a tool to allow Windows software to run on Windows NT, and then display on Linux.

The new Linux client runs Windows applications remotely

Essentially, this provides the same sort of functionality as the Citrix ICA protocol, or Microsoft's Hydra.

What is particularly distressing is that this supports the GraphOn Patent for Remoting Windows Applications. But that does not appear to have anything to do with WINE...

That's exactly what WINE does. And Quarterback Software used to sell a X11 program for Windows 3.1 which did the same thing.

Clearly you haven't looked at the Wine undocumented API stuff then. The wine developers have had to reverse engineer chunks of undocumented APIs that are used by things like MS Office and IE.

Well Corel is contributing extensively in the Wine project. Their contribution is valuable in both running other Windows-software on Linux and developing winelib for porting Windows software to Linux.

IMHO Wine is an important piece of software to help people to move away from Windows. Most have at least one critical app that they have to run on Windows. That's a major reason not to change OS. Wine can break that hinder and help Linux gain more users.

Programs that work with wine says, "In particular, 16-bit versions of Word, Excel and Quicken do work well enough with Wine for many purposes, although they are by no means flawless."

And this page is dated Quarter 2 1996 - so I imagine Quicken works a whole lot better now.
The official list of apps that work is at WineHQ
Joseph Elwell.

...formerly known as RA2Wav. There is a trial beta here.

Only problem is, it's Win32. Good thing is, RealPlayer G2 for Win32 runs on the latest CVS of WinE, so there's a good chance StreamRipper and its companion, PNM downloader X-FileGet, will run.

Keep an eye on these guys. The upcoming version of StreamRipper does RA to MP3, CD-ripping and other nifty things, and the upcoming version of StreamVCR handles G2 servers, RTSP and some MMS streams.

Hope this helps!

I asked him to elaborate on this compatibility thing, and he said "Well... I think... OpenBSD can run C++ programs." Instantly I lost all respect for him. I inquired further, and he said "yes, it can run Microsoft C++ programs, and the other BSD's can't."

Perhaps he had it backwards; OpenBSD is the BSD that concentrates on security, and, as for the Microsoft programs, the "About Wine" page on the Wine Web site mentions Linux, FreeBSD, and Solaris (presumably meaning Solaris x86) as platforms on which Wine can run Windows x86 binaries, but doesn't mention openBSD.

That may, of course, just be because they didn't mention it, not because Wine can't run on OpenBSD; the "emulators" section of the OpenBSD ports status page mentions Wine, so there may be a working port.

The major difference between MainWin and this being CygWin is open source.

No, the major difference between MainWin and Cygwin is that they go in opposite directions; MainWin provides a Win32 API atop UNIX-compatible OSes, while Cygwin provides a UNIX API atop Win32 OSes. If you want to contrast Cygwin to a non-open-source UNIX-apps-atop-Windows product, contrast it with Interix, and if you want to contrast MainWin with open-source Windows-apps-atop-UNIX software, contrast it with Wine or TWIN or Twine, say.

I can see the future now, within 5 years, every *nix will be able to run M$ apps, and every admin will have to explain her/himself to IT's why they aren't using on the company's servers.

Better keep a grip and use wine!
--

After reading the MainWin overview on MainSoft's site, it is obvious that it is just another Win32 emulation layer, similar to Wine for Linux or Wabi for Solaris. Of course, they state on their page that MainWin is not an emulator. But all it does is to translate Win32 API calls to something that runs under Linux. The calls are executed in the MainWin layer (thanks to the Windows source code that they can use) or translated to Linux system calls. By the way, MainWin is already available for many UNIX systems, and they are just adding Linux to their list.

How is this different from Wine? On the negative side, it is closed source and probably quite expensive. On the positive side, the fact that they have access to the Windows source code means that they might be more compatible with all the undocumented Win32 features that are used by some MS applications.

I don't think that there is anything really exciting about this announcement. Win32 emulators have existed for quite a while on various UNIX systems, and all of them have their drawbacks. This one might be better in some areas and worse in some others, but it will never replace a native port of the applications to Linux.

If MicroSoft (not MainSoft) starts publishing press releases encouraging developers to work only on Win32 because it is portable to all environments including Linux, then we may have something to respond to. But I don't think that any serious company would stop porting their products to Linux because some small company provides a (closed and expensive) emulation layer for Win32 apps.

It is interesting that they don't mention WINE as competition. Normally ZDNet not mentioning the Open Source product wouldn't surprise me, but this *is* a Linux article.

Wine (by my guesstimation) is looking at a similar time period to be stable enough to port sellable applications with. Corel must think so too, or Corel Office on Linux would be too far off to be worth doing this way (IMHO, of course))

To head off wasted posts quickly, please remember that WINE is *BOTH* a Win32 API implementation, AND a Windows emulator (The latter being a binary loader and interface to the former, of course)

isn't this what twin is doing? Have a look at all the wine-ish projects at http://www.winehq.com/others.html.

PS: The Wine site has a database for tested applications, but GoZilla wasn't listed, so I can't tell you what to expect.

For those of you who cannot hold your breath: Opera is WINEable.

//Mutende
--

You are right (but I knew this already :)
My statement was not based on running Wine but on having a look at this link:

http://www.winehq.com/source/graphics/d3ddevices.c

Particular this part:

1. /* Direct3D Device
2. (c) 1998 Lionel ULMER
3. This files contains all the D3D devices that Wine supports. For the moment
4. only the 'OpenGL' target is supported. */
5. #include
6. #include "config.h"
7. #include "windef.h"
8. #include "winerror.h"
9. #include "wine/obj_base.h"
10. #include "heap.h"
11. #include "ddraw.h"
12. #include "d3d.h"
13. #include "debugtools.h"
14. #include "d3d_private.h"
15. DEFAULT_DEBUG_CHANNEL(ddraw)
16. /* Define this variable if you have an unpatched Mesa 3.0 (patches are available
17. on Mesa's home page) or version 3.1b.
18. Version 3.1b2 should correct this bug */
19. #undef HAVE_BUGGY_MESAGL
20. #ifdef HAVE_MESAGL 1

My reason to find out what the Wine folks are doing is this one:

There is a new 3d API on the block, QDraw, that will be the foundation for a new 3d Web format (GEL). This API is crossplatform (NT and UNIX, I was able to run it under FreeBSD) and uses different backends, presently OpenGL and ASCII aalib (yes :-)

Now comes the funny bit. QDraw is from the original Direct3d guys - and while being much more cleaner (a nice C++ API, as far as I can see from the example sources) it is closer to Direct3d than OpenGL. So it might be easier to realize a Direct3d -> QDraw mapping, than the one to Mesa.

Although this isn't exactly "Freshmeat" there is a respository for Open Source Windows software. Okay, It's quite small now, but hopefully it'll get better. http://commit.winehq.com/~lynch/OSSW.html

You have checked out http://www.winehq.com haven't you?

AFAIAA Dosemu is much more finished than Wine, and should run any Dos programs you have fine (I think).

Now here's a good news/bad news situation. I already used my five moderator points today on another thread, which meant that I couldn't moderate up any of the JWZ posts on this topic. On the other hand, that means I can add my own amplifications on the topic of how much X sucks.

Another sucky thing about X is...is...

Oh, what's the point. I've been an X user for almost fifteen years now. And I'm one of the lucky ones: I've never had to program for it. Fifteen freaking years and I have finally almost got a desktop I actually like. And that's only because the GTk+ people did an end-run around X and I've got a desktop machine that would stomp any supercomputer from the 1985-ish era of the X design. So I have to say that X is quite lovely if you have the luxury of running it on hardware 32,000 times more powerful than it was designed for.

But then Zawinski writes:

But none of that matters. Why? Because it doesn't matter how much X sucks, because X is entrenched. It works badly, but it works well enough. It is the de-facto sub-standard. It cannot be replaced, or even fixed, without rewriting every single graphical application you have ever seen, and that's just not practical.

I feel your pain, but I'm not sure even I am as darkly pessimistic as this. I guess the claim is that replacing X would be too much work, but I think we have plenty of evidence that there are people out there for whom time and duplicated effort have very little meaning. As I write this, there are hundreds of programmers slaving away at the Wine Project in order that we might one day be able to run Microsoft Word in bug-for-bug compatibility mode. Zawinski has already pointed out the amount of wheel-spinning that has gone into the eleventy-seven different toolkits that you can run under X. Emacs now can have a built-in web browser (disclaimer: yes, I sometimes use it) and I personally know the guy who wrote its spreadsheet mode.

No, I think there's enough random energy around to write a completely new GUI for Unix and hack/slay/port all of the most useful applications to it. There are already two or three groups of people who are working on the next X itself.

I'm not sure all of this is the wisest use of one's time, of course, but there you go. Worse may usually be be better, but this cuts both ways. I remember when Linux was still in the .95 days and there was a serious question about how long Linux thing could go on before the *BSD people saved us all. It didn't happen that way for a variety of reasons, and *BSD was a far more likely candidate for world dominance in 1991 than X is in 1999.

King Babar

There are more than 1000 functions in the native API (ntoskrnl.exe + hal.dll are the modified microkernel). A minimum part is available to user mode via ntdll.dll. Unfortunately less than 10 per cent are documented by MS.

There is also a GPL'ed implementation of that microkernel: its name is ReactOS. It is planned a Win32 server on top of it and probably a POSIX+ one in the future. This project borrows some code from Wine. You can download the pre-alpha code (no GUI yet!) from www.reactos.com.

Thank you for playing.

see Wine/About
"Wine ...is freely redistributable. (The licensing terms are similar to BSD.)"

>...Wine to run x86/NT programs would be cool, >but I rather doubt Compaq would want to release >their FX!32 technology.

If the licencse is BSD-like they should not have to release it. :)

Posted by joakal:

Actually, there is a Linux port of StarCraft. As far as I know, it is not in any way sanctioned by Blizzard (grr, fools). If you search around the Linux gaming sites, you might come across it. Unfortunately, when I tried to access their web site, it was down and thus I forgot to bookmark it. :-) I'm not even sure if the project got off the ground.

At any rate, you could always try running it in Wine. I've never gotten that to work, but the error I get suggests that it's because of my Banshee video card.

Good luck!
=========================================== =========
Joakal
"In a world without walls and fences,

The Mozilla project does indeed include Composer. However, the need for a more powerful graphical editor in the same realm as Dreamweaver is great, IMHO. Composer could possibly be extended to provide such functionality, but its greatest strength in most cases is its simplicity... I'd hate to see that compromised. I'm assisting in the creation of the curriculum for a high-school-level class in Linux. Tentatively, one section of the class is on building Apache and managing a small Web presence. I'd like to couple the Web serving unit with a unit on Web design, but I'm in need of a design tool comparable to Dreamweaver, I believe. So, in essence, is anyone working on one? If I can't find a suitable application, I'd settle for running Dreamweaver within WINE. Has anyone experimented with this? The reports on WineHQ are a bit sketchy.

Yes!! I didn't know what kind of red should I drink with clams!! Perhaps you mean www.winehq.com?

This may sound obvious, but have you tried to run
the camera software under Wine?

Of course, even if this does work a native version
would be better

It's under a license they describe as "BSDish". Read it here.

If you haven't, check it out at WINE HQ It has a library called winelib which is basically a non-microsoft implementation of win32 app stuff. it also has a program loader which lets you run win32 apps under WINE in linux... Please note me on any discrepencies..

If you can't get Wine to compile, there are binaries available. Of course that isn't as much fun as compiling it yourself ;)