Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

System library versus standard library

  1. Sep 17, 2010 #1
    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()?
  2. jcsd
  3. Sep 17, 2010 #2
    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 alot 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.
  4. Sep 17, 2010 #3
    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.
  5. Sep 17, 2010 #4
    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.
  6. Sep 17, 2010 #5
    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.
  7. Sep 17, 2010 #6
    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.
    Last edited: Sep 17, 2010
  8. Sep 17, 2010 #7
    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.
  9. Sep 17, 2010 #8
    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.
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook