Progress and whatnot

Those who really know me, i.e. my precious Julie, know that when I find something I find funny I do it. A lot.

So for the last few days I've been totally focused on Cosmos, and have made some significant changes dare I say. The network driver for RTL 8139 became stable enough to send proper packets the other day. Yey!

Today I added support for VMWare Server (since we only had VMWare Workstation from before). The VMW Server hasn't got an RTL network card, so for now we are only able to send networkpackets from Qemu and physical machines with RTL NIC's.

Oh, did I mention that the RTL can't receive packets yet? A mono-NIC if you will. Once I understand IRQ's in Cosmos (and we get that darn "Invalid Opcode" bug out of the way) we can hopefully get a fully functional network card.

It would be awesome if we could get two Cosmos machines talking to each other before Chad goes to Egypt to present Cosmos at Microsoft Egypt's EDC, Egyptian Developers Conference in April.

Mention on the Cosmos blog

The Cosmos project has a blog - and darnit - I got my 15 minutes of fame.

For those of you who doesn't yet know what Cosmos is it's a framework for writing Operating Systems in C#. Within minutes you can have your own custom operating system up and running. The C# code you write is converted into IL by Visual Studio, and then converted to Assembly/Machine code by Cosmos.

Today Chad "Kudzu" Hower, a Microsoft MVP and one of the founders of the Cosmos project, implemented USB support. That means that you build directly from Visual Studio 2008 onto a USB memorystick, and then you can boot your Operating System directly from the memorystick.

Network support is still more unstable than a cow balancing on a 15 feet pole stacked on a football, but still...

Network packet sent from Cosmos

I've been working on network support in Cosmos for some days now, and actually got a breakthrough this evening. A packet, although with invalid data, has been sent onto a virtual network!

Here is a screenshot of Wireshark (former Ethereal) which sniffs a packet from a virtual TAP -WIN32 networkcard connected together with Cosmos' RTL8139C+ NIC.


The next step is to get correct data to be sent, and also to receive packets.

Cosmos - an interesting place to be

Like before I've discovered new and interesting things through the blog of Scott Hanselman. This time I've stumbled over Cosmos - an operating system written in C#.

I've been fascinated with creating OS's for several years. Back in 2004, I think it was, I wrote a simple OS in plain C. It didn't really do much except boot and detect some hardware.

Last summer I dabbled a little with the ReactOS operating system, and made some small sourcecode contributions there. That was C/C++, and unfortunately those are languages I'm not fluent in, so the development just progressed to slowly.

Now though I've found Cosmos which lets me use my favorite language, C#. Yey!

My goal is to create Network support in Cosmos. I've been working on a driver for the RTL8139 chipset for a few days now. Since I have a background in electronics I really love working in the sweet spot just between software and hardware. Working out bits and bytes, and addressranges and memoryareas. Bitfiddling and bitwise mathematics. Good fun!

New R/C helicopters

I've been fighting the urge of buying a radiocontrolled helicopter for a month or two, and last week I had to succumb. I picked up a small Superfly 2.0 chopper at a local store, and have been playing with it a lot since then.

Today my boss and I went to a local hobby-store in Drammen, and ended up leaving with a Twister Bell 47 chopper each! The Bell is about 3 times as big as the Superfly, and 6 times as expensive.

The Superfly is extremely simple to fly, and can take quite a beating. It's been sent head-first into walls and furniter time and time again, but minimal damage. I even (crash)landed into a 500W lamp. Two channel controllersticks - dead easy.

I've been hovering the Bell around the livingroom this evening, and this helicopter is in another league. There are way more axis to control, and it takes some getting used to. I've had two very minor crashes, and both have resulted in broken rotorblades. Four channel controllersticks - hard, but fun!

Shrinking SQL databases

I've got a bunch of SQL databases on my machine. Both from SQL 2000, SQL 2005 and also SQL 2008.

The databases are mainly used for testing customers databases or for development, and the actual data isn't really important.

Over time the .mdf and .ldf files have a tendency to grow to 1-3GB files, and keeps hogging more and more of my C:\-drive. Often the files actually just contain free space as well.

A quick way to shrink the files is to run this - the demo base is called Demo1 in this example:

Use Demo1
CHECKPOINT
DBCC SHRINKFILE (Demo1, 1)
DBCC SHRINKFILE (Demo1_log, 1)

This shrinks the files as much as possible by removing "free space" from the files.

The CHECKPOINT is included since my databases are using the Simple Recovery Model, and that command purges the .ldf file. This is the same as is done when you tell SQL Server to do a backup. Only in this case I just truncate the .ldf file, without performing the actual backup.

The DBCC SHRINKFILE commands try to shrink the two files down to 1MB. The .ldf file will end up being 1MB, but the .mdf actually contains data, so it will become as small as it can without deleting data.

Getting to know my network - Jumbo Frames

I was reading one of Scott Hanselman's blogposts about improving network performance , and got referred over to a very good article which explains how Jumbo Frames can speed up the network throughput.

I started doing some testing of my home network, to see which devices are Jumbo Frame compatible, and eventually if I could gain anything from enabling it.


As the figure shows most of the devices in my network are using WLAN. Only the router, firewall and wireless access point are actually connected with CAT 5 cables. Even the Windows 2003 server is communicating with an external USB Linksys WLAN adapter.

One very significant fact when discussing Jumbo Frames is that it is ONLY available on 1Gb network devices. 100Mb/10Mb devices do not have Jumbo Frame capability. And since my network is mostly WLAN this is a shop-stopper. However, I still wanted to figure out what it would take to JF-enable LAN, and also to gather some information about the network.

The most obvious thing was to check the network drivers on the various machines. On my IBM T42 the Intel PRO/Wireless 2200BG card unfortunately doesn't support Jumbo Frames (JF), but the Intel PRO/1000 MT Mobile infact does. The gigabit NIC seems to support 4KB, 9KB and 16KB packets.

By pinging the access point I was able to determine that my T42 WLAN card has packetsizes of 1272 bytes. The size was determined by pinging with the command 'ping -f -l 1272 172.28.5.3', and adjusting the packetsize until the NIC returned error "Packet needs to be fragmented but DF set.". Both on Julies Dell Inspiron 6400 laptop's WLAN card and on the USB Linksys Wireless-G adapter the packetsize is 1474bytes.

The Dell laptop's LAN NIC is only 10/100Mb, so it doesn't have JF support.

On the Dell server the LAN NIC is an Intel PRO/1000 MT card (not unlike on the T42), but Jumbo Frames is not available in the driver settings. Perhaps it only requires a driver update.

My switch, a D-Link DES-1008D, is a mere 10/100 Fast Ethernet switch - so it does not support JF either.

So it seems like my network is far from Jumbo-Frames-ready. Ok, so now at least I know. No point in enabling JF on my laptop yet then.