4

What exactly do we mean when we say that a program is OS-independent? do we mean that it can run on any OS as long as the processor is same?

For example, OpenGL is a library which is OS independent. Functions it contain must be assuming a specific processor. But ain't codes/programs/applications OS-specific?

What I learned is that:

  1. OS is processor-specific.

  2. Applications (programs/codes/routines/functions/libraries) are OS specific.

  3. Source code is plain text.

  4. Compiler (a program) is OS specific, but it can compile source code for a
    different processor assuming the same OS.

  5. OpenGL is a library.

Therefore, OpenGL has to be OS/processor-specific. How can it be OS-independent?

What can be OS independent is the source code. Is this correct?

How does it help to know if a source code is OS-independent or not?

unwind
  • 391,730
  • 64
  • 469
  • 606
KawaiKx
  • 9,558
  • 19
  • 72
  • 111
  • 1
    It means it can be compiled to run on a different platform. You are right, there are things that are highly-platform dependent, OpenGL gets around the majority of these issues by separating the core API from window system API (e.g. GLX, WGL, EGL). Frameworks like GLUT further hide this detail by having separate code-paths for each window system API, so you can write code using GLUT and never have to know the underlying window system. But since it is not binary distribution that we are talking about here, processor has next to nothing to do with anything, except a few endian issues in the API. – Andon M. Coleman Oct 11 '13 at 04:15
  • @AndonM.Coleman: There are languages that do not compile into machine code. – SigTerm Oct 11 '13 at 05:18
  • 1
    @SigTerm: Yeah, but he was referring to how the API for OpenGL is designed in order to accommodate multiple platforms, or at least that is what it sounds like. – Andon M. Coleman Oct 11 '13 at 05:32

4 Answers4

6

What exactly do we mean when we say that a program is OS-independent? do we mean that it can run on any OS as long as the processor is same?

When a program uses only defined behaviour (no undefined, unspecified or implementation defined behaviours), then the program is guarenteed by the lanugage standard (in your case C language standard) to compile (using a standards compliant compiler) and run uniformly on all operating systems.

Basically you've to understand that a language standard like C or a library standard like OpenGL gives a set of minimum assumable guarentees that a programmer can make and build upon. These won't change as long as the compiler is compliant with the standard (in case of a library, the implementation is standards-compilant) and the program is not treading in undefined behaviour land.

openGL has to be OS/processor specific. How can it be OS-independent?

No. OpenGL is platform-independant. An OpenGL implementation (driver which implements the calls) is definitely platform and GPU-specific. Say C standard is implemented by GCC, MSVC++, etc. which are all different compiler implementations which can compile C code.

what can be OS independent is the source code. Is this correct?

Source code (if written for with portability in mind) is just one amongst many such platform-independant entities. Libraries (OpenGL, etc.), frameworks (.NET, etc.), etc. can be platform-independant too. For that matter even hardware can be spec'd by some one and implemented by someone else: ARM processors are standards/specifications charted out by ARM and implemented by OEMs like Qualcomm, TI, etc.

do we mean that it can run on any OS as long as the processor is same?

Both processor and the platform (OS) doesn't matter as long as you use only cross-platform components for building your program. Say you use C, a portable language; SDL, a cross-platform library for creating windows, handling events, framebuffers, etc.; OpenGL, a cross-platform graphics library. Now your program will run on multiple platforms, even then it depends on the weakest link. If SDL doesn't run on some J2ME-only phone then it'll not have a library distribution for that platform and thus you application won't run on that platform; so in a sense nothing is all independant. So it's wise to play around with the various libraries available for different architectures, platforms, compilers, etc. and then pick the required ones based on the platforms you're targetting.

Chris Keefe
  • 797
  • 7
  • 17
