OSNews

Let me remember you that WINE is different from this (check the site). WINE is also a opensource reimplementation of windows core libraries & stuff. You may not like it, but I _like_ the idea of having a opensource win32 and Direct 3D implementation so I can use it as a sort of cross-platform toolkit ala QT.

I would rather run native apps.

Same here, there are already plenty of toolkits that can be used to make applications for the four main operating system families and companies would be better off using as much of those as they can from the very start. That way when another platform becomes a viable source of customers, the developers of a software product don't need to rely on emulation and translation layers or rewriting the applicatiom from scratch.

I'm rather disappointed that companies are moving towards much slower interpreted languages than simply using portable libraries that come without the sharp speed decrease. And don't anyone dare tell me that Java/MSIL/Etc... are just as fast as compiled languages, because I've tried most of those including Java and MSIL and they are much slower.

You may not like it, but I _like_ the idea of having a opensource win32 and Direct 3D implementation so I can use it as a sort of cross-platform toolkit ala QT.

Now, this is by far the most stupid reason possible.

You already have gtk, qt, wxWidgets and few others that are crossplatform. They already work. The only possible crossplatform libs are the ones not dominated by any OS. As soon as toolkit is being developed by one company and faked by another, there will never be a really good results with fake. Why do you think wine is not yet suitable as foundation after 10 years or more? Because they don't control the toolkit

Well, you might pose Google with Picassa for contra example, but remember that Google helps on wine (which means missing features are done by Google, until app works), and Picassa uses its own toolkit by the way.

And please, don't understand this as undermining projects like wine. Wine is good, but not in the way you said it.

Edited 2006-06-17 18:42

Actually wine is quite usable today. Just take a look at certain Google applications.

Since the release of the 0.9.x series of Wine, the situation has become quite different.

But I agree that using it as a crossplatform utility is suboptimal. There are better ways to ensure such a goal.

Actually wine is quite usable today. Just take a look at certain Google applications.

I noted them, and I noted why they can't be counted as in parents example.

Since the release of the 0.9.x series of Wine, the situation has become quite different.

But I agree that using it as a crossplatform utility is suboptimal. There are better ways to ensure such a goal.

Yes, I will put it in more cleaned up version now. Wine as tool for runing apps that WERE (nobody will write again Photoshop 6), rocks and is THE tool in my opinion. Problem is with apps that WILL BE. And parent wanted to go crossplatform with wine. MS is changing API like crazy, and I doubt wine has enough contributors to follow them. Meaning this toolkit will always be dominant on windows and merely/barely working on others (taken apps written with newer APIs in question). Already released apps (and older they are less trouble is with them) don't provide much trouble to wine, not yet or just released do.

Now if parent wants to use features on Vista or features from the time of 98 is what interests me. Ones will not be present for a long time, and one are more or less present already. But if he would think about 98 he wouldn't mention DirectX

Edited 2006-06-18 01:51

The Project Odin (http://odin.netlabs.org) hosted by OS/2 Netlabs has tried this approach since around 1998, converting win32 pe-exe files to native OS/2 lx-exe files.

This can work for some apps (I tried Winzip once and it did basically work) but it was not to be considered reliable.

Odin required you to convert or copy your Windows dll-files into OS/2 dll-files (and run these files through its emulation layer similar to Wine's) in order for it to work, however, this was not always easy to get working...

The basic approaches sound much the same so I would like to see what these guys can do that the Odin and Wine guys do not seem to have gotten to work respectively...

This was years ago. In early alpha stage they switched to a runtime loader. There is even now a project which enables you to use windows printer driver inside OS/2.

did you even read the article? How is this different except that this one translates then writes a new executable, instead of translating and directly executing?

The fundamental problem of the Win32 API exists in both methodologies.

Converting a PE structure with CODE and DATA sections to an Elf structure with CODE and DATA sections is an insignificant problem when compared to properly handling and returning the data that calls to CreateFile, CreateThreat, RegOpenKey and the like expect.

Now, where Alky may have some success is this: "We only currently care about high-end, modern gaming. "Normal" applications will come later." That reduces the number of APIs they need to initially implement significantly.

If this methodology is supplied to developers in the form of an SDK rather than to users in the form of a converter; I believe you might see games that work on linux and OS X. The SDK concept requires game developers to code within the constraints of what Alky has implemented and means more chances of interoperability.

From a user supplied tool perspective; I would expect to see roughly equivalent success if not slightly more to the WinE project at running "high end games" simply because it is so very difficult predict what functionality a game will use/require.

Eerrr nevermind.

Edited 2006-06-17 18:59

> I often am upset when trying to use cedega, the
> performance of the on-the-fly interpretation of windows
> code is sad.

The description on the site doesn't sound like Alky does it different. They only link the on-the-fly translation into the executable, so you can distribute it as a standalone Linux/Mac executable. Actually, since they convert binary executables without manual intervention, I don't think anything but on-the-fly translation is possible.

Yes, a message box and a crash dialog.
http://alkyproject.com/wiki/index.php/Progress

But since this project is only one week old I didn't expect it to run Halflife2 native.

Thank you, I must have missed the screen shots in the wiki. Understandable about the HL2. But now I see the proof of concept. Here's to hoping they get it coded and implemented completely.

I hope this will get a GPL license model so everyone can have the experience.

Read the webpage. It clearly states, under a seperate header no less, it is licensed under the LGPL.

I wonder if any sharing of code with Wine will occur? It sounds like some of it might be useful.

EDIT: And after poking around the wiki a bit, it looks like they will need it. 6 kernel32 function implemented? 1 comctl32 function? I hope that those pages are merely way out of date.

Edited 2006-06-17 21:56

Which game demos are they? if so i guess we can download them somewhere, afterall once they're converted there's no need to us to convert them again, they're done.

The impressive results Alky is capable of so far apparantly amount to the following: http://alkyproject.com/wiki/index.php/Progress

You say it's

"Opensource, go download and check it out."

is it that simple? can we do this easily or would we have to do a lot of coding ourselves once checked out of SVN or buy a mac for it to work?

Why do Mac users get so hung up on this look and feel thing?

These will be converted Windows programs (mostly games at first anyway) and they should ACT like Windows programs. Their task at hand is difficult enough without trying to fake the Mac way of doing things. Granted, eventually it could be possible, but that certainly shouldn't be their focus.

Why do Mac users get so hung up on this look and feel thing?

In the same way GNOME and KDE users are hung up on look and feel? If it feels foreign, it usually behaves foreign (keyboard short cuts not working, etc).