Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualATC

Posted 27 October 2012 - 03:54 PM

Well, the bad news is, that code is STILL wrong.
The text screen video memory at that address takes WORDS, not bytes. Each word is a combination of a character to display and an attribute describing the color of the character and its background.


Ah, got me again... Oddly though, using char* did work, but in the real code I was padding it with the color information to write 16-bits for each char... But I looked at my text I/O implementation of a more mature version of my system project and saw that I actually used type unsigned short*, so you're correct. It's been a couple years though, like I said... so my memory of some things is a bit faded. Posted Image

Anyhow... about learning resources... It is indeed true that there are plenty books on OS development. But very few (in my experience) were suitable for beginners and even fewer actually teach how to write your first OS. Most books assume you're a CS major with system's programming experience and teach about OS design/architecture as opposed to the "how" and "why". So as a beginner OS programmer it's extremely difficult to find the learning resources you need. It's been a couple years since I did my OS project, so maybe things have changed; but that is the way I remember it.

Just reading ATC's response scared the everliving shit out of me, and I was not (and never would) consider trying to build a new OS.

Well, I'm off to have nightmares of implementing malloc and free...


Well, I didn't mean to scare ya lol! Posted Image

It's actually a lot of fun... and the feeling of overwhelming satisfaction you get from making the damn thing work for the first time was one of the most rewarding programming experiences I've ever had. Writing you own CSTDLib functions like malloc and free is also extremely rewarding. It's difficult and frustrating to get through it but when you get it working correctly you will be extremely happy and proud of yourself. Each time you call malloc or free you'll be grinning ear to ear knowing you made that code work. :-)

Even the little things like rolling your own strlen or strcmp functions are fun:

[source lang="cpp"]// Naive approach; just an example ::size_t strlen( const char* str ) { size_t len; char* ptr = (char *)str; for( len = 0x00; *ptr != '\0'; ++ptr, ++len ) ; return len;}[/source]

Seriously, you should try your hand at it! It's really challenging and entertaining to roll your own standard lib and try to write optimal routines and functions. And you'll walk away knowing 1000 fold more about C, C++, assembly language, the standard libraries and computer science.

One thing that was unique about my OS project is that I developed it completely within Visual Studio 2008 (Pro). Yes, you can indeed write an OS in Visual Studio! It's all about configuring the environment and project settings correctly, and either writing your own bootloader capable of handling your kernel/loader or implementing the multi-boot standard to make your OS interoperable with a good bootloader like GRUB.

I chose the latter approach, and used GRUB. And my kernel was actually a PE image (.exe file). The way I achieved interoperability with GRUB was by setting the base address of the PE image to the system loader's entry point, and using some assembly language tricks to emit the multi-boot header right there where GRUB would be expecting it. For example:

[source lang="cpp"]#define dd(x) \ __asm _emit (x) & 0xff \ __asm _emit (x) >> 8 & 0xff \ __asm _emit (x) >> 16 & 0xff \ __asm _emit (x) >> 24 & 0xff[/source]

That macro will actually embed a dword right into the code. So you can do this:

[source lang="cpp"]int _loaderMain( ){ dd( MB_MAGIC_NUMBER ); // ... and so on ...}[/source]

I also went so far as to write an entire static lib for handling PE images and reading their headers which could be linked right into the kernel or anything else that needed it. I implemented drivers as DLLs with a special *.DRV extension, and the OS loader (an intermediate loading program loaded by the bootloader that loaded the kernel and critical drivers) could us the "PELib" to read the kernel and driver headers. Just talking about it kinda makes me want to start playing with it all again, but I've got an engine to write lol. Posted Image

Regards,

--ATC--

#2ATC

Posted 27 October 2012 - 03:52 PM

Well, the bad news is, that code is STILL wrong.
The text screen video memory at that address takes WORDS, not bytes. Each word is a combination of a character to display and an attribute describing the color of the character and its background.


Ah, got me again... Oddly though, using char* did work... But I looked at my text I/O implementation of a more mature version of my system project and saw that I actually used type unsigned short*, so you're correct. It's been a couple years though, like I said... so my memory of some things is a bit faded. :P

Anyhow... about learning resources... It is indeed true that there are plenty books on OS development. But very few (in my experience) were suitable for beginners and even fewer actually teach how to write your first OS. Most books assume you're a CS major with system's programming experience and teach about OS design/architecture as opposed to the "how" and "why". So as a beginner OS programmer it's extremely difficult to find the learning resources you need. It's been a couple years since I did my OS project, so maybe things have changed; but that is the way I remember it.

Just reading ATC's response scared the everliving shit out of me, and I was not (and never would) consider trying to build a new OS.

Well, I'm off to have nightmares of implementing malloc and free...


Well, I didn't mean to scare ya lol! Posted Image

It's actually a lot of fun... and the feeling of overwhelming satisfaction you get from making the damn thing work for the first time was one of the most rewarding programming experiences I've ever had. Writing you own CSTDLib functions like malloc and free is also extremely rewarding. It's difficult and frustrating to get through it but when you get it working correctly you will be extremely happy and proud of yourself. Each time you call malloc or free you'll be grinning ear to ear knowing you made that code work. :-)

Even the little things like rolling your own strlen or strcmp functions are fun:

[source lang="cpp"]// Naive approach; just an example ::size_t strlen( const char* str ) { size_t len; char* ptr = (char *)str; for( len = 0x00; *ptr != '\0'; ++ptr, ++len ) ; return len;}[/source]

Seriously, you should try your hand at it! It's really challenging and entertaining to roll your own standard lib and try to write optimal routines and functions. And you'll walk away knowing 1000 fold more about C, C++, assembly language, the standard libraries and computer science.

One thing that was unique about my OS project is that I developed it completely within Visual Studio 2008 (Pro). Yes, you can indeed write an OS in Visual Studio! It's all about configuring the environment and project settings correctly, and either writing your own bootloader capable of handling your kernel/loader or implementing the multi-boot standard to make your OS interoperable with a good bootloader like GRUB.

I chose the latter approach, and used GRUB. And my kernel was actually a PE image (.exe file). The way I achieved interoperability with GRUB was by setting the base address of the PE image to the system loader's entry point, and using some assembly language tricks to emit the multi-boot header right there where GRUB would be expecting it. For example:

[source lang="cpp"]#define dd(x) \ __asm _emit (x) & 0xff \ __asm _emit (x) >> 8 & 0xff \ __asm _emit (x) >> 16 & 0xff \ __asm _emit (x) >> 24 & 0xff[/source]

That macro will actually embed a dword right into the code. So you can do this:

[source lang="cpp"]int _loaderMain( ){ dd( MB_MAGIC_NUMBER ); // ... and so on ...}[/source]

I also went so far as to write an entire static lib for handling PE images and reading their headers which could be linked right into the kernel or anything else that needed it. I implemented drivers as DLLs with a special *.DRV extension, and the OS loader (an intermediate loading program loaded by the bootloader that loaded the kernel and critical drivers) could us the "PELib" to read the kernel and driver headers. Just talking about it kinda makes me want to start playing with it all again, but I've got an engine to write lol. Posted Image

Regards,

--ATC--

#1ATC

Posted 27 October 2012 - 03:49 PM

Anyhow... about learning resources... It is indeed true that there are plenty books on OS development. But very few (in my experience) were suitable for beginners and even fewer actually teach how to write your first OS. Most books assume you're a CS major with system's programming experience and teach about OS design/architecture as opposed to the "how" and "why". So as a beginner OS programmer it's extremely difficult to find the learning resources you need. It's been a couple years since I did my OS project, so maybe things have changed; but that is the way I remember it.

Just reading ATC's response scared the everliving shit out of me, and I was not (and never would) consider trying to build a new OS.

Well, I'm off to have nightmares of implementing malloc and free...


Well, I didn't mean to scare ya lol! :P

It's actually a lot of fun... and the feeling of overwhelming satisfaction you get from making the damn thing work for the first time was one of the most rewarding programming experiences I've ever had. Writing you own CSTDLib functions like malloc and free is also extremely rewarding. It's difficult and frustrating to get through it but when you get it working correctly you will be extremely happy and proud of yourself. Each time you call malloc or free you'll be grinning ear to ear knowing you made that code work. :-)

Even the little things like rolling your own strlen or strcmp functions are fun:

[source lang="cpp"]// Naive approach; just an example ::size_t strlen( const char* str ) { size_t len; char* ptr = (char *)str; for( len = 0x00; *ptr != '\0'; ++ptr, ++len ) ; return len;}[/source]

Seriously, you should try your hand at it! It's really challenging and entertaining to roll your own standard lib and try to write optimal routines and functions. And you'll walk away knowing 1000 fold more about C, C++, assembly language, the standard libraries and computer science.

One thing that was unique about my OS project is that I developed it completely within Visual Studio 2008 (Pro). Yes, you can indeed write an OS in Visual Studio! It's all about configuring the environment and project settings correctly, and either writing your own bootloader capable of handling your kernel/loader or implementing the multi-boot standard to make your OS interoperable with a good bootloader like GRUB.

I chose the latter approach, and used GRUB. And my kernel was actually a PE image (.exe file). The way I achieved interoperability with GRUB was by setting the base address of the PE image to the system loader's entry point, and using some assembly language tricks to emit the multi-boot header right there where GRUB would be expecting it. For example:

[source lang="cpp"]#define dd(x) \ __asm _emit (x) & 0xff \ __asm _emit (x) >> 8 & 0xff \ __asm _emit (x) >> 16 & 0xff \ __asm _emit (x) >> 24 & 0xff[/source]

That macro will actually embed a dword right into the code. So you can do this:

[source lang="cpp"]int _loaderMain( ){ dd( MB_MAGIC_NUMBER ); // ... and so on ...}[/source]

I also went so far as to write an entire static lib for handling PE images and reading their headers which could be linked right into the kernel or anything else that needed it. I implemented drivers as DLLs with a special *.DRV extension, and the OS loader (an intermediate loading program loaded by the bootloader that loaded the kernel and critical drivers) could us the "PELib" to read the kernel and driver headers. Just talking about it kinda makes me want to start playing with it all again, but I've got an engine to write lol. :P

Regards,

--ATC--

PARTNERS