How to make cross platform software ?

How do you make cross platform software ?
does the compiler have to be cross platform or the libaries or both ?

So if i use mingw as a compiler for windows will it work on mac or linux
Last edited on
How do you make cross platform software ?

write code that the compiler/interpreter can generate equivalent instructions for on any os

does the compiler have to be cross platform or the libaries or both ?

why would the compiler have to be cross platform? if you use a library that is not cross platform, your code is not cross platform

So if i use mingw as a compiler for windows will it work on mac or linux

the binary? not natively no.
So if i write a application using Opengl which is cross platform would it work on all operating systems it is available on
closed account (2LzbRXSz)
As long as you're not using any OS specific headers, commands, functions, etc... You're fine.

I'd recommend downloading a virtual machine with a Linux OS, and a Mac OS to test out your software (Or just make friends with people who are on Linux and Mac to program with and test out your stuff but testing it out yourself is the best option. That way you're not dependant on others).
You can use Qt... It will tone down your work

You can use Virtual box to check out your work on different environments...
Last edited on
When the compiler compiles the code, it links/incorporates platform dependent library's that are on your computer which handle the behind the scenes stuff that needs to be done for your program to run on a given operating system and machine.

When you compile your code, the resulting executable file will only run on the type of system is was compiled for. This is not avoidable.

You just need to worry about the code being cross platform. That means that you can compile it on any operating system. That means when you use a library that's not part of the standard built in C++ library, you need to make sure it's cross platform.

It is sometimes possible to get certain tools and libraries and set up a compiler so that it can compile a program for a different operating system than your running. This is called cross-compiling. I wouldn't recommend it unless you have to for some reason.

Of course I'm talking about native compiled code like C, C++, etc. There are some other types of languages like Java and C# which are different in that they are designed to not be ran by your system directly, they instead are ran by another program that sits between your system and your program. This way they are able to ( sort of ) achieve "compile once, run anywhere".
Last edited on
closed account (2LzbRXSz)
Oh yeah, I completely forgot to mention the executable file.

.exe will not execute on Unix systems (Or at least, not on Mac. I think Linux can still run them). Unix has all sorts of executable files (From what I've read, on Unix every file is read as executable it just has to be executed ((Is that just Linux though? I'm a Mac user but there's still a bit I'm unsure of. They're both Unix systems so I'm assuming it goes for both)).) .out is what I use as a replacement to .exe

cactus that comment got me so confused xD
thanks everyone now i understand the libraries i use have to be cross platform and not focused on one OS
closed account (2LzbRXSz)
Sorry about that haha.

In short
.exe will not work on Mac
.out will work on Mac.

I think either should work on Linux
"Cross platform" software is software that is available on all of the most commonly used operating systems (today, it's Linux, Windows, and Mac; Although google's ChromeOS seems to be trying to weasle it's way in as well).

However, I believe you meant to say "how to write cross-platform code", which is code that compiles on all the most commonly used operating systems without any modification. The compiler is not part of the codebase, and, thus, is not included in this definition. To write cross-platform code, all you have to do is use a cross-platform build system (cmake is pretty popular, and readily available), and modify your code to use cross-platform libraries instead of direct calls to the operating system. While making calls to the operating system's API isn't forbidden, or even bad practice in some situations, it can make it harder to maintain as different operating systems are updated continuously and their APIs change over time.

The Boost library provides cross-platform implementations for a huge set of operating system features: filesystem, ASIO, etc... So it is my primary choice. I'm sure there are other libraries though.
closed account (2LzbRXSz)
There's a ChromeOS? Jeez.
Yeah, it's part of Google's chromium project: http://www.chromium.org/chromium-os

It's what runs on their ChromeBooks. They're starting to become populare because they're cheap.
Last edited on
closed account (2LzbRXSz)
Huh... You know what that reminds me of?

http://ultronbrowser.io/

I watched 2 of their videos about it. It's great for people who only use their computer to go on the internet. It just doesn't sound very safe (well, maybe it is because who would bother writing a virus to take out ChromeBooks if only a small percent of the majority use them) or like it can do much else. It's almost pointless.

I'd say it's good for younger kids, but younger kids are more interested in computer apps and games than their Social Media.

Edit: It's good for older folk, like grandparents who just need to check their email.
Last edited on
Oh yeah, I completely forgot to mention the executable file.

.exe will not execute on Unix systems (Or at least, not on Mac. I think Linux can still run them). Unix has all sorts of executable files (From what I've read, on Unix every file is read as executable it just has to be executed ((Is that just Linux though? I'm a Mac user but there's still a bit I'm unsure of. They're both Unix systems so I'm assuming it goes for both)).) .out is what I use as a replacement to .exe

