You sound to me like you are learning from terrible resources.
Almost everything you've said reeks of misinformation.
If you have a modern Windows computer, you are not running DOS. DOS does not exist on your system. The "command prompt" program which runs on your computer is a shell. You can run programs in it and perform some other rudimentary tasks as expected. It's actually terribly inadequate, but it's Windows.
Let me explain explain the standard POSIX `system ()' function:
This is NOT a "system call". I see why you might think that, but system () is a POSIX and standard C function.
It is equivalent (on standard systems) to running the default shell (named `sh'), with the flag "-c", and command as the c-string passed to it. (It executes it's argument in the shell). But Windows is a special child.
On Windows, it spawns a new process, directly equivalent to issuing
cmd.exe /c [arg1]
On a standard system, the difference appears mostly cosmetic:
sh -c arg1
This technique is generally called "shelling out". It's sometimes useful because it reduces functional duplication, complexity, hides information, and is otherwise generally good practice, if you can get away with it. Under Windows, it's more slow and dangerous than usual. Other than the value returned from the shell, there is no way to receive information from the program retrieved.
So that's system().
A system call is totally different. It's the bridge between the kernel and your program. Your implementation of the C standard library, the Win32 API, etc. make calls to these functions as provided by the kernel. You cannot implement them yourself. Examples include _sopen_s (), _wopen () _telli64 (), etc.
Here is the documentation for _sopen_s ().
http://msdn.microsoft.com/en-us/library/w64k0ytk.aspx
Most programs would never need to invoke those calls directly. They are backward, error-prone, non-standard, terribly complicated, and offer no benefits in most cases.
"But C Standard Library says nothing about Networking and GUI. I thought we have to create separate libraries ourselves, but i don't even know where to start to create GUI or Networking stuff!"
No, it doesn't. C is a systems programming language, for one.
You're a fool if you try to create those libraries yourself! (and expect to get anything done)
If you're using C, you would start by invoking the WinAPI, for GUI, or Winsock (a twisted, nonstandard implementation of BSD Sockets) for networking.
Listen:
I could continue, but you're looking to write everything down to the circuitry. While _fun_, you need to decide what your goals are, focus on learning the language, and then re-approach learning how exactly GUI shows up on the screen.
The last paragraph of your (series of) question(s) is an absolute engineering travesty. There is a humongous disconnect between the skill implied by that paragraph and the skill required to do what you are implying.
Information hiding is the only sane way to accomplish anything. Taking what you have said to the extreme, you should not be writing C, you should be hacking Assembly, or rather running a hex editor, entering bytes of machine code from the processor datasheet next to you.
I strongly suggest reading some of these. I stripped out many of them not directly applicable. They are all good.
1. ) Robert C. Martin -- Clean Code: A Handbook of Agile Software Craftsmanship
2. ) The GOF (Erich Gamma et al) -- Design Patterns: Elements of Reusable Object-Oriented Software
3. ) Steve McConnel -- Code Complete: A Practical Handbook of Software Construction, Second Edition
5. ) Frederick Brooks -- The Mythical Man-Month: Essays on Software Engineering
9. ) Eric S. Raymond -- The Art of Unix Programming
13. ) Thomas & Hunt -- The Pragmatic Programmer
18. ) Donald Knuth -- The Art of Computer Programming (a reference: which I don't own, I get the library's copy)
Hacking around in the bits is fun... building your own OS is fun... But it's _hard_! Learn first!
If you want, send me a message via YA.