System library versus standard library

[RedX]

Is fcntl.h more fundamental than stdio.h?

Using just stdio.h, I can define a FILE type, and use an fopen() command to open a file and return the address of the file into the FILE variable.

Using fcntl.h, I use open() instead of fopen(), and instead of returning a FILE type, open() returns an integer that's called a file descriptor.

fcntl.h I believe is only for Linux, while stdio.h is for any operating system that runs C.

Would I be correct in saying that each operating system has to write their own stdio.h that meets C standards, and Linux uses fcntl.h to do that, while Windows uses windows.h?

So if I look at stdio.h for Linux, it would define fopen() in terms of open() from fcntl.h, and similarly with Windows except using Window's version of an open() command to define fopen()?

 

[airborne18]

Back in the day with DOS, you had several file methods, but streams were the standard. It was a debate for a while and streams won. You will notice that stdio has a lot of macros. That is because everything is a file stream.

Windows eventually went away from streams, and everything was a handle. But for a long time windows supported the all of the DOS and low level IO methods.

It has actually evolved beyond Handles in windows, and now security at both the object level and the driver level is being emphasized. You cannot easily access the disk at the sector level.

But yes you have the concept. Somewhere every iteration of C for each operating system has it own core internals and the standard libraries are the common interface.

Keep in mind that it is impossible to write portable code in C. Unix and Windows are too far apart. And so is the MAC. Though basic file IO is not something that really needs to be hard.

Some of the benefits to not using the stdio is when you are taking advantage of tasking and asynchrounous file IO. But Unix really does not emphasize that, OS/2 and Windows do, though even that has evolved a bit.

 

[airborne18]

The whole idea and beauty of streams is that you can capture and redirect streams. That is where stdin, stdout, stderr come into play. In Unix and Dos for that matter you create small programs and you link them together on the command line.

 

[RedX]

But yes you have the concept. Somewhere every iteration of C for each operating system has it own core internals and the standard libraries are the common interface.

Keep in mind that it is impossible to write portable code in C. Unix and Windows are too far apart. And so is the MAC. Though basic file IO is not something that really needs to be hard.

I'm slightly confused here. If your program only uses standard libraries, then it ought to be portable right? The pre-processor will look for <stdio.h> wherever your operating system stores it under its file management, find it and then paste it into your program. It is not the programmer's responsibility to make sure that the version of <stdio.h> for a particular operating system will produce the correct results.

So it seems to me that source code should be portable if you stick to C-standard libraries.

Executable code might not be portable though, since different operating systems have different executable formats.

But before compiling and linking, it seems to me that <stdio.h> should be <stdio.h> functionally, although the internals would be different and particular to each OS, because the makers of the OS made it that way so people would use their OS.

 

[airborne18]

It is portable, but are you going to write command line programs your entire life? Yes you can write a command line windows program that will also be a command line program in Unix.

Yes the source code is portable, but not very useful. The point in windows is not to write command line programs. They exist for very specific purposes, but you want to write Windows based programs.

So yes, but the C standard libraries are not flashy programs that people actually write for commerical purposes. That is what I mean.

 

[RedX]

It is portable, but are you going to write command line programs your entire life? Yes you can write a command line windows program that will also be a command line program in Unix.

Yes the source code is portable, but not very useful. The point in windows is not to write command line programs. They exist for very specific purposes, but you want to write Windows based programs.

So yes, but the C standard libraries are not flashy programs that people actually write for commerical purposes. That is what I mean.

But in principle, can one construct flashy functions built out of only the standard C libraries, and then by using only those functions, make it portable? Or is the only way to make flashy functions is to use OS-specific functions provided by the OS-manufacturers?

I vaguely recall that in C there is a standard library called graphics.h, and since it is a standard library it should be available in Mac and Unix too.

I guess what I'm trying to say is that with computers, you can sort of get self-assembly. Using already existing functions, you build a function slightly more flashy. Once you have these functions, you use them to build something more flashy. But the reward if you keep doing this is something that is portable, since it is built out of only the standard C library. But I guess then you will be reinventing the wheel, and you might as well just create your own operating system using standard C.

 

[airborne18]

There are no flashy windowing in the standard libraries ( ANSI ). Throughout the years there have been many third party libraries that have attempted to build cross platform windowing and graphics libraries. For C++ you will find them. But they have never caught on, simply because each paradigm is different enough that you give up too much naitive functionality.


graphics.h should not be a std library.. not ANSI. Dos had it, but I do not believe that windows has it.

Windows uses the GDI for graphics.

The best you can do with the standard libs is a text based windowing system that uses Escape sequences, and that is more trouble than it is worth.

 

[airborne18]

This issue is the reason people like the java concept, and the .net type frameworks where there is a psuedo compiled opcode chunk that is platform indepdent.