Things

I don’t like AVG 8. It is horrible. I liked 7.5. it was non intrusive and although it liked to complain about viruses it never did anything rash unless I told it to. 8 on the other had is annoying. Not only does it take three times as long to scan my computer, adds these really annoying pictures beside my links on web pages and insists on searching for tracking cookies it has a nasty habit of simply deleting files.

I had this rather large archive. There was a file within this archive that contained a virus, and I knew this. AVG 7.5 would always remind me. But when I installed 8 I never got a warning. At first I did not think much about this, but when I looked into it I found it had simply deleted this archive.

It did not bother to tell me.

Normally files it deletes are placed in a quarantine area so I can inspect them later. as it turns out there were a few files in there. But no archive. I suspect it felt the file was too big for the quarantine and as such deleted it.

But still. 

That was a nice archive.

Stupid AVG.

I hope to have fixed this by telling AVG not to limit the quarantine. I have also removed those annoying web page scanner icons. as well as (I hope) removed un-necessary scanning. It still takes too long.  

And why does AVG require a restart every update? come on. 

I used to like avg (although it did complain a lot)

but now.  I don’t

It wont even let me copy files if it thinks there is a virus. I had to disable the resident scanner to copy a file. It does not have a virus, but try telling AVG that.

hm. I wonder if my test-virus file exists.

Anyways, long story short I am on the lookout for a new free anti-virus. 

Oh these foolish games we mortals play

So anyways. As people know. I quit my last job a while ago. I said I would help out a bit, but I never really received instructions on what to do and the guy I was supposed to train never called me. So. I pretty much did nothing. The fact that I filtered all their email into a folder I never checked probably did not help much either. I also stopped checking my email. wooo.

A few days ago (apparently) I received an email from one of my co-workers. Well, the only other guy in the place besides me. He has worked their for 20 years and was the senior programmer.

Apparently he quit too.

So that was like wow. cool.

I emailed him back.

Anyways.

Now, The devil went down to Georgia, to make a cake or two, and when he was done he said Son of a gun I just invented devils food.

So, I did something silly

I decided it may be a bad idea to purchase a coffee for 1.50 every day. So I bought one of those insulated steel canisters for storing biological weapons in. They were cheap at superstore.

There really are three problems with this.

First. I don’t have any biological weapons. At least none I am willing to trade for coffee.

Second. This sense of fiscal responsibility has made me irresponsible fiscally. I mean, normally I would say. "No, I cannot buy that sports car, I am already spending too much money on coffee." But now I say, "you know, I am saving so much on coffee I can afford to treat myself to a new sports car."  And now I have  a sports car in my driveway.

Third. I don’t know how to make coffee. Which is sad. I really need one of those bunn coffee makers. you put in a pre-measured packet. push a button. instant coffee (minus the instant coffee). And its good! But no. I have to be content with whatever weirdness I happen to produce that day.

But the insulated whatchamacallit (<- That word is in my dictionary?) actually works. When I get home from School which is just over 8 hours from when I left for school, the coffee is still warm. Not hot mind you, but warm. At noon however it is usually still scalding. Which is nice. burns the tongue. can’t taste the coffee. 

I may consider taking hot iced tea.

would that not just be tea then you ask? well nope. you should try it. good host iced tea in boiling water. for some reason it keeps me awake for hours so when I am falling asleep in class I just take a sip and I’ll be buzzing around like a bumble bee.

It probably should be noted that I still buy lunch TWF from timmies. I like their soup.

Build your own operating system. Step 1 of Infinite.

Introduction:

So, you want to write an operating system. Whether it is because you are sick and tired of the current operating systems, want to prove once and for all that you are smarter than Bill Gates, or you simply were bored one Sunday afternoon, all of us at some point in time have wanted to write an operating system.

Writing an OS however, is no simple task. It relies on all aspects of computer science including some they probably will never teach you.

The first question that may plague you, is where to begin? I myself when I first considered creating an operating system felt the most obvious place to start would be with the boot sector, the piece of code that is loaded by the bios and then hands over control to the kernel. While this may not be the most horrible place to start it does require you to know a variety of things that ultimately are very frustrating. At the time I decided it would be best to simply write a kernel and let a boot loader such as grub do the initial setup. 

But even with that decision made, there is the question of where to next? Probably the most obvious is simply lets get a kernel to load, and print a message on the screen. As one might imagine this is a lot simpler said then done.

