C++ header files

[engine252]

If i want to use stdio.h in my kernel, i have to write it myself...why ???

and do i have to wright it in asm then. becouls i can't figure out a way in c++

and is there a good recource for asm somewhere?
does anyone have some good pdf files on asm
i know thats alot to ask but i am new and i want to learn fast.

[Tom]

I have a "fstdio.h" file, that's a stdio.h file, the F is for FritzOS.

It has alot of functions, but not all. I hope you'll find it useful.

You can even just include my whole file instead of editing anything...to just keep it simple.

download it here:
http://sourceforge.net/project/showfiles.php?group_id=58434&release_id=101327

[Mr_Spam]

most if not all of the functions in stdio.h wont work just like the dos interrupts wont work (in your other post). You have to write you own, or borrow if there nice enough

[engine252]

what do i have to do then

let's say i want to use printf

do i have towrite a function printf or can i use the headerfile stdio.h

i don't get it, when you include a header it should compile with the program not? let's say i get a header
file from someone else what then i never had to wright
my own headers before help me

do i have to compile these headers and how can i make them work in my kernel.

if anyone can give my a good example or a tutorial i'm happy to learn ? ???

[Tom]

[attachment deleted by admin]

[Mr_Spam]

what it is is that when you use most of the funtions in the premade libary in your C/C++ compiler, those functions make some kind of system call to the operating system, it be DOS, Windows, Unix ect. When you use that same funtion in your OS, the code tries to make that same system call but since that operating system is not currently running, the code is useless and dosn't do anything. you have to rewrite those functions to either fit your system calls, or bypass them entierly.

I think most of us (hobbyist OS developers) at this point are just pretty much bypassing all those system calls. when the printf function is used in windows for example, it sends whats to be displayd to the standard output buffer, making system calls to windows to do that. i think most of our OS's dont have a standard output buffer, atleast of yet so we write directly to the video ram. i hope that makes sence.

[PlayOS]

Hi,

OK engine252, Including yourstdio.h will do absolutely nothing for you, you must write an implementation for the functions you will be using. Header files are mainly only for the development tools, they never actually become a part of your binary code (with the exception of local variables or extern variables decalred in there), the reason you need a function prototype (which is what the header file is mainly used for) is so that the compiler and/or linker knows what functions you have used in your code, for example if you have a simple c++ program like this:

Code: Select all

  #include <iostream.h>

  void main()
  {
       cout << add(6, 5) << endl;
       cout << mul(9, 15) << endl;
  }

  int add(int x, int y)
  {
       return x + y;
  }

  int mul(int x, int y)
  {
       return x * y;
  }

If you tried to compile this you would get at least 2 errors, the compiler would complain about the use of add() and mul() because at this point in the file they have not been defined, the compiler knows nothing about them, however if you add these next two lines before the main() function, then everything will work.

Code: Select all

    int add(int x, int y);
    int mul(int x, int y);

You see the compiler and linker dont care about where your function code is, as long as they know about it when it is called and as long as it is compiled into the program somewhere.

So you can use yourstdio.h but you will need to write the function code that will actually be called. If you use Tom's header then you can also find his stdio.c (He will not mind, I dont think) and compile that with your code, and as long as it is written properly you should be ok, just remeber any function that has system calls in it, will mean you will need to support those calls before you can use it.

Personally I think that you are too new to programming to be starting an OS, I believe that anyone can learn, but you should at least be able to understand header files, what they do, how they work, etc...

Anyway, I hope that I have cleared this up, no doubt you will probably have more questions.

Good Luck!

[engine252]

so if i get it wright all my header files that come with my compiler are useles.
right,that means i have to write a dozen of functions with the system calls of the normal functions.

ok is there some info on that subject somewhere
becuals i get a little stuck there.

[PlayOS]

Basically yes

You have to port just about all of the standard c\c++ libraries to your OS if you want to use them.

[Schol-R-LEA]

There seems to be some confusion about the nature of the C preprocessor [tt]#include[/tt] directive, and use of the header files.

When you use [tt]#include[/tt], it inserts a copy of the file named after it directly into the text of the source code, at exactly the point where the [tt]#include[/tt] occurs. This means that if I have three files, [tt]foo.h[/tt], [tt]foo.c[/tt], and [tt]bar.c[/tt],

Code: Select all

/* foo.h - global declarations for foo */
#ifndef __FOO__       
#define __FOO__ 1

extern int narf;

