Is it possible to make an application that works on both windows and mac without being recompiled for each OS?
Printable View
Is it possible to make an application that works on both windows and mac without being recompiled for each OS?
Yes, I believe so. I think you can use this. It's Trolltech's Qt application: http://trolltech.com/products/qt/. But I think you can only do so much. I'm not sure though. Hope this helps though.
With respect to C++, the answer is generally no.Quote:
Is it possible to make an application that works on both windows and mac without being recompiled for each OS?
How about windows and unix/linux?
No. Windows and Linux have different executable formats.
Besides that, it is highly unlikely that something compiled for one platform will work on another (technically, it's possible, but it's darn difficult, and I doubt anyone has done it or will).
i was just curious because i saw the pro version of limewire where they claimed it was compatable for windows, linux, and mac.
http://www.limewire.com/download/
The question is not whether it is possible to write a program that runs on both Windows and Mac, but whether it is possible to write a program that runs on both Windows and Mac without compiling for each platform.Quote:
i was just curious because i saw the pro version of limewire where they claimed it was compatable for windows, linux, and mac.
yes i understand the question. at the top right corner where it is listing the benifits of limewire pro it states it is windows, mac, and linux compatible.
Have a look at their download links again. There are 4 different versions, not one.
i am aware of that but the PRO version specs at the top say it supports all three OS's
Yes -- but that just says they have a version on the OS's. The three files are NOT bit-for-bit equivalent.
Irrelevant. There are 4 different versions. Each one compiled for their specific platform.
There is no way, with C++, that you can get the same executable running on both Windows and Linux and Mac.
They use different executable formats! It just won't run. OS Limitation.
you guys are just jealuos of my sweet c++ knoledge.RARRRRRRRRR
That dinosaur you do is just so darn cute I can't stand it.Quote:
Originally Posted by herWter
There are a few things that need to match if you want to write a compiled [1] application that runs on different platforms:
- All systems must support the same file-format. Windows uses something called PE-COFF. Linux generally use ELF but also has a "a.out" format. I think ELF is also the format for the recent versions of MacOS (v10+ that is based on a BSD Unix type kernel). Older MacOS is using a different [I think proprietary format].
- All systems must support the same instruction set. That means that the Mac model must have a x86 processor to be compatible with a x86 version of Linux or Windows - or the processor will be just as wise as I am when a french person speaks his/her native language with me - that is, I haven't got a clue. [2]
- All systems must support the same API/ABI. API stands for Application Programming Interface, ABI is Application Binary Interface. The API says "these are the functions we can use in this OS, and this is what you can expect from the function [including what happens if you pass in 'bad' parameters - e.g. a filename that doesn't exist to a OPEN FILE function]". The ABI tells the (system)programmers how "stuff" is passed from one function to another within the system, e.g. a function that returns an integer does so in register X, arguments to functions are passed in registers Y and Z and then on the stack [the stack is in register W], etc, etc.
There are some ways around all/some of these things. We could for example have our own generic ABI/API combination for our application, and then have three sets of ABI/API interface files that translate our internal ABI/API combo into the particular systems ABI/API - so "genericOpenFile" translates to Windows "OpenFile", and "open" in Linux/MacOS.
We would also have to build a system-specific loader that loads our generically supported file-format. So in Windows, we'd have something that uses VirtualAlloc() to allocate memory for the appliction to run in, and then load the code into the allocated memory.
It is possible to do, but it gets very hard if you want to support generic functionality, because there are usually differences in how the different OS's support something, and they are so different that you have to use a different overall principle to solve the same problem in two different OS's [a typical example is "fork()" which doesn't have an equivalent in Windows at all - it would be possible to fake a fork(), but it's quite complicated and it's very easy to "miss something" so that it's no longer doing the exact thing the coder wanted].
[1] It is of course much easier to have the same code work on different platforms if it's compiled into a form that isn't actually machine code for the target system.
Other languages, such as C# and Java have solutions do this. In Java it's pretty good, but I have a feeling that C# is fairly limited in what you can actually do if the system isn't running on Windows.
Unfortunately, this also means that there's a performance loss compared to natively compiled applications. It is possible to "compile as we go along" into machine code, but it is still quite hard to get that to run as fast as a native application, because some of the original context of what was actually being the code has been lost in the intermediate translation - a bit like translating something from english to spanish, but because we couldn't find a good english to spanish translator, we take the french translation and translate that to spanish - some of the original "flavour" of the language has now been lost.
[2] There have been systems (e.g. MacOS systems) that support older applications compiled for a processor that is different from the current processor, e.g. running 68000 based code on PowerPC and running PowerPC on x86 processor. This is however not a particularly good solution for high performance operations.
But then again, you would need a custom loader, which would have to be compiled into an application somehow, which would repeat the whole argument above. There's no way you're getting a compiled application running on Windows and Linux or Mac (with the same executable).Quote:
Originally Posted by matsp
And besides, it's just more profitable to compile the code on the different platforms and end up with different binaries. No need to develop expensive special loader systems and testing to make sure it works on all platforms and the extra work and researching it takes to create platform-independent code.
I agree. I was just trying to explain that it IS possible - just not very practical, because, as you explained, you end up with some components that are system dependant, and those need to be developed and compiled for multiple platforms.Quote:
Originally Posted by Elysia
Of course, if you have a HUGE application that you want to produce for multiple platforms, it may be simpler to produce a small layer of "shim" to connect to the OS proper - whether that is a separate loader and API/ABI shim, or just a set of library functions that interface between the application proper and the OS dependant components is a different question.
--
Mats