In this document I hope to outline the very basics that are required to setup a development and testing environment, plus of course the source and how to compile and run your very own operating system. I am by no means an expert in this field and am learning even as I write this, but this should make your life easier if you ever decide to try to write your own kernel.

Because all we are doing is printing something to the screen then halting, our operating system will be less than useless, but it will give us a place to start and to experiment.

For best results, it is recommended you know c/c++, assembler. It is also advisable to be able to work on the Linux command prompt. However most will be done in Windows.

Step 1: The Development Environment.

The first thing we need is c/c++ compiler and an assembler. There are many tools available for windows, but we will save our time many headaches later by creating ourselves a cross-compiler for the purpose of compiling our operating system kernel. If we attempt to use any of the compilers we have on our system currently it is very likely that they can only output files meant to be executed on windows and include many calls to a kernel that quite simply we have yet to write.

In order to do this we must first download and install Cygwin, a Linux environment built for windows. Cygwin includes a windows port of the gnu g++ compiler and many other nice tools that traditionally only available for Linux.

So, lets begin. This part is taken mostly from http://wiki.osdev.org/GCC_Cross-Compiler

First we must download cygwin here: http://www.cygwin.com/

When you finish downloading it, start the install, when it displays a list of packages you wish to install make sure that the gcc compiler, make, and nasm are selected. The cross-compiler tutorial also mentions Bison and Flex as well as a scripting language such as perl or python, but so far I have not made use of them. It is up to you.

When cygwin is finished installing (this may take a while) we should now download the source for gcc-core, gcc-g++ and binutils both of which can be found here: http://ftp.gnu.org/gnu/. There are many versions to use, I chose 4.2.3 and 2.18 respectively as they were the newest versions that were successfully tested together. Download these three files to someplace useful, /usr/src under cygwin for example.

From the Cygwin prompt (assuming you downloaded to /usr/src, which is (usually) c:cygwinusrsrc)

extract the source tarballs
x.xx is the version of the binutils. In my case 2.18
x.x.x is the version of gcc. In my case 4.2.3

tar -xf binutils-x.xx.tar.tar tar -xf gcc-core-x.x.x.tar.tar tar -xf gcc-g++-x.x.x.tar.tar

Set up parameters and create directories for the install

export PREFIX=/usr/cross export TARGET=i586-elf cd /usr/src mkdir build-binutils build-gcc

Install binutils in our cross compiler directory (/usr/cross)

cd /usr/src/build-binutils ../binutils-x.xx/configure --target=$TARGET --prefix=$PREFIX --disable-nls make all make install

Install gcc into /usr/cross

cd /usr/src/build-gcc export PATH=$PATH:$PREFIX/bin ../gcc-x.x.x/configure --target=$TARGET --prefix=$PREFIX --disable-nls     --enable-languages=c,c++ --without-headers make all-gcc make install-gcc

The details of what is happening are not going to be covered here, but suffice to say we are creating an empty compiler that does not know about any libraries that will compile to the ELF executable format that Grub likes. This may take a while, one one of my machines it took almost all day, on another just under 2 hours.

Once the install is finished we will be able to use our new gcc and linker from the /usr/cross directory, or alternatively by using -b and -V on the command prompt. 

It would also be nice to have a proper text editor. I use JEdit http://www.jedit.org/, but any editor that you like will work fine. Even notepad or dos edit will work if you don’t mind working in them. It is however recommended to have syntax highlighting.

At this point however you should be able to compile a kernel.

Step 2: Set up our Testing environment

It would be rather pointless if we did not have a way to test our new operating system. What I have found to be the easiest is to create a Grub boot disk with fat12, this enables us to simply copy our newly compiled OS to the floppy which we can then take to a separate machine for testing, or mount in an emulator such as bochs or Microsoft Virtual PC. I will not be at this time detailing the use of bochs for Microsoft Virtual PC, but they both are relatively simple and come with ample documentation. For a Linux install, all you need is create a small hard drive and mount a Linux ISO to install from, I used DSL http://www.damnsmalllinux.org/ for this. For booting your operating system, all you need to do is capture your floppy drive in the emulator you are using and reboot.

There really are two ways of building a grub boot disk. The first is get your hands on a Linux box and from the terminal enter the grub prompt and install grub to the floppy:

