“Alky is a tool that allows you to convert a Windows executable to a Mac OS X or Linux binary. We are focused on high-end gaming at the moment, though we will support other applications in the future. Our binary translation layer is already working fully for OS X and Linux support is in progress. Of course, Windows applications use a very different set of libraries from Linux or OS X applications so we are also working on a library called LibAlky that will provide those Windows libraries to the application.” One of the project’s members is Cody Brocious, one of the developers behind PyMusique.
lets see if they can do well, what the WINE project cant seem to get right.
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. I hope they can pull it off.
> 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.
I like the concept and idea behind this. I went to the site and read up on it but didn’t have much in the way of seeing it in action. Is it possible to provide a screen shot or a a small flash animation/video of a Windows executable on Mac OS X? Just a proof of concept is probably what I’m looking for. Best of luck to this project, it may be just the boost other OS’s are looking for.
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.
Seems nice, good idea, but I can’t really comment on the technical aspects of this.
Anyone?
And, btw, has anyone already tested it?
Normally I’m quite sceptical of things like this (and hence don’t mention it on OSNews), but seeing Cody Brocious’s name below the website gives it credibility.
If they can pull this off, this would be a very BIG development. Correct me, if I’m wrong, but wouldn’t you need access to a lot of proprietary libraries to get this to work? Or are they going to pull the libs that are aready on an app’s disc? For gaming, are they going to convert Direct X libraries as well? Also, wondering what the legal ramifications of this to your basic software licence. Like I said, it would be neat if they pull this off, but then I had similar hopes with WINE.
I hope this will get a GPL license model so everyone can have the experience.
When this promising project doesn’t reveal itself as an paper tiger eventually ofcourse.
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
Correct me if I am wrong, but what Alky does is to convert the executable to the Linux ABI and then staticaly link the missing windows functions into the executable.
While doing static linking instead of dynamicaly linking the whole WineLib does have some benefits I doubt that there will be a significant perfomance differentce.
And why reinvent the wheel by reimplementing the missing functions instead of fetching them from Wine?
I heard various times this binary translation idea and never materialized, always the time showed that was a joke.Any different now? only time will tell
Just like so many other projects that have passed through here, proof will be in the pudding. Until some code or some “undeniable” proof of concept is released, they will get nuthing but skepticism…so whatever they do, they should do very carefully because it will be scrutinized to the nth degree. If it actually does work, they wow good stuff…i thought Enomalism was vaoprware until i cheked the site the other day and there was a beta download available? have yet to try it out, has anyone else? Enomalism (www.enomalism.com)
Cody already has Oblivion converting and trying to start, I believe right now it shows a dialog saying D3D initialization failed (because that’s not done yet). Last I heard he was going through some DirectX demos and making them work.
—
Travis Watkins
Way to hack dudes!
First, its a manual conversion because of the librarys needed, so it should be much faster than wine. Reports are that DirectX demos are already converted.
And NT for Alpha had a program that did this, but they had the librarys, this is the part that hangs people up.
Opensource, go download and check it out.
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?
The main idea is to make games work and this actually makes it a lot easier to implement. Games tend to use DirectX and not much else so we don’t have to worry about all the random APIs and their bugs like WINE does. About the only regular APIs that would need to be supported would be those used by the Windows Installer (so you can actually install games to play them).
is this a repeat or am I getting it mixed up with some of the other tech news sites? Anyway the project is a nice idea only for a task like this you either have to be a very very productive programmer or have a large enough group of people working on it. Unfortunately I don’t think that either one is the case here. Props for the effort though.
Now we need some benchmarks comparing Wine with Alky project. This will decide which is the better of the two.
On the other hand, since both are (L)GPLed it may not matter really which is the better one. They will both complement each other…
I think they might be onto something if they use Wine’s progress. They want to focus on DX and other APIs used by games but there are parts of the games that rely on normal Win32, for example configuration and installation. If this project survives the first years of development (which I doubt…) it could be a major success. Then again they could be just a bunch of gamers with no idea what they’re trying to do.
interesting … Ill try to watch their progress 2 c what it is .
As far as my very limited knowledge tells me this project creates enough hooks for Windows games to run while WINE fully implements the whole OS .
Combine the 2 should be certainly interesting .
(Just in case): Flaming me for lack of knowledge is stupid because I’m not saying I know what I’m talking about .
AFAIK WINE does not interpret .
Any slowness will be due to unresolved issues etc – these speed tests of WINE v XP show that WINE can shine .
Again I get this feeling of quiet WINE bashing because they are reimplementing Windows for UNIX which of course might be considered evil.
Yes native apps would be best but IMO WINE is still an incredible achievement.
Hmm. I dont use Wine anymore because these days there is a ton of good linux applications but I used it like 5 years ago to run mIRC and it worked perfectly.
Back then, it required some dlls from Windows, but I think you can use Wine alone now.
i hope programs looks and behaves like mac programs
Edited 2006-06-18 09:30
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).
Actualy this can be done, but this is serious hacking… crazy as hell. I think this could rock the whole world if it ever get to work…
Still it represent a lot of debuging and disassembling. Imagine tracing value in some apps that you don’t even have the code. This will be a severe pain in their arse. Still, this could be very interesting for some video game company who could write portable game for very cheap and to many other plateform, not only Mac OS X and Linux. Imagine the transformation layer could be done for a GameCube or a Xbox. I guest those guys could get a lot of help from majors if they get the attention.
Edited 2006-06-19 13:40
I hope so, I may download PC-BSD once I get broadband. We are still in the internet middle ages, 56k sure does suck. Just picture it one click install like windows, plus the ability to convert windows apps. Sounds great to me.
The irony is that my developer friends tell me that the Mac has MUCH better developer tools (OPENSTEP) than Windows. So, instead of learning that, people seek to translate legacy stuff written in MSFT’s legacy environment.
Still, it makes sense, because there are plenty of old Windows games sitting on shelves at CompUSA.