I dont understand how a compiled program communicates with OS

How does a compiled C++ program communicate with OS like accessing and reading files? If the C++ standard library is written in C++ then how do the standard libraries communicate with OS?

Can I read, write files or read mouse co ordinates without using C++ standard libraries?

Also, could I in ASM code something that triggers a software interrupt to execute a certain Kernel function?
Each OS will provide you with an API for accessing its internals. This is what you get when you #include <windows.h> or #include <unistd.h> . The C++ standard libraries use these functions to communicate with the OS. Windows provides OpenFile() as a function. The C++ standard library will use this function during fstream::open(). If you compile on Linux, you can use fstream::open(), but it will probably call the appropriate linux function. This is how the C++ standard libraries are platform-independent... by supporting all platforms.

The C++ libraries don't nessesarily #include <windows.h>, they are often written in a lower level language such as asm, but the same concept applies.
And the ASM basically uses interrupts to call the appropriate OS function, correct?

Anyway, everything makes better sense now, thanks stewbond for your answer.
No, even if written in assembly, they will use the correct OS functions to handle things like files.


That is why you cannot use, for example, Microsoft's Visual C++ library DLLs on Linux. Because the MS C++ library interacts with the Windows API, and not with the POSIX/Linux API.
Duoas, you should re-interpret his 2nd question.

Basically:
Standard -> Windows API -> ASM interrupts
I suppose you use ASM interrupts as the lowest level to read a file.
In this case, yes.
Windows does not use interrupts to read files.

Modern versions of Windows no longer support the old DOS Int 21H stuff (and haven't for a rather long time). You need an emulator to do that.

If you are writing assembly, you really would have an easier time just linking with the standard OS API.

Because there is really no sense in writing ancient OS-specific code that won't work on your OS.
But, does Windows itself internally use Interrupts? If it does, that's it, that's what I think he meant.
closed account (N36fSL3A)
The standard lib is basically rewritten for each OS.
And the ASM basically uses interrupts to call the appropriate OS function, correct?

C++ library (e.g. fstream::open()) will call OS function e.g. POSIX open(2)), which will call OS-specific functions, which will then execute the system call, which will transfer control from user space to kernel space and do things there (e.g. change open file descriptor table)

System call can be a special CPU instruction, an unconditional jump instruction to a special memory address, or, as was the case in MS-DOS, a software interrupt instruction

For example, this is what the OS-specific functions that open a file look on the systems I use, from the beginning and until the system call instruction
AIX/32bit

lwz   r12,0x6fc(r2)
stw   r2,0x14(r1)
lwz   r0,0x0(r12)
lwz   r2,0x4(r12)
mtctr   r0
bctr

AIX/64bit

ld   r12,0x9f0(r2)
std   r2,0x28(r1)
ld   r0,0x0(r12)
ld   r2,0x8(r12)
mtctr   r0
bctr

Solaris/64bit

mov      5, %g1
ta       %icc,0x0000000000000040

Solaris/32bit

mov      5, %g1
ta       %icc,0x00000008

Linux/64bit:

mov    $0x2,%eax
syscall 

Linux/32bit:

push   %ebx
mov    0x10(%esp),%edx
mov    0xc(%esp),%ecx
mov    0x8(%esp),%ebx
mov    $0x5,%eax
int    $0x80


Exactly.

Whether or not Windows itself uses interrupts to do stuff is irrelevant. Do things according to the exposed API, and you won't have any problems. Try to go behind that and you are asking for all kinds of troubles that you really don't want to waste time dealing with.

(Part of Windows' job, and any OS's for that matter, is to handle hardware interrupts so that user processes don't have to.)


[edit] And seriously, how hard is it to just link to the proper Windows function?
Last edited on
Topic archived. No new replies allowed.