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...

It's much easier to make a program act as if it were a real operating system (to some sort) than an actual operating system(and a lot more bearable as well).

And I don't think your terminology of "virtual" to "real" operating systems makes sense.

An operating system running on a virtual machine is still a "real" operating system, as it would generally carry the same instructions that would be used otherwise on real hardware directly, rather than a program acting like a virtualized version of real hardware itself.

And if you're really that eager to see how they made the video, contact them on their YouTube account.

Someone else can propose an idea, guess, or maybe know, but it's hard to tell based on just a video as to what program was used to make it.

If you want to make an operating system for real, however, you have a lot of learning to do.

Even though an operating system is still software, it's not the same as compile-and-go "Hello world!" that can be accomplished and executed in less than a minute from scratch(with the right programs, input speed, files and knowledge ready).

Actually, that address is a holdover of realmode, not protected mode. While still mapped (up to a point) when you switch to protected mode, it does not need to, nor usually will, remain mapped to that address range. Furthermore, if you have enabled paging then that code could be doing all sorts of nasty things to the byte at 0xB8000. Additionally, your code only affects a single byte of memory, and thus doesn't actually print your string so much as it puts '!' to the byte at address 0xB8000.

Yes, sorry, I screwed up my code... The original version I wanted to post from one of my first working OS kernels is this:

char* screen = (char *) 0xB8000;

const char* str = "Hello, OS world!\0";

for( int index = 0; str[index] != '\0'; ++index)
screen[index] = str[index];

EDIT: I figured out why my code was getting screwed up... if you're using a variable named "i" as an array index the forums interprets it as italics lol! So now I fixed it so the code is correct.

However, when I tried to post it with the code/source tags it came out screwed up and was unreadable (for some reason the forums don't like array indexing [x] symbols in code/source tags)! So I tried to modify it to make it readable using just pointer arithmetic but it looks like I actually just screwed it up (never incremented "screen" so, you're right) lol. I will fix the original example; thanks for pointing it out! Was very tired last night!

And yes, you're right... it is real-mode. Sorry for that mix-up too! But I was simply demonstrating how physical RAM can be manipulated in Ring-0 without causing a crash, and how to make a basic "Hello world" kernel work. You obviously wouldn't want to use this code in a real/practical OS project. It's just a contrived example to make a point. ;)

[quote name='Washu' timestamp='1351326247' post='4994367']
Actually, that address is a holdover of realmode, not protected mode. While still mapped (up to a point) when you switch to protected mode, it does not need to, nor usually will, remain mapped to that address range. Furthermore, if you have enabled paging then that code could be doing all sorts of nasty things to the byte at 0xB8000. Additionally, your code only affects a single byte of memory, and thus doesn't actually print your string so much as it puts '!' to the byte at address 0xB8000.

Yes, sorry, I screwed up my code... The original version I wanted to post from one of my first working OS kernels is this:

char* screen = (char *) 0xB8000;

const char* str = "Hello, OS world!\0";

for( int index = 0; str[index] != '\0'; ++index)
screen[index] = str[index];

EDIT: I figured out why my code was getting screwed up... if you're using a variable named "i" as an array index the forums interprets it as italics lol! So now I fixed it so the code is correct.

However, when I tried to post it with the code/source tags it came out screwed up and was unreadable (for some reason the forums don't like array indexing [x] symbols in code/source tags)! So I tried to modify it to make it readable using just pointer arithmetic but it looks like I actually just screwed it up (never incremented "screen" so, you're right) lol. I will fix the original example; thanks for pointing it out! Was very tired last night!

And yes, you're right... it is real-mode. Sorry for that mix-up too! But I was simply demonstrating how physical RAM can be manipulated in Ring-0 without causing a crash, and how to make a basic "Hello world" kernel work. You obviously wouldn't want to use this code in a real/practical OS project. It's just a contrived example to make a point. ;)
[/quote]
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.

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.

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!

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.

Regards,

--ATC--

To demonstrate what Washu is talking about, a correct example of what I was trying to demonstrate earlier would be more like this::

[source lang="cpp"]
void _writeText( const char* str ) {

int index = 0x00;
char* pstr = (char *)str;
unsigned short *vidMem = (unsigned short *)0xB8000;

for( ; *pstr; ++pstr, ++index )
{
unsigned char c = *pstr;

vidMem[index] = (unsigned short) c | 0x0700;
}
}
[/source]

Sorry for screwing this up multiple times trying to make a simple point lol... Like I said, it's been years and I can't copy code from any of my projects verbatim because there's a lot of code, headers, macros and functions used in numerous files and it wouldn't make sense without posting it all (overkill for such a small, contrived example). So I just have to either try to strike up examples from memory or write a new, simplified version; as it so happened I did that wrong, lol...

Hopefully this time I did the demonstration correctly haha