OSDev Series Chapter 23 has been released. It covers user mode, TSS, and System API topics. Sorry, no demo yet do to series updates. Everything should be updated by this week including additional content added to this chapter.

Single tasking has been moved to the next chapter, which will cover Loaders in detail: including information on shared resources and PE loading.

OSDev Series Chapter 23 has been released. It covers user mode, TSS, and System API topics. Sorry, no demo yet do to series updates. Everything should be updated by this week including additional content added to this chapter.

Single tasking has been moved to the next chapter, which will cover Loaders in detail: including information on shared resources and PE loading.

Thanks a lot. Bummer about single tasking -- I was looking forward to it. But I can wait!

[edit]I just noticed you added the new/changed file list this time -- thanks a lot!

on "copy kernel"you use: 0xC0000000 1100000000 0000000000 000000000000 PDE=3 pointing to ????? There is not any entry at position 3 (only 0 and 768) PTE=0 pointing to 0 PAGE Offset=0 starting from first byte of that page...

This 4088 bytes is physical memory map. Each bit in this area of bytes shows the state of physical memory block (each 4KB in size) (e.g. first bit of first byte 0 => your first 4KB are free for use, 1 => it is already used, or not used if memory region type is not available). So, to store information of 8 memory blocks will be enough 8 bits => BLOCKS_PER_BYTE = 8; If you try run it on other machine with other amount or RAM number of bytes written right after kernel will be different.

But I can't understand, why 0x0F? Shouldn't it be 0xFF? I use 0xFF instead 0x0F and everything works fine.

Thinking of great - thinking of little, thinking of little - thinking of great.

its seems to me that is a bug, since a 8 block is represented by a byte... and it works fine in any fashion because we haven't much use of memory. But it seems that you are right and should be 0xFF

On dealing with BIOS region, why Mike sets it as a free blocks of memory? it's not supposed to be marked as "in use" memory? (see pmmngr_init_region)...just like he did with kernel region; he left it marked (in use)... (see pmmngr_deinit_region)...and other memory blocks is left marked as "in use" - why? ...is not supposed that, at this stage, only BIOS data area and, of course, the Kernel, has to be marked?

I guess we don't need IVT anymore, while we are in protected mode. (And it is [0x00 - 0x3FF] region of memory). You can set it as in use, but think before: will you use it? The only BIOS area that lefts untouchable - Extra Bios Data Region and ROM area (because type of that regions is Reserved, so that regions are set as busy). And talking about 8 memory blocks per byte: it's not a bug, it is normal way: to store information about 4GB of physical memory you jest need 128KB. You even shouldn't allocated more than one page. Of course, if you go with PAE (Physical Address Extension) you have to find another way. But I really don't think you Virtual Machine has at least 4 GB of RAM =))

Thinking of great - thinking of little, thinking of little - thinking of great.

djsilence wrote:I guess we don't need IVT anymore, while we are in protected mode. (And it is [0x00 - 0x3FF] region of memory). You can set it as in use, but think before: will you use it? The only BIOS area that lefts untouchable - Extra Bios Data Region and ROM area (because type of that regions is Reserved, so that regions are set as busy). And talking about 8 memory blocks per byte: it's not a bug, it is normal way: to store information about 4GB of physical memory you jest need 128KB. You even shouldn't allocated more than one page. Of course, if you go with PAE (Physical Address Extension) you have to find another way. But I really don't think you Virtual Machine has at least 4 GB of RAM =))

i was not talking about IVT... I was talking about the information stored in (memory_region*)0x1000 with function 0x15 (eax=0xe820) (Originally introduced with the Phoenix BIOS v4.0)