<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent posts to blog</title><link>https://sourceforge.net/p/bootdebug/blog/</link><description>Recent posts to blog</description><atom:link href="https://sourceforge.net/p/bootdebug/blog/feed.rss" rel="self"/><language>en</language><lastBuildDate>Sun, 16 Mar 2014 04:32:09 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/bootdebug/blog/feed.rss" rel="self" type="application/rss+xml"/><item><title>A strange corner of the world</title><link>https://sourceforge.net/p/bootdebug/blog/2014/03/a-strange-corner-of-the-world/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;BootDebug came about via a number of interesting reasons dating back all the way into the mid 90s. Back in the day I liked to dig around with how the internals of computers worked, learning assembly, understand the hardware and crazy things like Protected Mode. For much of what I was doing the classing DEBUG in DOS was an invaluable tool, using it I was able to understand quite a bit of what the computer did. For everything else I ended up writing my own boot loader so I could make small programs that could poke at the system in a number of interesting ways.&lt;/p&gt;
&lt;p&gt;Twenty years on such exploration is no where near as easy. Modern OSes hide much of what is going on behind the scenes using protection levels and memory mapping. If you really want to do understand how the hardware is really working you have to step around the OS to do it. You can't just jump back to something like DOS to do it as it doesn't have full access to the system. &lt;/p&gt;
&lt;p&gt;Of course that's not why I started writing what would become BootDebug, mostly it was a way to play around with GRUB and some of the features in it as well as getting Visual C++ to work with it. Once I started to boot successfully I started wondering what else could I do and how parts of the system worked (as well as what Protected mode features a modern BIOS offers).&lt;/p&gt;
&lt;p&gt;As for why I'm using the Microsoft tool chain for this instead of GCC and NASM? Well I'm primary a windows programer so it's the tool chain I'm the most familiar with. Though there is the downside of having to be stuck with MASM, I love NASM (heck I even contributed code to it) and would much rather be using it. I might move the ASM code over (there's a good integration with Visual Studio now) but for now I'm sticking with a 'stock' system.&lt;/p&gt;
&lt;p&gt;On the other hand, I'm very happy to use C# for the post build tools. It made them easy to write up and easy enough to use. Both tools are rather generic and can be used in any other project and in fact I would love to expanding the PE library in the header tool to cover all parts of the file format and not just the core headers.&lt;/p&gt;
&lt;p&gt;Hopefully I should have some code/downloads up in a few more days.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Fox Cutter</dc:creator><pubDate>Sun, 16 Mar 2014 04:32:09 -0000</pubDate><guid>https://sourceforge.net5f329b34204fb155ededf99bdd08d065f6d2368d</guid></item></channel></rss>