legends2k
  • 31,634
  • 25
  • 118
  • 222
  • can we say that openGL library is OS specific but source code of openGL is OS independent? – KawaiKx Oct 11 '13 at 06:09
  • No, what I meant was not just source code, but libraires, frameworks, etc. can also be platform/os-independant. Take the .NET framework which is a specification; Linux has an implementation named [Mono](http://en.wikipedia.org/wiki/Mono_%28software%29) which can run a program that's based on .NET framework. – legends2k Oct 11 '13 at 06:12
  • but a library is a bunch of object codes and object codes are OS/processor specific? isn't it? – KawaiKx Oct 11 '13 at 06:14
  • Not necessarily. Say I've two programmer A and B. A programs in Linux and B on Windows. I say I need a library that opens a window irrespective of the platform and it's prototype should be `Window OpenWindow(const char *title, int left, int top);` then each should implement the same function differently based on the OS they work on. – legends2k Oct 11 '13 at 06:20
  • 1
    Now once they're done, my program can include their header and call the function `OpenWindow` and I don't have to worry about how the window is created. Since the library/API I use abstracts platform implementation details from me and when I call the function I can rest assured that a window with the passed title will pop-up at the passed location on screen. Such collection of function prototypes becomes a standard later on. [GTK+](http://en.wikipedia.org/wiki/GTK%2B), [GLFW](http://www.glfw.org/), etc. are such platform-independant libraries. – legends2k Oct 11 '13 at 06:22
  • @Saurabh: On most platforms, the OpenGL "library" as you refer to it is actually a pretty dumb wrapper. It may provide some basic OpenGL functionality, but the library is just a stub that lets you interface with a driver that provides a more complete set of functionality. There is no single implementation of OpenGL as with some other "libraries," which is why you should think of OpenGL as an API (just a common interface) that is implemented by vendors like NV, AMD, PowerVR, Intel, Apple, Mesa, etc. – Andon M. Coleman Oct 11 '13 at 06:24
  • "program is guarenteed" In practice, you may run into driver bug and not-quite-standard-compliant compiler/OpenGL implementation. (Did ATI/NVidia fix noise functions from GLSL?) – SigTerm Oct 11 '13 at 18:31
  • @SigTerm: Spec is to guarentee, but of course implemenations will have bugs. GCC, MSVC++ all do have bugs and so will APIs, libraries, etc. In practicality we deal with them, but when you introduce these to someone it'd be detrimental to the understanding than helping. – legends2k Oct 12 '13 at 03:32
3

What exactly do we mean when we say that a program is OS-independent?

It means that it has been written in a way, that it can be compiled (if compilation is necessary for the language used) or run without or just little modification on several operating systems and/or processor architectures.

For example, openGL is a library which is OS independent.

OpenGL is not a library. OpenGL is an API specification, i.e. a lengthy volume of text that describes a set of tokens (= named numeric values) and entry points (= callable functions) and the effects they have on the system level.

What I learned is that:

  • OS is processor-specific.

Wrong!

Just like a program can be written in a way that it can targeted to several operating systems (and processor architectures), operating systems can be written in a way, that they can be compiled for and run on several processor architecture.

Linux for example supports so many architectures, that it's jokingly said, that it runs on everything that is capable of processing zeroes and ones and has a memory management unit.

  • Applications (programs/codes/routines/functions/libraries) are OS specific.

Wrong!

Program logic is independent from the OS. A calculation like x_square = x * x doesn't depend on the OS at all. Only a very small portion of a program, namely those parts that make use of operating system services actually depend on the OS. Such services are things like opening, reading and writing to files, creating windows, stuff like that. But you normally don't use those OS specific APIs directly.

Most OS low level APIs have certain specifics which a easy to trip over and arcane to address. So you don't use them, but some standard, OS independent library that hides the OS specific stuff.

For example the C language (which is already pretty low level) defines a standard set of functions for file access, the stdio functions. fopen, fread, fwrite, fclose, … Similar does C++ with its iostreams But those just wrap the OS specific APIs.

  • source code is plain text.

Usually it is, but not necessarily. There are also graphical, data flow programming environments, like LabVIEW, which can create native code as well. The source code those use is not plain text, but a diagram, which is stored in a custom binary format.

  • Compiler ( a program ) is OS specific, but it can compile a source code for a different processor assuming the same OS.

Wrong! and Wrong!

A compiler is language and target specific. But its perfectly possible to have a compiler on your system that generates executables targeted for a different processor architecture and operating system than the system you're using it on (cross compilation). After all a compiler is "just" a (mathematical) function mapping from source code to target binary.

In fact the compiler itself doesn't target an operating system at all, it only targets a processor architecture. The whole operating system specifics are introduced by the ABI (application binary interface) of the OS, which are addresses by the linked runtime environment and that target linker (yes, the linker must be able to address a specific OS).

  • openGL is a library.

Wrong!

OpenGL is a API specification.

  • Therefore, openGL has to be OS/processor specific.

Wrong!

And even if OpenGL was a library: Libraries can be written to be portable as well.

  • How can it be OS-independent?

Because OpenGL itself is just a lengthy document of text describing the API. Then each operating system with OpenGL support will implement that API conforming to the specification, so that a program written or compiled to run on said OS can use OpenGL as specified.

  • what can be OS independent is the source code.

Wrong!

It's perfectly possible to write a program source code in a way that it will only compile and run for a specific operating system and/or for a specific processor architecture. Pinnacle of OS / architecture dependence: Writing things in assembler and using OS specific low level APIs directly.

  • How does it help to know if a source code is OS/window independent or not?

It gives you a ballpark figure of how hard it will be to target the program to a different operating system.

A very important thing to understand:

OS independence does not mean, a programm will run on all operating systems or architectures. It means that it is not tethered to a specific OS/CPU combination and porting to a different OS/CPU requires only little effort.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
2

There's a couple concepts here. A program can be OS-independent, that is it can run/compile without changes on a range of OS's. Secondly libraries can be made on a range of OS's which can be used by a platform independent program.

Strictly OpenGL doesn't have to be OS-independent. OpenGL may actually have different source code on different OS's which interface with drivers in a platform specific way. What matters is that OpenGL's interface is OS-independent. Because the interface is OS-independent it can be used by code which is actually OS-independent and can be run/compiled without modification.

Libraries abstracting out OS-specific things is a wonderful way to allow your code to interface with the OS which normally would require OS-specific code.

Cramer
  • 1,785
  • 1
  • 12
  • 20
  • 2
    You hit the nail on the head. OpenGL is an open specification, with dozens of implementations. The only thing that matters is the API, and the core OpenGL API goes out of its way to avoid anything platform-dependent; going so far as to split the implementation of setting up a render context into a separate set of APIs. The core API makes concessions for endianness when transferring data from GPU/CPU but that is about it. – Andon M. Coleman Oct 11 '13 at 06:16
  • @AndonM.Coleman So can we say that a specification is 'open' but an implementation is 'closed'. the openGL library installed in my computer is specific to linux OS which is specific to x86 (on my computer). is this correct? – KawaiKx Oct 11 '13 at 06:23
  • @Saurabh perhaps it's better to say a specification is 'fixed' while an implementation 'varies'. The concepts of open and closed are used for other things. – Cramer Oct 11 '13 at 06:28
  • @Saurabh: That library is just a stub, as explained elsewhere. Drivers provide the actual implementation of the vast majority of OpenGL on most systems, and the library is just there to provide a way to compile your software once and hook into the driver at run-time without you having to know or do anything. If you are more familiar with OpenGL, this will explain why you have to do things like `___GetProcAddress (...)` whenever you want to use a newer OpenGL feature. As such, the library (which is an implementation) may be platform-dependent, but the interface certainly is not. – Andon M. Coleman Oct 11 '13 at 06:28
0

One of those:

  1. It compiles on any OS supported by program framework without changes to source code. (languages like C++ that compile directly into machine code)
  2. The program is written in interpreted language or in language that compiles into platform-independent bytecode, and can actually run on whatever platform its interpreter supports without modifications. (languages like java or python).
  3. Application relies on cross-platform framework of some kind that abstract operating-system-specific calls away. It will run without modifications on any OS supported by framework.

Because you haven't added any language tag, it is either #1, #2 or #3, depending on your language.

--edit--

OS is processor-specific.

No. See Linux. Same code base, can be compiled for different architectures. Normally, (well, it is reasonable to expect that) OS kernel is written in portable language (like C) that can be rebuild for different CPU. On distribution like gentoo, you can rebuild entire OS from source as well.

Applications (programs/codes/routines/functions/libraries) are OS specific.

No, Applications like java *.jar files can be made more or less OS independent - as long as there is interpreter, they'll run anywhere. There will be some OS-specific part (like java runtime environment in case of java), but your program will run anywhere where this part is present.

Source code is plain text.

Not necessarily, although it is true in most cases.

Compiler (a program) is OS specific, but it can compile source code for a different processor assuming the same OS.

Not quite. It is reasonable to be written using (somewhat) portable code so compiler can be rebuilt for different OS. While running on OS A it is possible (in some cases) to compile code for os B. On Linux you can compile code for windows platform.

OpenGL is a library.

It is not. It is a specification (API) that describes set of programming functions for working with 3d graphics. There are Libraries that implement this specifications. Specification itself is not a library.

Therefore, OpenGL has to be OS/processor-specific.

Incorrect conclusion.

How can it be OS-independent?

As long as underlying platform has standard-compliant OpenGL implementation, rendering part of your program will work in the same way as on any other platform with standard-compliant OpenGL implementation. That's portability. Of course, this is an ideal situation, in reality you might run into driver bug or something.

SigTerm
  • 26,089
  • 6
  • 66
  • 115
  • That is not entirely true. Even though Python is an interpreted language, half of the picture when it comes to getting OpenGL setup is creating a render context using the window system. You definitely have to modify the software if it was originally written for GLX and is moving to WGL. None of the OpenGL API calls should need to be changed, but the platform-dependent parts which are separated into the window system APIs will need to be. – Andon M. Coleman Oct 11 '13 at 05:30
  • Sure, but that is part of the OpenGL binding for Python. Not a consequence of Python being an interpreted language. The actual reason it works is because those modules hide the window system API, when running on Linux it will use GLX and Windows it will use WGL. I have seen Python code that interfaces directly with the underlying window system because the bindings are inadequate, much like GLUT is often inadequate. – Andon M. Coleman Oct 11 '13 at 06:10
  • @AndonM.Coleman: My point was that on any platform that has opengl there's a library that'll abstract platform-specific calls away. " it works is because" And? See #1. If all code is within the same file, it is #2. "I have seen Python code" And I've seen multithreaded C++ code that passed function parameters via global variables. If someone did that, it doesn't mean it is a good coding style or something. – SigTerm Oct 11 '13 at 10:47
  • Good, we are on the same page then. But this is unfortunately not what you wrote in your answer, and that is what I was trying to point out. Your answer implies that portability is achieved through running in a virtual machine / interpreter alone, but it is actually achieved through libraries, modules, etc. that abstract the platform specifics away in the case of OpenGL. It is still possible to interface directly with the platform-specific parts of a system in a Java or Python user application is the point I was trying to make - it is frowned upon for portability, but can be done. – Andon M. Coleman Oct 11 '13 at 17:05