How come games can only run on some OSs?
Author
What prevents a game from running on multiple OSs if the game was written in a language they all have compilers for?
Quote:Original post by llamaSong
What prevents a game from running on multiple OSs if the game was written in a language they all have compilers for?
Because platform dependant calls (or API's) always finds their way into the source and abstracting out and porting those portions are seldom deemed profitable since something like 95% of the total games market is windows boxes.
Some games use APIs that don't have equivalents on other platforms. DirectPlay, for example, is particularly limiting. Even if you avoid platform specific APIs and libraries, there are also other fundamental differences between computers that languages can't perfectly hide. For example, Macintosh computers use big-endian integer storage, while x86 uses little-endian integer storage. This can cause certain pointer code to blow up when moved from one platform to the other. Even when equivalent or even the same API are available on different platforms, differences in how these functions are implemented can hinder migration. For example, the dup2() function call on some *nix platforms will close the new file descriptor, while on other platforms will duplicate the file handle and the next available open file handle. Finding and detecting these differences can take a great deal of testing time, so companies may simply not have enough time and money to do the migration.
You need to code with the target OS in mind. For example, even though C++ can be compiled on Win32 and Linux, if you used the DirectX API for graphics you would only be able to run your game on a Win32 OS, because DirectX is only supported by Windows. If you used OpenGL on the other hand, you could potentially write a program capable of running on both operating systems.
Basically, you have to keep it in mind with every design decision (talking about code design here), and only use components that are supported by each OS you wish to support - furthermore, you may need to use the components in a certain fashion.
Well designed code can generally be ported (i.e. changed as neccesary and recompiled) to a different OS with little difficulty if the coder(s) has been keeping this in mind, but for many things a lot of people just don't consider it worth the effort to create code that will port easily (or be cross-platform right out of the box).
That's a pretty basic explanation and doesn't really cover it in much detail, but hopefully that'll give you a decent idea of it. [smile]
Basically, you have to keep it in mind with every design decision (talking about code design here), and only use components that are supported by each OS you wish to support - furthermore, you may need to use the components in a certain fashion.
Well designed code can generally be ported (i.e. changed as neccesary and recompiled) to a different OS with little difficulty if the coder(s) has been keeping this in mind, but for many things a lot of people just don't consider it worth the effort to create code that will port easily (or be cross-platform right out of the box).
That's a pretty basic explanation and doesn't really cover it in much detail, but hopefully that'll give you a decent idea of it. [smile]
Several things:
Libraries. Windows has libraries called Winsock and DirectX that Linux and Mac don't have. Mac OSX has libraries called Cocoa and Carbon that Windows and Linux don't have. If you ported these libraries, re-writing them to work on a different operating system, lots of programs would work there. This has been done; google Wine and Cygwin.
System calls. There are certain fundamental services the OS provides, that work in a certain way, and tend to be used a lot. On Linux, for example, the classic examples are fork() and select(); these work very specific ways, and are very hard to duplicate on other OS's.
Support programs. There are more of these than you think. Linux uses a program called X11 to display graphics; there are similar programs for Windows, but you generally have to buy them. You wouldn't want to anyway, since Windows has it's own way of displaying graphics. Windows also has a framework of tools called (variously) COM or ActiveX, which Linux and OSX doesn't have. Even the loader, a fundamental program that takes other programs and finds all the correct DLL's for them, is different on all three systems.
Basically, this means that if you want a program to run on more than one platform, you had better have some way to cover up all these differences. It can certainly be done, and there are cross-platform frameworks such as SDL that set out with this in mind. But they're a lot of work to create, even more work to design and maintain well, and often you can get more support/performance/power by using something like DirectX that only works for one specific OS.
Libraries. Windows has libraries called Winsock and DirectX that Linux and Mac don't have. Mac OSX has libraries called Cocoa and Carbon that Windows and Linux don't have. If you ported these libraries, re-writing them to work on a different operating system, lots of programs would work there. This has been done; google Wine and Cygwin.
System calls. There are certain fundamental services the OS provides, that work in a certain way, and tend to be used a lot. On Linux, for example, the classic examples are fork() and select(); these work very specific ways, and are very hard to duplicate on other OS's.
Support programs. There are more of these than you think. Linux uses a program called X11 to display graphics; there are similar programs for Windows, but you generally have to buy them. You wouldn't want to anyway, since Windows has it's own way of displaying graphics. Windows also has a framework of tools called (variously) COM or ActiveX, which Linux and OSX doesn't have. Even the loader, a fundamental program that takes other programs and finds all the correct DLL's for them, is different on all three systems.
Basically, this means that if you want a program to run on more than one platform, you had better have some way to cover up all these differences. It can certainly be done, and there are cross-platform frameworks such as SDL that set out with this in mind. But they're a lot of work to create, even more work to design and maintain well, and often you can get more support/performance/power by using something like DirectX that only works for one specific OS.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