void foo(int baz, char quux);  // prototype for foo() 

#endif

Code: Select all

/* foo.c - a function to foo around with */

#include <stdlib.h>
#include "foo.h"  // note that user-defined headers use quotes, not angle brackets

int  narf;

#include "foo.h"  // oops, put it twice by mistake

void foo (int baz, char quux)
{
   int bloop;
   
   bloop = atoi(quux);
   narf += (baz * bloop);
}

Code: Select all

/* bar.c - a note to follow foo() */
#include "foo.h"

int bar()
{
   foo (10, "123");
   return (narf / 2); 
}

What the compiler actually sees when compiling [tt]foo.c[/tt] and [tt]bar.c[/tt] is:

Code: Select all

int   atoi(const char *_s);
void   exit(int _status) __attribute__((noreturn));
void   free(void *_ptr);
char *   getenv(const char *_name);
void *   malloc(size_t _size);
void   qsort(void *_base, size_t _nelem, size_t _size,
         int (*_cmp)(const void *_e1, const void *_e2));
int   rand(void);
void *   realloc(void *_ptr, size_t _size);
void   srand(unsigned _seed);
int   system(const char *_s);

extern int narf;

void foo(int baz, char quux);

int  narf;

void foo (int baz, char quux)
{
   int bloop;
   
   bloop = atoi(quux);
   narf += (baz * bloop);
}

Code: Select all

extern int narf;

void foo(int baz, char quux);

int bar()
{
   foo (10, "123");
   return (narf  / 2); 
}

(The example [tt]stdlib.h[/tt] was taken from DJGPP; for space reasons, only a small part of the [tt]#include[/tt]d declarations are shown.)

Note that foo.h has the whole header surrounded by a conditional compilation statement, which checks to see if the file has been included in this compilation unit already. If it didn't then the accidental duplicate [tt]#include[/tt] in [tt]foo.c[/tt] would have declared [tt]narf[/tt] and [tt]foo()[/tt] twice, leading to a compilation error.

The role of the header files should now be clearer: it is meant to allow external references to be added automatically to multiple compilations, so that the compiler knows what the types of the external references, and what external linkages it needs to account for in the object code. It is not used by the linker, nor does it referenced by the compiler directly.

Note that this usage is not enforced; you can put any kind of valid C/C++ code in a header file if you wish. However, it is an extremely bad practice to put anything in a header except global constants, external declarations, and function prototypes, as the purpose is to allow separately compiled functions to be declared consistently in every file that refers to them. It is a good practice to [tt]#include[/tt] a C source file's own header in the source file, to ensure agreement between the prototype and the actual function, but there is nothing that requires you to do it.

The compiler treats the standard libary header files different from user-defined headers in only one way: the standard library headers are [tt]#include[/tt]d using angle brackets around the header name, while user-defined headers have double-quotes around the file name (C++ goes one step further, and omits the file extension on standard headers, to differentiate them from the equivalent C headers).

For further enlightenment, try running cpp (the preprocessor utility) over some program files and review the results.

[PlayOS]

Just to clarify, I never intended to say the the preprocessor directives were seen by the compiler or linker, I was saying that the compiler sees what is in the header file, which can be seen by simply trying to compile my little example. Without the function prototypes, which should come from a header file, the compiler complains, why? Because it dosen't know about the function, unless the function has been defined before hand. So the compiler is very concerned about what is found in header files (once they have been inserted into the code file), you are right however, the linker definately does not see, know or care about header files, it is only concerned with symbols.

Sorry for the confusion.

[Schol-R-LEA]

My apologies, PlayOS. I was mainly meaning that for engine252 and Tom, who seemed to have some misunderstandings on the topic. Of those who had posted, you seemed to be the one who already understood things correctly (Mr_Spam understood about the system calls being different from OS to OS, but I wasn't sure if he had all the details about the [tt]#include[/tt] directive down). The preprocessor, while a powerful tool, is also the source of tremendous confusion, even among experienced C programmers, and I have gotten into the habit of explaining it whenever that seemed to be the case. I had no intention of seeming patronizing, and I regret it if I did.

[PlayOS]

No need to apologise, I know from all your previous posts that I have seen, you like people to know what is right and what is wrong, this is a good thing. You seem to have a lot of knowledge on programming and I make sure that I read your posts well, so that I understand what you are saying. You have definately shown yourself to be an asset to this forum, and I have been helped by your advice many times.

Keep up the good work.