0

I understand that programming languages can either be run in a VM (Java, etc) on every OS that supports the VM natively or can be compiled to machine code (C, etc) for each platform.

What I don't necessarily understand is why programs (whether dealing with graphics APIs like OpenGL, DirectX12 or Mantle, or not dealing with any at all) aren't all cross-platform if it's as easy as cross-compiling?

What is it that keeps programs, games, APIs (for example OpenGL) from being compatible on all platforms (except that maybe the developers only wanted it on one platform)?

With the new graphics API, Vulkan, coming out soon, would it be theoretically possible if using a toolkit like wxWidgets, for native GUI, along with an API like Vulkan to create programs that run completely cross platform as long as the OS has a Vulkan driver? Any other insight on something I'm missing would be appreciated.

  • Ever look into what kind of performance hit may be taken to make something cross-platform? – JB King Dec 23 '15 at 18:13
  • What do you think is going to happen if I design something with Vulkan in mind and someone tries to run it on MS-DOS 6.22? – whatsisname Dec 23 '15 at 18:15
  • 1
    Cross compiling is only easy when someone has done the work to make cross compiling easy... and that's not easy. – GrandmasterB Dec 23 '15 at 18:48
  • 2
    Possible duplicate of What makes a program cross-platform or not? – gnat Dec 23 '15 at 19:20
  • The proposed dupe target is specifically about C++ programs, while this one focuses on graphics APIs. The answers on the other question simply do not mention the fact that for any given graphics API, not every system in existence has a driver for it. – Ixrec Dec 24 '15 at 14:33
4

With the new graphics API, Vulkan, coming out soon, would it be theoretically possible if using a toolkit like wxWidgets, for native GUI, along with an API like Vulkan to create programs that run completely cross platform as long as the OS has a Vulkan driver?

You've answered your own question.

The Vulkan driver has to be written for every system/OS, and not all systems will be compatible with what is required by Vulkan.

1

APIs build atop one another by value addition. Hardware vendors have choices amongst standards, then there is firmware, then ABIs from interpreters and build toolchains, chosen by monitor/OS vendors, leading to line ending of scripts CRLF-NL combinations and ELF & COFF executables. Upcoming C++ 17 has modules proposal, but until then mangling of overloads has compelled vendors trying for up to date broad hardware coverage to favor system software vendors using C calling convention(or anything close enough clarity-wise). So many stakeholders trying to comply with so many different possibilities at once, if one solution software program were to cover many of these, then the executable payload would be bloated during times when disk space was precious... cause of platform dependence

Vulkan(for more insight), assuming all goes well, is expected to allow developers to work with graphics bypassing intermediate binding wrappers, when the value additions will be unused anyhow. Without committing career to C, similar earlier efforts used to be made via DCOM/XPCOM...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.