...

Sorry about that haha.

In short
.exe will not work on Mac
.out will work on Mac.

I think either should work on Linux
[quote]

there are so many things wrong with this. first:
[quote].exe will not execute on Unix systems (Or at least, not on Mac. I think Linux can still run them)

.exe is an extension. if i name any file foo.exe on a unix (or unix like) machine, it will execute, as long as it has the executable (+x) flag and has told the os the proper way to execute it. for example:
1
2
3
4
5
6
$ echo "#!/usr/bin/python2.7" >> foo.exe # so foo.exe is a python file
$ echo "print 'Hello, world!\n'' >> foo.exe
$ chmod +x foo.exe # make foo executable
$ ./foo.exe
Hello, world!
$ 


What you mean is COM/PE (the windows binary executable type) wont execute on Unix/Linux systems, which is only half right. It wont execute natively (like ELF/Mach-O files on linux/mac systems respectively) because they dont come with COM/PE loaders. Programs such as wine (does wine exist on mac? im sure it exists for other unix systems like BSD) allow you to run COM/PE though.

Unix has all sorts of executable files (From what I've read, on Unix every file is read as executable it just has to be executed ((Is that just Linux though? I'm a Mac user but there's still a bit I'm unsure of. They're both Unix systems so I'm assuming it goes for both)).)


on unix (and unix like systems) *almost* everything is a file. not all of those files are neccesarily executable though. only things marked as executable (ie +x the executable flag). this is true of all unix (including mac) and unix like file systems (including linux and the bsd's). also, the point of Linux is that it isnt unix ;). Linux Is Not UNix (coincidence, since Linus didn't come up with Linux).

.out is what I use as a replacement to .exe

no its not.

edit:
thanks to toad, who did my research for me since i had a pissy day at work, wine does in fact exist for mac
Last edited on
closed account (2LzbRXSz)
Thank you for correcting me.

Wine exists, and if I really needed to run a .exe I have bootcamp set up so I can switch over to Windows, but without any help from Wine, Bootcamp, etc... You can't run .exe (just like you said, it can't execute natively) that's what I meant.

Little Bobby Tables wrote:
no its not.

Sorry that was really terrible wording on my part. If I'm not using any external libraries, and it's just a plain-jane console application, .out is what I use.

.app is much closer to .exe (but honestly it's such a hassle and most of the time I'm experimenting in console so I'm just not used to .app and even sort of forgot about it).

Apologies on my part for all the false information, and thanks again for correcting me.
Last edited on
Little Bobby Tables wrote:
on unix (and unix like systems) *almost* everything is a file.


I've used arch linux for almost a year now, and have yet to come accross a filesystem object that isn't a file. I would, however, add that the same is true on Windows, but that it's just implemented differently (and by differently, I mean poorly, and with a few exceptions to the rule). For example, links are "files", so are folders, but external media/hardware is just a mess to deal with and isn't represented as files as in *nix operating systems.

But that's just me being pedantic... Let's get back to the OP.
@iwik: drivers arent considered files apparently.

For example, links are "files", so are folders, but external media/hardware is just a mess to deal with and isn't represented as files as in *nix operating systems.

links are files. not "files" (well im assuming you mean links to other files, ie ln). and external media is treated as a file ;). it is literally a file system. you just have to mount it.

cactus:
for every time you say .exe, replace it with COM/PE. as i showed you, linux can run "exes".

.app is much closer to .exe

do you mean the macintosh Application files? those are not close at all to COM/PE. if anything its closer to JAR.
closed account (2LzbRXSz)
.app launches the application on Mac like .exe would on Windows, from my understanding. I understand that they function in completely different manners, but I'm talking in terms of what can natively be executed on Mac. (Jar can be executed natively on Mac, but exe can't. So it's not a "replacement" like I had originally said, but the "how-Mac-apps-are-packaged.")

Edit: I was half asleep when I replied, and just reread what you wrote now.

I get what you're saying, and I don't mean to be a nag about it, I'm just sort of trying to explain what I meant (but honestly I need to do my homework on these things and get more savvy with the terminology. I could blame it on being self taught, but I don't like coming up with excuses and that's not even a fair excuse).
Last edited on
Little Bobby Tables said:
and external media is treated as a file

Not on windows. On *nix, you can write to a device file to control the device, but on windows, you have to use the api. Devices aren't files on windows.

Little Bobby Tables said:
drivers arent considered files apparently

I never said anything about drivers...
Topic archived. No new replies allowed.