From Linux prompt type:

mkfs -V -t msdos /dev/fd0 mount /mnt/floppy /dev/fd0 mkdir /mnt/floppy/boot mkdir /mnt/floppy/boot/grub cp -pa /boot/grub/* /mnt/floppy/boot/grub grub

From the grub prompt Enter the following:

root (fd0) install /boot/grub/stage1 d (fd0) (fd0)/boot/grub/stage2 0x8000 p (fd0)/boot/grub/menu.lst quit

Please note this does assume that your floppy is on fd0.

Alternatively we can just download an image http://downloads.terdos.com/mos/grubboot.zip and write it to a floppy with something like rawwrite: http://www.chrysocome.net/rawwrite

In either case we must modify the menu.lst file to boot our operating system. For the purposes of this document the following will suffice for our operating system. I have been putting my kernel imaginatively named mos in a:bootmos.bin

# This sets the default entry to boot.  # Remember that GRUB counts from 0, so 1 is the second entry. default 0   # This sets the length of time in seconds that grub will wait for the user to select an OS # before it boots the default on.  timeout 15  # this is the entry for our OS. The title is what will display in the menu, the next # line is the command that the menu option will execute. the command line is the line that # we have to change to reflect the name/path of our kernel title MOS kernel /boot/mos.bin

At this point, if we had a kernel, we could boot it. yay.

Step 3: Lets make a kernel

Our basic kernel consists of two source files, one assembler file that will contain our executable header and call our main function, and a c file that contains our bare bones kernel.

The following is the start.asm. I basically stole it from a tutorial online: http://www.cs.vu.nl/~herbertb/misc/writingkernels.txt. All it really does is create our stack area, define the Multiboot header then call the cmain function. We probably will never have to modify this file once we compile it.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; start.asm ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; This is the kernel's entry point. We could either call main here, ; or we can use this to setup the stack or other nice stuff, like ; perhaps setting up the GDT and segments. Please note that interrupts ; are disabled at this point. [BITS 32] global start  start:  mov esp, _sys_stack ; This points the stack to our new stack area jmp stublet  ; This part MUST be 4byte aligned, so we solve that issue using 'ALIGN 4' ALIGN 4  mboot:  ; Multiboot macros to make a few lines later more readable MULTIBOOT_PAGE_ALIGN equ 1<<0 MULTIBOOT_MEMORY_INFO equ 1<<1 MULTIBOOT_HEADER_MAGIC equ 0x1BADB002 MULTIBOOT_HEADER_FLAGS equ MULTIBOOT_PAGE_ALIGN | MULTIBOOT_MEMORY_INFO MULTIBOOT_CHECKSUM equ -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)  ; This is the GRUB Multiboot header. A boot signature dd MULTIBOOT_HEADER_MAGIC dd MULTIBOOT_HEADER_FLAGS dd MULTIBOOT_CHECKSUM  ; A call to main (the C kernel) followed by an infinite loop (jmp $) stublet:  EXTERN cmain ; start of our kernel call cmain jmp $  ; Here is the definition of our BSS section. Right now, we'll use ; it just to store the stack. Remember that a stack actually grows ; downwards, so we declare the size of the data before declaring ; the identifier '_sys_stack' SECTION .bss resb 8192 ; This reserves 8KBytes of memory here _sys_stack: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Next is mos.c the meat and potatoes of our kernel, this is where we start our kernel. All we are currently doing is pointing two pointers to the start of video memory and then using them to clear the screen, then write "Hello world" in the top left corner.

// The main procedure for our kernel. This is called from the assember startup  // file. I am using cmain only because that was what was used in the tutorial I // found. int cmain() {     char* string = "Hello World";     int i;           // we are using volatile, which essentially means no caching, if my memory     // serves.     volatile short *v = (volatile short * )0xB8000;           // clear the screen, set all characters to a space 0x20     // note that the 0x0720 seems backwards compared to our printing     // of the string below. This is because the Intel IA32 is Little Endian.     for (i =0; i < 25 * 80; i++)     {         *v = 0x0720;         v++;     }           volatile char * video=(volatile char*)0xB8000;     // loop through the string Hello World, 0x07 simply sets the colour as      // light grey on black      while(*string!=0)     {         *video=*string;         string++;         video++;         *video=0x07;         video++;     }     return 0; }

Next all we need is a couple of scripts to facilitate the compiling and linking. They are as follows

link.ld (again taken from http://www.cs.vu.nl/~herbertb/misc/writingkernels.txt):

ENTRY(start) phys = 0x00100000; SECTIONS { .text phys : AT(phys) { code = .; *(.text) *(.rodata) . = ALIGN(4096); } .data : AT(phys + (data - code)) { data = .; *(.data) . = ALIGN(4096); } .bss : AT(phys + (bss - code)) { bss = .; *(.bss) . = ALIGN(4096); } end = .; }

Essentially all it does is tell the linker where to put the different data sections, as well as where to start the program. I tried to just let linker do it on its own, grub would not even load the file.

makefile:

CFLAGS := -fno-builtin -nostdinc -O -g -Wall -I. LDFLAGS := -nostdlib -Wl,-N -Wl,-Ttext -Wl,100000  all: mos.bin  mos.bin: start.o mos.o     /usr/cross/i586-elf/bin/ld -T link.ld -o mos.bin start.o mos.o     @echo Done!  start.o: start.asm     nasm -f elf -o start.o start.asm  mos.o: mos.c      /usr/cross/bin/i586-elf-gcc-4.2.3 $(CFLAGS) -c -o mos.o mos.c  clean:      rm -f *.o *.bin  install:     cp mos.bin a:/boot/mos.bin

You may have to change some of your locations. This allows us to use three different commands with make. all, clean and install which compiles and links, removes all binaries, and copies the kernel to the floppy drive respectively.

At this point you should be able to from your Cygwin console change directory to wherever you placed the previous four files and compile:

cd /cygdrive/r/mos make all make install

If you did not experience any errors you should now be able to boot off of your floppy and see the words "Hello World" at the top of the screen.

Now where do you go? Well from here I would recommend writing an output module using what you already know. It would make life much more easier if you could write debut information to the screen. So writing the various output routines that would allow you to display information on the screen would be very helpful. 

After that, It is up to you. It all depends on where you plan on going with your OS. But as a general rule it is always easier to start at the bottom by building the basics and working on more complicated modules using those you have already created. It is much better to learn to crawl before you attempt to run. Don’t let your ego get ahead of what you are capable of accomplishing and things will go much easier for you.

At some point I may post my output routines, If I get them finished. 

Tools:

Cygwin: http://www.cygwin.com/
RawWrite For Windows: http://www.chrysocome.net/rawwrite
DSL Linux: http://www.damnsmalllinux.org/ 
JEdit Editor http://www.jedit.org 
Bochs IA-32 Emulator http://bochs.sourceforge.net/

Source:

MOS http://downloads.terdos.com/mos/mos1.zip
Grub Boot Disk http://downloads.terdos.com/mos/grubboot.zip (bif format?)
GNU Utilities Source: http://ftp.gnu.org/gnu/

References:

Cygwin FAQ: http://www.cs.nyu.edu/~yap/prog/cygwin/FAQs.html
Making a Grub Boot Floppy: http://linux-sxs.org/administration/grubflop.html
Writing Kernel Tutorial: http://www.cs.vu.nl/~herbertb/misc/writingkernels.txt
Cross Compiler Tutorial: http://wiki.osdev.org/GCC_Cross-Compiler

Further Reading:

OS Dev Wiki:http://wiki.osdev.org
FAT12 http://www.it.lth.se/ssoa/Project1/FAT12Description.pdf

More school Wooo!

Registration for the fall/spring terms was opened at 6:30 AM June 30 and as such was up bright and early to secure my picks. The first term went well, but an unforseen scheduling conflict between a physics lab and my computer science class forced me to move the computer science class to the current summer term. Which mean now I am doing three classes this term and owing of course another 500 dollars.

So far given what I have seen, neither of the classes I currently have had should present me a problem. So it is not like I am taking a full load, except that I am.

I don’t currently know what I am going to do for my second term, I have a fourth year interface design class currently registered, but I don’t know If I want to take it. I can only take 2 fourth year classes and would rather not waste them.

I bought more text books which is also fun. 

We are going to be learning about the mips processor. yay. not that anyone has ever heard of the mips, or ever will use one.

I called student loans. I have been regected for the summer classes as expected, but they have yet to recieve my paperwork for the fall classes. did someone mail that? they said they did they did.

ah well. Assignments are out. I should do them I guess.