digg

Join DiggAbout

Discover and share the best of the web!
Learn more about Digg by taking the tour.

Converting Windows executables to Mac OS X or Linux binaries

alkyproject.com — Cody Brocious (PyMusique) is working on a new project to convert Windows executables to native Mac OS X or Linux binaries. He is focusing on high-end gaming at the moment, though he plans to support other apps in the future. On his blog, he said: "My goal for the next 5 years is simple: Any piece of software, any platform you choose."

Bury
show profanity settings
expand all
  • geminitojanus, on 10/12/2007, -5/+64What they're describing is really just a redesign of Wine; instead of having the source code for the program and manually linking against WineLibs (for porting a Win32 program to Linux, for example), this system simply forcefully relinks an already built application to their library (LibAlky).

    What they forgot to mention is that you can already DO this with Wine, and with Wine approacing 1.0, virtually an entire copy of Win32 is available and at your disposal. What this project should do is focus their relinker on WineLibs instead of once again reinventing the whole API, which would increase the performance of Wine on some applications (because the Wine server won't have to run to dynamically translate function calls).
    • mbthompson, on 10/12/2007, -39/+8Forgive me if I'm wrong, but Wine is only Linux, not OS X, so really there is a difference in what he is trying to do.
    • dclowd9901, on 10/12/2007, -47/+6There's also that whole Boot Camp thing that will soon render the whole emulation thing, you know, obsolete.
    • deepsub, on 10/12/2007, -2/+26http://darwine.opendarwin.org/
    • dobesov, on 10/12/2007, -13/+33Wait! wait... what if you ran a copy of XP through this theoretical program... Then you could run windows, but still feel good that you are running linux! ...Its a joke, dont kill me...
    • shuffle, on 10/12/2007, -1/+42Bootcamp does not render emulation obsolete... I'd love to be able to run Windows binaries along side my mac stuff - you know, in the same environment, accessing the same data - without rebooting into a whole seperate OS.
    • merreborn, on 10/12/2007, -3/+35This is a really nutty and difficult idea. There are a bunch of trouble spots:

      1) Calls to propreitary hardware and instruction sets. Altivec on the mac, BIOS on the PC.
      2) Calls to OS libraries. This guy seriously thinks he can take an arbitrary OS call, and translate it into calls for two other completely different OSes? Their APIs are completely different, and full of quirks. And what about things that rely on special OS services? Those services obviously won't be running on a mac or linux box.
      3) Drivers drivers drivers.

      Is it theoretically possible? Yeah. Is it really, really, really hard? Hell yes.
    • shakin, on 10/12/2007, -2/+17Boot Camp is nothing more than a wizard to guide newbies through the steps to setup a dual boot computer, which Linux users have been doing for more than 15 years.

      Alky will be a winner if it works. I'm skeptical that it will be more successful than Wine.
    • Ilyanep, on 10/12/2007, -2/+7"Is it theoretically possible? Yeah. Is it really, really, really hard? Hell yes."

      Yeah but imagine how much money this guy could make later with a "premium version" or tech support or something.
    • cius, on 10/12/2007, -6/+11"Is it theoretically possible? Yeah. Is it really, really, really hard? Hell yes."

      The question is, is it NP-complete? Even if it were, that wouldn't make it not worth pursuing. Ever tried to find an algorithm to give the minimum dominating set of an arbitrary graph? That's NP-complete. The difficulty of finding a solution to any hard problem is offset by the value of its solution. If I could spend a day or so alkylizing Steam and Counter Strike Source in order to play it full speed under Ubuntu, I'd do it. So, if his project can make this possible, I say its worth it.

      Also, maybe I understood this wrong, but some people seem to compare this to Wine and he clearly explains the differences. If I understand Wine properly, it implements the NT 4.0 libraries and dynamically translates calls to them into *nix calls at runtime. The original Win32 binary is untouched. What this guy is going to do, is actually create a new *nix binary that implements the exact same functionality as the win32 binary. His alkylib implements only those specialty system calls that aren't available on *nix systems. So he's not trying to dynamically link to new calls or translating at runtime, he's actually translating the entire binary at once into a functionally identical binary. Once that binary is translated, its *nix native, or OS native more precisely.
    • lpcustom, on 10/12/2007, -5/+3@cuis

      Yeah he thinks he's going to convert a windows binary to a linux native binary. Is he going to use magic?
      Maybe he should start off with something a little lighter. Convert a dos executable over to a linux executable. It's not hard if you have the source, but how easy is it without the source?
    • daeken, on 10/12/2007, -1/+11@lpcustom:

      Our conversion layer is already 100% done for OS X, and getting there for Linux. All (as if that's small...) that needs to be done now is implementing the Win32 APIs.

      So why again is this not possible?
      (Not saying it's practical, just possible)
    • mastercheif, on 10/12/2007, -3/+2 Im shocked nobody has mentioned parallels yet.
    • illt, on 10/12/2007, -4/+2merreborn: Altivec on the mac? this wouldn't work on powerpc's anyway without emulation.....
    • rasterbator, on 10/12/2007, -2/+6Couldn't someone just run a virus-infected executable, convert it to Mac OS X or Linux and start a widespread outbreak of a computer virus?
    • stoanhart, on 10/12/2007, -0/+4@daeken

      Is that all, huh? Well then I can definately see how you are not doing the same things as the WINE team then...

      @cius

      "If I understand Wine properly, it implements the NT 4.0 libraries and dynamically translates calls to them into *nix calls at runtime. The original Win32 binary is untouched. What this guy is going to do, is actually create a new *nix binary that implements the exact same functionality as the win32 binary."

      They are both doing the same thing. Wine implements the win32 API, so that the windows EXE can call functions with the same functionality as the win32 binaries (at the same or even better speed, if the calls are written well). That is also what alkylib does. The first poster had it right - they should just focus on using their binary conversion algorithm with the winelibs, rather than redoing all of the WINE team's work.

      The only difference between this and wine is that wine uses the wine server, which really doesn't add much overhead, since it is really just a box around the windows EXE, made to look like windows on the inside. When a program makes a system call, the wine server calls the appropriate function from the winelibs, which are natively implemented. There is very, very little overhead in running the wine server.

      I think this is a cool project - being able to run an application on any OS without extra software would be cool, I just think it's a wast of time to re-implement the win32 API again. Like daeken said, "All we have to do now is implement the win32 API". That is no small task, and is exactly what wine is doing.

  • plue2, on 10/12/2007, -6/+37Why's he talking about this five year plan? Is this some communist trickery!?
    • RyeBrye, on 10/12/2007, -4/+36In 5 years you will have forgotten about it. Kind of like how 10 years ago we were going to have fiber optic going to our houses in 10 years.
    • RadiantBeing, on 10/12/2007, -9/+14It's like commercial fusion power, the technology that is forever 20 years away. But fiber did roll out in my neighborhood last month so maybe there's some hope.
    • MattyLite, on 10/12/2007, -18/+8I have a fiber optic internet connection in my house . . . ?
    • dobesov, on 10/12/2007, -3/+4yeah five years? what ever happened to the guys at transitive?

      http://www.transitive.com/technology.htm

      I think they use QuickTransit in rosetta... but that could be inaccurate.

      anyway... I guess you would still have to emulate the API calls or translate them too...
    • merreborn, on 10/12/2007, -7/+5RyeBrye:

      Bad example. Verizon is offering fiber to the home in select areas. There was a trial a block from my parents' home 5 years ago.

      http://www22.verizon.com/FiosForHome/channels/Fios/HighSpeedInternetForHome.asp
    • lane.montgomery, on 10/12/2007, -2/+4It's probably 5 years away because that's the perpetual prediction of when Linux on the desktop will finally go mainstream. Thus, at the same time you will be able to run your windows programs without knowing the difference.
    • RyeBrye, on 10/12/2007, -0/+9I guess the other reason he is saying in 5 years is because he is going to use Duke Nukem Forever as the first app that he demonstrates translating?
  • anewname, on 10/12/2007, -14/+8I wouldn't be surprised if Jobs wanted to do this himself in future versions of OSX, but on his own terms.
  • pgquiles, on 10/12/2007, -6/+9This is not new. The OS/2 Netlabs people did this years ago for OS/2 and it's called Project Odin: http://odin.netlabs.org/
    • ahhell, on 10/12/2007, -0/+6Oh yeah? How did that work out for them?
    • crunk, on 10/12/2007, -0/+1Odin is a port of wine so I'm sure it works quite well (probably better win32 support than the winos2 stuff already there!)
  • Jakelshark, on 10/12/2007, -6/+6But he goes to such lengths to show it isnt Wine...FOUR WAYS....count them, one, two, tres, four!

    But yeah, this is going to take a long time to get anything working right in my opinion, by which I mean anything worth using. I dont care if they can convert MS Office or anything...I just wanna see some gaming action, and by the complexity of games today that will be a long time...
  • strictnein, on 10/12/2007, -2/+12Interesting idea... but doesn't the future seem to trending more towards virtualization? Microsoft, among others, is throwing billions of dollars at the idea.
    • JohntB, on 10/12/2007, -4/+5Yeah, but then you have the overhead and expense of running a copy of Windows on your computer at the same time you're running linux or OS X on it.
    • merreborn, on 10/12/2007, -2/+3"Yeah, but then you have the overhead and expense of running a copy of Windows"

      That's probably unavoidable -- applications make calls to native drivers, OS services, and the OS API. Those things pretty much have to be present one way or another.
    • BobbyOnions, on 10/12/2007, -0/+0> That's probably unavoidable -- applications make calls to native drivers
      > OS services, and the OS API. Those things pretty much have to be present one way or another.

      I think you're missing the point, but it is a tough point to grasp when you're familiar with WINE et. al.

      The application will have been translated to run natively on another operating system at the binary level - rather like you rewriting a Perl script in Python where would replace "sub foo { }" with "def foo" etc. - once and once only.

      Native O/S calls don't have to be present, they will be substituted with the host environment's implementation.
  • safer9999, on 10/12/2007, -12/+8How do you spell VAPORWARE"

    Neal Saferstein
    • daeken, on 10/12/2007, -9/+13It's an open-source project which you're more than welcome to help out with if you don't like the way you believe it's being developed.
    • keeperofkeys, on 10/12/2007, -0/+11well, I'm English, so I'd put a 'U' in there
    • coffeepoet, on 10/12/2007, -1/+1and an extra 'e' at the end so. . . Vapourwaree?
    • neko, on 10/12/2007, -1/+1Vapour? where?
    • loginssuck, on 10/12/2007, -6/+0@AmericaFirst

      But, but, but... Duke Nukem Forever is coming out in a few months now!!!! THey said so!!!!!!1111!!!!! LOL!!!!!1111!!! ROTFL!!!!!!!11111ELEVENTY!!!!!!
    • rdoger6424, on 10/12/2007, -0/+1it's spelled d-u-k-e n-u-k-e-m f-o-r-e-v-e-r
  • lpcustom, on 10/12/2007, -11/+7This isn't a goal. It's a dream. A lot of people have already had this dream.
    • aoe2bug, on 10/12/2007, -4/+13Atleast this guys making an effort. Jeez way to be a pessimist.
    • lpcustom, on 10/12/2007, -9/+3You obviously don't realize the effort he would have to put out to do this and neither does he. Like "justice7" says below...If this could be done it would have been been done by now. This isn't being pessimistic. I can put up a website saying that's what I'm going to do as well. That doesn't mean anything. This type of project is no where near as easy as he thinks. Wine has been in existence well over 5 years....do you see it coming close to what this guy is proposing? NO....You know why...it's not because of lack of effort...it's because it's not this straight forward or simple. It's a very complex task to try to achieve. Kudos to him if he makes any headway in it. By the time he's actually able to achieve his "goal" though we'll probably all be using something totally different.
    • daeken, on 10/12/2007, -0/+17lpcustom:

      I'm the Cody Brocious mentioned in the article, and I think the one thing you're missing is that we're focused on games, not general applications. (Not that we won't support normal applications in the future, as they do play into my goal for the next 5 years.) Games use a very, very small subset of API calls, unlike general applications. Although I believe that with the way development on Alky is done that we can meet the goal of having damn near every application working within 5 years, I don't kid myself as to the work involved. It is a huge undertaking, and I'm fine with that. Something needs to drive change.
    • lane.montgomery, on 10/12/2007, -1/+7Ipcustom, your logic is flawless, oh wait...

      "If it could be done, it probably would have been done by now."

      Do I really need to explain to anyone why this statement is wrong?
    • lpcustom, on 10/12/2007, -2/+2@Cody Brocious
      Why not devote your effort at Cedega instead of trying to do it yourself? I commend you for the effort but that doesn't mean you'll be able to do this. Cedega will already run a lot of Windows games in Linux. Why don't you spend your time contributing to a project that is already halfway there.

      From what I gather you want to convert a binary executable over to Linux and Mac format. Now if you were writing software to compile source to all three OS's that would be doable but converting binary executables and expecting it to work flawlessly. The available libraries are different on each system. The filesystem structure is different. The API's are different. Not even mentioning that game makers each do things differently. I mean when Windows XP first came out there were quite a few Windows games that wouldn't even run on it. I still can't get FF7 to run on it. The technologies involved change faster than you can code for it.
    • aoe2bug, on 10/12/2007, -2/+3"You obviously don't realize the effort he would have to put out to do this"

      You obviously don't have much faith in your fellow digger. Just because i said you were a pessimist doesn't mean I don't acknowledge the huge amount of work something like this is.

      "If this could be done it would have been been done by now. This isn't being pessimistic."

      This has got to be the stupidest thing I've ever heard. We, as a human race, are not "done" yet; therefor we still have things to do. Therefor not everything accomplishable is done. Even if this is too difficult to do "in today's world", even if you are "right", it could still be done "at some indefinite point in the future." I'm sorry if I've insulted you, but your statement is inherently false.

      "I can put up a website saying that's what I'm going to do as well. That doesn't mean anything. This type of project is no where near as easy as he thinks. "

      How easy do you think he thinks it is? Just because he is willing to do something doesn't mean he doesn't know the task ahead of him.

      "Wine has been in existence well over 5 years....do you see it coming close to what this guy is proposing? NO....You know why...it's not because of lack of effort...it's because it's not this straight forward or simple. It's a very complex task to try to achieve."

      True, but again; more effort toward the goal of interoperability is a good thing. Even if one could argue that he's reinventing the wheel; new effort is never a bad thing.

      "Kudos to him if he makes any headway in it. "

      Yep.

      "By the time he's actually able to achieve his "goal" though we'll probably all be using something totally different."

      That's entirely possible.. Then we could emulate osx on that and then... :)
    • SyvanX, on 10/12/2007, -1/+3"If it could be done, it probably would have been done by now."

      Tell that to Charles H. Duell, director of the US Patent Office in 1899. He said - "Everything that can be invented has been invented
    • lpcustom, on 10/12/2007, -4/+1@lane.montgomery
      Let me explain where this statement is right. If time travel were possible...someone from the future would have already came back in time to show us how it's done. Has this happened? No. Is it possible. Probably so. So why don't you waste your life trying to figure out how to time travel.
    • aoe2bug, on 10/12/2007, -2/+2"If time travel were possible...someone from the future would have already came back in time to show us how it's done."

      Now why would you think they would do that. I imagine strict laws preventing the alteration of the past. (though admit-ably difficult to enforce)
    • Bradl3y, on 10/12/2007, -2/+2"If time travel were possible...someone from the future would have already came back in time to show us how it's done."

      Say time travel was possible right now, how far would you go back to show people how it was done? Maybe nobody from the future has came back this far yet?

      Also, what if you could not travel to a time before the time travel technology was invented? Then they couldn't come back and tell us.
    • lpcustom, on 10/12/2007, -0/+3@aoe2bug
      Its great that you spent that much time replying to my post. I think a lot of you are missing the point though. I know we haven't done everything that we can. If you think we can do anything we want you are completely wrong though. The truth in this case is that the computer industry has been booming since 1980. Back in the early days there were a ton of different architectures and OS's. Now we have more standards. These standards don't really apply to OS's though. They all have the same job but they perform this job completely different.

      Its not impossible that someday one game will play on all different systems flawlessly. That objective however is highly unlikely. You won't have some magical converter that will make a windows binary into a linux binary. If this happens at all it'll be from standards placed on game and OS developers to make all their software compatible. There are way more intricacies to all of this that most of you are missing.
    • tforcram, on 10/12/2007, -2/+0Yea, and everybody told (pick your favorite historical figure) that ____ was (impossible/ he would die trying/make up your own), but somehow ____ still came about. So how about that all you pessimistic diggers!
  • zetsurin, on 10/12/2007, -0/+3I've previously used wxWidgets for my cross platform projects. It works a treat except for the fact that it's difficult to make a Mac app LOOK like a mac app this way. And to compound that, Mac users are particularly anal about that kind of thing (which I think is understandable as a 'most of the time' Mac user myself). I've been really trying to like Objective-C in order to do things that way with Cocoa, but [self dontLikeIt:AtAll]...
    • zephc, on 10/12/2007, -1/+3Long method names in Cocoa are sometimes in a pain in the ass, but they lend themselves well to goin onto mutliple line e.g.
      result = [myObj copyFile: file
                      fromDirectory: dir1
                          toDirectory:dir2];
    • lightningrod220, on 10/12/2007, -1/+1I love Cocoa, because it's clean and easy to understand, usually. The thing that I hate, however, is the manual retain/release of objects. I forget to do that on a single object, or release it in the wrong place, and KKKKKBOOOM!!! This is my perspective after about a year of using it, of course. Ask me what I think in 20 years ;)
    • geminitojanus, on 10/12/2007, -0/+1"I've previously used wxWidgets for my cross platform projects. It works a treat except for the fact that it's difficult to make a Mac app LOOK like a mac app this way. And to compound that, Mac users are particularly anal about that kind of thing (which I think is understandable as a 'most of the time' Mac user myself). I've been really trying to like Objective-C in order to do things that way with Cocoa, but [self dontLikeIt:AtAll]..."

      Hell, even Apple doesn't use Cocoa for everything. Just use it when you need it and you'll be fine.

      Besides, Obj-C is actually a very elegant language, and more object oriented than C++ or Java could ever dream to be. If you're an OO programmer, you should really learn to embrace it, as it really is one of the best tools out there (I've been using it for years, though the Cocoa API is new to me). But of course, if you really, really don't like it... (and shhh.. let's keep it on the D/L, because some people will curse at me for saying it..) you don't /have/ to use it you know. Apple still maintains the C API called Carbon that is at least as powerful as Cocoa if not more powerful (if I remember correctly, Cocoa is actually implemented /over/ Carbon).
  • justice7, on 10/12/2007, -17/+3lets put it this way

    if it could be done, it would be by now. What could be done, has already been done (Wine/Cedega)
    • binaryloop, on 10/12/2007, -1/+16by that line of reasoning... if humans were meant to fly we'd have been born with wings.
    • barbobot, on 10/12/2007, -1/+12If it could be done , it would be done? burn those witches at the stake!
      Seriously whenever I hear someone say this my brain implodes and Einstein cries.
    • jmuchrisf, on 10/12/2007, -9/+1i like burnt steak.
      oh wait.. no... rare steak.
      burnt stakes.
    • barbobot, on 10/12/2007, -8/+2haha whoops, it's early give a guy a break.

      /eat steak
      //eat steak
      ///eat a big ol steer
    • lpcustom, on 10/12/2007, -3/+3"by that line of reasoning... if humans were meant to fly we'd have been born with wings."

      A more accurate analogy would be humans trying to fly without aircraft and naked. Try it. No matter how much effort you put into it...it just can't be done. This isn't about "thinking outside the box". This about copyrights and closed source software. Mine you I didn't say it was impossible. It's just infinitely impossible. Many have tried already.

      Look how many people have jumped from tall objects and died. Do they get points from you for trying to fly?
  • Jakelshark, on 10/12/2007, -1/+10Heres the CVS of the code, http://alkyproject.com/svn/alkyproject/trunk/

    looks like hes busy working on the kernel and a few other small things, and thats about all the progress done
    • lpcustom, on 10/12/2007, -0/+3This guy links to the SVN page so you can actually look where the project is at and you digg him down????
      Digg amazes me
  • themulf, on 10/12/2007, -9/+6Yeah... but does it run linux?
  • Dotnetsky, on 10/12/2007, -7/+2Let me know when I can run SQL Server 2005 on it. Yawn.
  • pokeme444, on 10/12/2007, -1/+2As far as virtualization goes - there's already an open-source project on the way focusing on that, with a goal of "any platform on any platform." Right now we're mostly focusing on vintage platforms - things that run CDP/M, old home consoles, etc - but we're also laying down a robust and useful infrastructure for development of more complex virtualizers.

    In the future, we're going to do dynamic recompilation (like rosetta) on any platform, using an intermediate bytecode.

    Check us out:

    http://sourceforge.net/projects/openem

    Unfortunately, the only way to really check it out is through the SVN repository at the moment, as no releases have been made.
  • comradechimp, on 10/12/2007, -1/+2Does this mean I'll finally be able to run Progress Quest on my Linux box?
  • ThirdPrize, on 10/12/2007, -0/+3Nice idea but not a hope in hell of getting it working. OS2 used to do something like this but they had to rewrite the Windows 3.11 API in a non copyright infringing way. Add to that the various undocumented functions that exist in Windows.
  • khyberkitsune, on 10/12/2007, -1/+11This is to the programmer of this application.

    Games DO NOT USE A SMALL SUBSET OF API CALLS. At least, that's in the Windows world. If games only used a small subset of API calls, it'd be a very limited game. First off, about 98% of the DirectX API is used for even a game as 'simple' (as it could be called compared to today's games) as Quake 2. Next, you've gotta run all that through the OS if you use Direct3D for your hardware acceleration, which involves even more API calls. If you use OpenGL, then you've gotta run it through it's specific set of calls and hooks.

    'Normal' apps use FAR less API hooks and calls than games (with the odd exception for the occasional video chat program, like Camfrog, or other programs that constantly encrypt stuff, like Skype.)
    • lpcustom, on 10/12/2007, -1/+7They'll just digg you down for telling them the truth khyberkitsune. I've been arguing with em for about an hour now.

      Look people...If I make a website and say I'm building a car that'll fly to the moon at 28000 mph and gets 2000 mpg. Would you tell me I'm crazy and it can't be done or would you say you want to help?

      Cause I believe my magic car is more possible than what Cody thinks he can do.
    • Teiman, on 10/12/2007, -0/+1Quake 2 source code is based on around 35 files, and 3 files are OS dependant: sound, creating a window, capturing keycodes, etc. On these 3 files, theres very few API calls, maybe 4 or more.
      All game engines that release a Linux version where developped that way: a common base OS agnostic, and a few OS based files.
      But only a few engines where written that way. So you have some engines that work on linux and a few engines that dont work, or work poorly on wine, or not work at all.
      Games that dont work at all on Wine often use undocummented features or are poorly coded.
      Because If you write a multiplayer game, you want to able to run the dedicated server on Linux, you code multiplayer games with the agnostic OS core. So future games will have a Linux client, and a linux dedicated server, future games will run on Wine.

      I think another approach its good, because experimentalism can get new stuff, and Is fun. But I bet on Wine. All my money is on teh Wine bank because its the better approach to run Windows games on Linux. A polised enough Wine will run all windows games, except a few broken ones.

  • Sheco, on 10/12/2007, -4/+3that's unpossible
  • HappyScrappy, on 10/12/2007, -7/+1n00b.
  • xst4t1kx, on 10/12/2007, -2/+2Interesting project and interesting statement: "Yes! Alky was released under the LGPL license." I wasn't able to locate any files/source, correct me if you know. How can it be "released" under the LGPL when no files have been made available to the public? You can't have a release without a release.
  • plarp, on 10/12/2007, -8/+7HE DOES NOT UNDERSTAND THE WINE PROJECT, AND HE DOES NOT UNDERSTAND HOW BINARIES WORK THIS PROJECT IS LAME... sorry to yell but this got tooo many digs..
    • daeken, on 10/12/2007, -1/+6How do you figure that I don't understand how wine or binaries work?

      I've worked with wine quite a bit, and I wrote an entire binary translation layer from Windows PE to Mac's Mach-O. I think you're mistaken.
    • Grimboy, on 10/12/2007, -3/+4Due to the situatation I will forgive your annoying caps +3 diggs for you. No digg for this.
    • khyberkitsune, on 10/12/2007, -1/+0Translating from Windows PE to Mach-O != Windows XP to OSX/Preferred Flavor of Linux. Were this the case, we'd most likely have had this technology by now. As it stands, it'll be far easier to obtain now, since the three major OS (Win/OSX/*nix) now all run on one common hardware architecture. It'll be just far easier to port the game source instead of making what amounts to a wrapper or API replacement.
  • jron, on 10/12/2007, -3/+3uhhh yeah... not to mention 99% of all retail games are packed and encrypted binaries. To convert these games the way he proposes, he would first have to reverse engineer every game, just like cracking groups have to do... GOOD LUCK aka don't waste your time with this silly idea.
    • daeken, on 10/12/2007, -1/+5No we don't. We simply copy the segments from their files as they are into the Mac/Linux binary. This requires no reverse-engineering whatsoever.
    • Grimboy, on 10/12/2007, -2/+1I think you mean i.e. not "aka".
    • fatdog789, on 10/12/2007, -1/+1@daeken

      Methinks you misunderstand many things.
      1) Encrypted executables cannot just be ported over to Mac/Linux line you suggest. They are actually run through a self-contained virtual machine that decrypts the executable at runtime.
      2) IP laws. This is a violation of copyright and patent laws. The first time this is used on commercial software, the company that makes that software is going to shut you down.
      3) There are thousands of Windows API functions in each version of Windows. There are hundreds of undocumented functions in each version. These numbers don't include proprietary functions. Many of these functions *have no analogue* in Mac or Linux.
      4) This project sounds like a dissembler. You take a compiled binary, dissemble it, and recompile it into something useable on the target OS.
    • daeken, on 10/12/2007, -1/+5You misunderstand as well, fatdog. If you simply move those encrypted segments over in the binary file formats, their encryption code stays identical.

      You don't need to touch their encryption whatsoever.

      (This is coming from the person who developed the system, as well as an experienced reverse-engineer who deals with packed binaries daily)

      As for disassembling, that's not the case at all. We literally read the segments out of the windows PE file and write them in byte-for-byte into the mach-o file. The only difference is we also link in a replacement main function to set up imports. You can read the source for how this is done in the SVN repository.
    • geminitojanus, on 10/12/2007, -1/+5"1) Encrypted executables cannot just be ported over to Mac/Linux line you suggest. They are actually run through a self-contained virtual machine that decrypts the executable at runtime."

      Sure. So answer me this, how does the self-contained virtual machine get into memory? Oh, that's right. It's just an ordinary application. That ordinary application can be translated and ran just like any other application.

      "2) IP laws. This is a violation of copyright and patent laws. The first time this is used on commercial software, the company that makes that software is going to shut you down."

      Why? You've done nothing to touch the encryption, nor the program itself.

      "3) There are thousands of Windows API functions in each version of Windows. There are hundreds of undocumented functions in each version. These numbers don't include proprietary functions. Many of these functions *have no analogue* in Mac or Linux."

      They have an analog in Wine, which reimplements them. LibWine is actually _exactly_ the same thing as LibAlky that this project would use, and does the exact same thing. And Wine is able to act as any version of Windows from Windows 2000 to Windows 1. So yes, it is a HUGE body of code that one person could never implement in his or her own lifetime. But then again, why reimplement when a team of over a thousand have already done it for you? Wine is OS too, and could very easily make use of Alky's front end tools.

      "4) This project sounds like a dissembler. You take a compiled binary, dissemble it, and recompile it into something useable on the target OS."

      Disassembly implies that you're taking the application and turning it into source code. This project does none of that witchery, which is actually even MORE complicated. This program simply rewrites the Windows application (which is in a binary format called PE) into a Linux program (which has a binary format called ELF) or a Mac OS X program (which has a binary format called Mach-O). From there, it updates the application's linker table (a table which has the addresses for libraries in the system) with links to its own library (LibAlky, or even better, LibWine).

      So no, nothing this guy is doing is any kind of IP violation, and it already works (and could work better if it just targeted Wine instead of his own library). Of course, if you want to learn more of how Wine works (and for that matter, Linux and Windows), you can always go to their respective developer's websites.

    • Teiman, on 10/12/2007, -0/+0Yea. Thats a flaw of this approach. Maybe a kill one.

      Supose the exe contain garbage

      MZ#ASDFwinASFASFwinDA

      This garbage translate to linux

      ELF#ASDFlinuxASFASFlinuxDA

      you tun that, looks Ok, no windows stuff..., but then is uncompressed/uncypher to the real exe in memory, post facto.

      ELF#ASwinDFlinuxASFwinASFlinuxDAwin

      Ooops... the data result on API calls that are not converted by this proyect. So fail. Because this proyect dont run on runtime, so can't stop the executable from creating Windows code and triing to run it, that is what this cyph stuff do.
  • SniperSlap, on 10/12/2007, -0/+2If Wine is already working on this, he should put his efforts into that.

    I'm not always a fan of Wine though. So who knows. May the best man win (and absorb the other man).
  • lpcustom, on 10/12/2007, -2/+3This "news" should have been posted like two years from now. Cody, you said that you have converted windows apps to OSX with this. I think you mean you have made them executable binaries. I can do that with chmod +x. It's nothing to make a file executable. Making it work is the problem. Can you give us an example of what you have actually accomplished with this code? I have a feeling you have accomplished a lot less than you have portrayed to the digg community. Congrats for making front page but I think most of the people who dugg this have no idea what they are looking at.You may actually follow through and surprise me. I know if you are able to accomplish this you'll be one famous guy. I just don't see it happening. Whether thats being pessimistic or just realistic, guess we'll find out in 5 years.
    • daeken, on 10/12/2007, -1/+4http://flickr.com/photo_zoom.gne?id=161443549&size=o is the best screenshot I have right now. A simple (e.g. a quad and triangle) D3D app is almost entirely running, but I don't have any screenshots yet.
    • fatdog789, on 10/12/2007, -5/+1I invented fusion in my garage, but I forgot to take pictures. I also went back in time to the time of the dinosaurs, but my camera stopped working. You'll just have to take my word for it.

      Same difference.
    • daeken, on 10/12/2007, -1/+5You can see the source, fatdog.
  • lpcustom, on 10/12/2007, -0/+2well get some screenshots of it running....I'm interested in seeing how far you've came with it.
    • daeken, on 10/12/2007, -1/+3I'm fairly close now. Had a bit of trouble understanding how D3D used vertex buffers (I've only ever done OpenGL) so that took me a bit, but all that's needed now is to finish that up (only a few more lines) and write up the DrawPrimitive function. You can see what I have in the DirectX/D3D9 and DirectX/D3DGL directories in the SVN repository.
    • fatdog789, on 10/12/2007, -2/+1Agreed. This whole issue can be settled by 3rd party screenshots.

      And why the hell are you still trolling this site, daeken. Don't you have work to do? We (your detractors) will all be eating sour grapes IF you can actually prove that this ***** works (and no, a port of the most basic D3D tutorial *doesn't* cut it). Porting the deformable mesh tutorial would be a good start, as it requires both D3D and Windows API's.
  • Halvy, on 10/12/2007, -0/+2The reason Wine has not progressed fully, nor any other Win API related replacement for M$ is because of fear that M$ will bring a halt to it through tough legal action.

    What needs to be done is a completion of Wine and/or any related projects, in secret, and then released to the world community.

    This needs to be done WITHOUT any regard or respect for M$.

    Since that is not apparently happening, then the only other hope may be what Cringely said recently, about how someone as big as Job's, may be ready to solve this age old problem.


    http://www.pbs.org/cringely/pulpit/pulpit20060420.html
    • fatdog789, on 10/12/2007, -1/+1And then....
      BAM, MS's army of lawyers shut everything down.

      The main programmers of Wine are charged/sued for copyright violations. The main programmers are legally responsible for maintaining the code, so if anything illicit enters the code and they don't do anything about it when asked by MS, they get in massive trouble.

      If this project succeeds, MS will change the code in the next patch of Windows (you better believe they'd do this in under a week) and it's all rendered useless.

      Yeah, that's not such a good plan.

      WINE has progressed, as has MONO, not because they fear legal action, but because they need to do what they do in a completely OS manner that does not violate existing patents. This is incredibly difficult to do, but it is necessary, else corporations and governments WOULD NOT use the end product as they would be liable for all sorts of *****.
    • Halvy, on 10/12/2007, -1/+1fatdog, you didn't comprehend my post before responding.

      if something like this is released, like p2p and bittorent technology was released.. then all the liers.. i mean lawyers in the universe won't be able to do jack!!


      and why don't you explain to us, just how m$ changing the api AFTER the fact is going to affect software written for win32 previously??

      oh i know, the lawyers are all going to come get the software off our computers and change the api!! lol

      they are not training you very well in the use of FUD these days, in redmond :)
    • geminitojanus, on 10/12/2007, -0/+2"The reason Wine has not progressed fully, nor any other Win API related replacement for M$ is because of fear that M$ will bring a halt to it through tough legal action."

      I'm pretty sure that fear has been put to rest with Microsoft's Anti-trust lawsuit. The ruling was in favor of the government, and ruled that the API should be opened for interoperability. That ruling definitely would protect Wine.

      Basically, the only thing Microsoft could do is assert copyright on the API, but that's a very weak ground to stand on, legally: You and I both have an assignment to write a program that does the same thing, draw a cube. Because our assignments are so similar, it stands to argue that some of our function names will overlap (such as "DrawCube()"). Microsoft could argue the fact that Wine's direct task was to take their function names and reimplement their code, and argue they should be shut down for that reason, but like said above, if they pulled that defense, they'd be admitting to violating the Justice Department's ruling, and asking the Justice Department itself to counteract that own ruling.
    • wafflemania, on 10/12/2007, -0/+1fatdog, how is MS going to "change the code" as you put it?
      This project is based on the fact that they KNOW what functions applications are going to be calling. To "change the code", MS would have to rewrite every application that uses the win32 API.
  • fgb00, on 10/12/2007, -1/+2I don't understand why some people are so quick to shoot this down. It sounds like a fascinating project. And it seems likely that, even if it fails, some interesting technology may come out of it.
  • liquidrums, on 10/12/2007, -0/+2I would pay well over $500 for software to do this, and do it well :)
  • d3dm, on 10/12/2007, -0/+0If you have a fast enough pipe, you should just run this remotely and allow your machine to be nothing more than a thin client.

    This is what I predict someone like Google could do in a few years. The installation of your app would go to a Google-owned remote machine that would run the software. You'd send your input events to the remote box and it would send back a display list that your box would render. It follows that whole "software as a service" model and this is already being done with business applications.

    • capiCrimm, on 10/12/2007, -0/+0. . . and google creates a profile of you and sends back targeted adds as a bonus "feature".
  •  

    Login or register to add a comment

    Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.


© Digg Inc. 2008 — Content posted by Digg users is dedicated to the public domain.
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.