Sure, write your own OS. Then you can avoid everyone else's vendor specific code and use your own. ;P

I don't understand your question. If you want a program to run on a specific OS, then you need to use the API it provides. A linux program won't run on a win32 machine, and win32 won't run on linux without wine or something similar. That's just the way it is. :/

The OS can only do what it knows how to do. That means it has a specific set of instructions. If you want to tell it to do something, you have to use an instruction it understands. You can't avoid it.

You might be stuck in a XY Problem

As far as not writing OS-dependent code, do you mean the code you write or just the code in your compiled program?

If it's the code you write, then you could write software without OS-dependent code, it would depend on the library that handles the OS-dependent stuff for you. Some libraries might include enough stuff that you could write something without writing a single OS-dependent line of code, while some might require you to do some branching, like if Windows do this, if Linux do this, etc. And in some cases no matter how good the library is, you need to do OS-dependent code.

There's something you're not telling us or there's some other problem you're trying to solve why do you want to avoid OS code so much?

most people use a library that is cross-platform and so they avoid this issue altogether. Most people don't even use OS code so what are you worried about?

I was just wondering that whether a person can do programming without using OS system calls like how the OS is actually outputting Graphics and sounds with just opcodes.

Is it possible to do something like that, I mean can a library give graphical output without being dependent upon OS to allow the library to access the video memory?

If it helps, think of it this way: The source code can be platform independent. But in the case of many programming languages, the code will eventually have to be compiled and linked in order to run on a particular platform (ie. Windows). After that occurs, there will be platform-specific libraries/etc. in the program binary. Libraries like Allegro can do the hard platform specific stuff involving graphics, input, sound, etc. so you just write the source code once and that code will work on Windows, Linux and Mac. You just build the program for each of those platforms.

https://www.allegro.cc/forums/thread/617683

Technically there's no good reason that a Linux program can't run on Windows or visa-versa. In fact, I believe Windows 10 supports a devloper-only Ubuntu install that does run Linux code natively in Windows through a subsystem. It's not a virtual machine as far as I know. Effectively it's just a library that understands the ELF executable format and shared object file format (and the necessary system calls are somehow accounted for, but I'm not familiar with it).

Ultimately, the only reason software needs to be written with platform specifics is that a standard doesn't exist to unify everyone, or where it does exist specific vendors are ignorant of it or explicitly differ to try to limit users to their platform. The operating systems are ultimately just feeding instructions into the CPU, and processing inputs and outputs from the same hardware primitives and peripherals. They differ mostly because of competition: they're usually different just to be different so you HAVE to write platform specific code. If your Windows program ran just as effectively on Linux without any changes, and Linux is free, are you going to pay $200 every couple of years to use Windows or are you going to just use Linux (which is better in nearly every way).

The CPU has a specific set of instructions. The OS understands system calls, or basically a register has a specific service request, and a CPU interrupt instruction passes control back to the kernel code to handle it. There's no good reason that all common operating systems don't wrap their specifics in a standard API in say C. Ultimately, the failing to do so is competition and antitrust. Effectively, vendor lock-in. If your code only runs on Windows then it's more difficult for your customers that depend on your program to switch away from Windows. In practice, we could all be writing code that runs on all operating systems. The differences can and should be abstracted behind standard APIs. But it's a free market, and vendors are free to differ from everyone else, and they do so enthusiastically.

The OP is a newbie trying to understand how programming works. I don't know why we're conflating the issue with shenanigans. Why would the OP want to avoid OS specific code? Because it's complicated and expensive. OS specific code benefits the OS vendor, but nobody else. Maybe in rare cases it might benefit performance, but it's probably not true that a standard API, which could often be macros or inline functions equivalent to the OS specific code, would significantly impact performance 99.999% of the time so that's not really relevant. Ultimately, the OP should avoid platform specific code because it makes the code less portable and makes it more expensive to be portable.

#include <stdio.h>
int main()
{
   printf("Hello, World!");
   return 0;
}

No, it's full of standard C code. The preprocessed code is probably full of OS specific code, but the author of Hello World didn't write it, and that's the point. There's no harm in a portable program producing platform specific code. What matters is abstracting the platform specifics so that the author doesn't have to maintain several versions of the code at great expense.

Libraries are entirely optional. Ultimately, the operating system typically exposes the hardware through some kind of interface. Typically system calls, which I think typically means hardware interrupts, which I think is just another instruction in the CPU that tells it something special is happening. What that means depends on the OS. A library is useful here because it can abstract the details away from you. You don't have to remember the magic numbers that do things anymore, or the specific CPU registers that need to be loaded with magic numbers. You just make a relatively high-level function call and the rest is magically handled for you under the surface.

Cross-platform (meaning the code runs on many platforms) libraries exist. Allegro is one of them. Allegro is cross-platform. If you stick to Allegro calls your program should be compatible with Linux, Mac OS X, and Windows (and a couple of other less popular platforms, depending on the version of Allegro). You will have to build the program for each target platform though. Different executable files run on different platforms.

That's again just a choice that the OS vendors have made. There's no technical reason that a program compiled in Linux can't run in Windows. The program is ultimately just a collection of CPU instructions organized into a standard format: data that the OS needs to know how to unpack to feed to the CPU. That can include references to "dynamically-linked" code in DLLs (Windows) or shared objects (Unix-likes) so the executing operating system needs to also understand how to link the code at run-time to find the code in other files (when you execute the program).

Ultimately, because the operating systems differ in their low-level interfaces there needs to be platform-specific code to interface with non-standard hardware. Your program usually doesn't want direct access to video memory. It would be too burdensome if you had to understand how to display things on a computer screen through whatever connector that is in use. Instead, system-level code and drivers knows how to do what you want for whatever hardware you have. Basically each differing hardware interface requires custom code to talk to the computer OS and userland programs.

In the 80's you might well have written code specific for the platform and hardware. But thankfully these days these things are abstracted. There are something like 8000 people in the world that develop the Linux kernel alone. These people study the specifics of hardware and write software interfaces to it so that the rest of us can easily use it.

When you use standard C functions like printf it is ultimately talking to hardware: the text data that you write to the file handle is either copied into your monitor in some specific format to be displayed as text, or drawn graphically on screen, or perhaps written to a USB thumb drive's memory or a hard disk's plates. What it does depends on the type of device that the standard output file handle refers to in your specific program invocation at run-time.

There are completely free (as in freedom AND free as in beer) operating systems that you can study the code to. You can study the Linux kernel to learn how the low-level kernel and drivers work, and study the compiler toolchain like GCC to learn how the library functions ultimately turn your high-level request into low-level operations.

But there's millions if not billions of lines of code involved. It's a LOT to understand. You could spend your entire life studying just one part of that interaction and still not fully understand every part of it. Our time in this world is limited. Nobody in "IT" or "computer science" understands the entire modern day stack from top to bottom. You have to specialize in what interests you, and just trust that the rest works as described.

You probably won't find a "kernel hacker" building games in their spare time (it could happen, but it would probably be rare). It pretty much takes every minute of their available time to just do the kernel hacking part. Similarly, you probably won't find a game programmer hacking on a Word processor. All non-trivial programs pretty much require dedication that doesn't leave a lot of room for other things. You have to figure out what interests you and figure out how to succeed doing that. Over time you will learn about other areas of the industry from a high-level, but you're only going to get to experience the areas that you work with personally. The rest is just an abstract black-box that you can get a general notion of how it works, but it's basically just magic to you. But at least you know it's not really magic: it's magnetic or electronic signals forming circuitry pathways that ultimately make a butterfly flap its wings or visa-versa...