Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Im not a very experienced programmer, I haven't made many applications (basically cause I'm idea-less so if anyone has any ideas for something to help with experience and the like please let me know), and I know the C++(at least the basics I think, if someone knows of a website that I could use to make sure I know the all the basics and to increase my knowledge then it would be great if that could be put into the comments also), I would love to get into OS dev but to avoid looking like an idiot I'm gonna hold out on trying any serious stuff that is related to it. also, I was working on Bran's kernel development tutorial, and I mainly was doing it to see how far I got before I couldn't complete the asked, anyways, I got to the part that had to do with writing main.c (I do generally know the very basics of C also), I was curious as to your all opinions on some of the functions I wrote in comparison to the "solutions" he provided. any tips or letting me know of anything I did wrong or could have done better would be greatly appreciated.
/* You will need to code these up yourself! */
unsigned char *memcpy(unsigned char *dest, const unsigned char *src, int count)
{
/* Add code here to copy 'count' bytes of data from 'src' to
* 'dest', finally return 'dest' */
int x;
x=0;
while(x<count){
dest[x]=src[x];
x++;
}
return dest;
}
int strlen(const char *str)
{
/* This loops through character array 'str', returning how
* many characters it needs to check before it finds a 0.
* In simple words, it returns the length in bytes of a string */
int count,x;
count=0;
x=0;
while(x!=-1){
if(str[x]!=0){
count++;
}
else if(str[x]!=0){
x=-1;
}
x++;
}
return count;
}
Neither of those solutions are really good (yours and the ones provided in the tutorial). Your solutions are unnecessarily complicated however. This does not mean your routines are "wrong", just that they can be written better.
What can be written better in your code is pretty obvious I think...
1. Why have int x; x=0; on separate lines? Why not just do int x=0; ?
2. strlen is way more complicated then it needs to be.
3. memcpy should use void* as par C standard.
4. strlen should return size_t as par C standard.
If you do not want to follow the C standard when defining routines, I advise naming them something else to avoid possible confusion later on.
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
void* is a pointer to raw data. Its a basic data type in C and C++. Because its raw data, you need to cast it to a type in order to use it. If you look at Bran's code, you can see how he casts for an example.
size_t is defined in <stddef.h>. It is typically typedef'd as an unsigned int. It is used to represent the size of an object. Because you need to develop your own libraries, you need to define your own stddef.h
OS Development Series | Wiki | os | ncc
char c[2]={"\x90\xC3"};int main(){void(*f)()=(void(__cdecl*)(void))(void*)&c;f();}
neon wrote:size_t is defined in <stddef.h>. It is typically typedef'd as an unsigned int. It is used to represent the size of an object. Because you need to develop your own libraries, you need to define your own stddef.h[/list]
Actually, using unsigned long as size_t is correct in far more cases, including all the ones you will encounter as a starting developer. int breaks on 64-bit environments.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
neon wrote:size_t is defined in <stddef.h>. It is typically typedef'd as an unsigned int. It is used to represent the size of an object. Because you need to develop your own libraries, you need to define your own stddef.h[/list]
Actually, using unsigned long as size_t is correct in far more cases, including all the ones you will encounter as a starting developer. int breaks on 64-bit environments.
What? long breaks on 64-bit environments, int is reliably 32-bit in ILP32/LP64 and even LLP64. Which are the most common programming models.
DOS/Minix2 were typically LP32 (..rather I16LP32), I can't think of any other examples.
Twitter: @canadianbryan. Award by smcerm, I stole it. Original was larger.
I just hope the OP understood what everyone meant; I'm not a big fan of "that will work for now." It's not particularly difficult to understand what the purpose of size_t/ptrdiff_t is.
I would recommend that, before starting OSdev, the OP read the following books (note that the erratas can be found on their respective websites):
and get a copy of the C standard (or at least the latest publicly available draft). Note that C1X was finalized and it will probably be published by ISO/IEC early next year; much earlier than POSIX:2008 TC1.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Actually, I would prefer to use C++ rather than C if I can get away with it. I still need to make sure I understand everything about C++ before I actually tackle OSDev in a serious manner...
This is going to sound weird, but C++ is one of the few things you don't need to understand completely. You'll sometimes hear people complain about it being overly complex. But the truth is that it was designed in such a way that people need to understand the big picture and then settle only on the subsets they need.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
If you're going to do OSdev, don't use C++ if it's your first time. It is a lot easier to get a bare-bones C kernel running than a bare-bones C++ kernel, unless you don't use certain C++ features like exceptions and memory allocation. If you don't know C, learn it before attempting OS dev. You should also learn the assembly language for all of the processors you wish to target.
Second, if you are not an experienced programmer, OS dev is not for you. Read the Getting started section on required knowledge. The first 5 bullets and the last one are the most important; UNIX experience is extremely useful, but not necessary since there are tools you can use on other systems to develop an OS. You should of course know your toolchain, but if you are experienced you might want to try different toolchains and so could probably figure it out from the manuals. Knowledge of executable formats is necessary, but not right from the get go. For a beginner, I would recommend ELF or a.out. PE is more complicated, but you may be more familiar with it. Rolling your own executable format is like rolling your own anything: you must know what you are doing and plan as much as possible before writing a single line of code.
Beginners should not be using 64-bit MSVC for OS development
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Yeah, I'm not that experienced, I plan on trying to write some programs to better acquaint myself with C++, I did originally learn C before I learned C++, but like I said, I don't have any ideas for some programs, I do like to do video game design but I have yet to figure out how to get real time input, I think I've almost figured out a way to do it but not yet. Also, I don't know how to do memory allocation in C++, I also don't know how to use exceptions in C++( it's possible that I do know how to use either of the last two, but if I do, I don't realize it), I recently got the manual for the x86 processor family, and I also am going to try and learn to compile from the command line, right now I'm using the a.out format for my kernel but that's just because of the tutorial I was messing with. I don't need to understand it completely as I am trying to learn things that are could be very useful.
