I spent quite a bit of time in the past 10 years working with the IPv6 people worldwide. I ran the 6BONE IPv6 testing backbone for the Australian region, did work on IPv6 tunneling on demand gateways, designed protocols for TCP connection survivability on network topology changes, and developed bump-in-the-stack designs for IPv6 TCP/IP protocol stacks in Trumpet Winsock.

I gave it a rest over the past 5 years or so as it seemed that the developed world has a rather short sighted attitude to IPv6. I’m heading off to this conference so that I can again touch base with people and catch up with the latest developments. Finally the IPv4 addresses are running out (predicted around 2010 +/- 1 year) so it would seem that now the pressure is on.

P!

It basically relies on skeleton system.dcu’s etc where the win32 api has been factored out. That combined with some important glue code to make sure that the DeviceMain() function in C is emulated correctly results in a workable .SYS executable. Once that is done, the only thing remaining is to prepare the .SYS file by modifying the win32 PE header slightly so that windows will recognize it as a device driver.

This is a rather powerful way to do kernel mode programming in windows. I’ve been able to build a couple of device drivers so far. The first was a proof of concept. I was able to get the driver to run at ring 0, and then dump the page tables and GDT/IDT. The next useful driver I made was one to directly access the LAN driver. This was able to port some of the code I did for Trumpet Winsock directly to delphi and now have roughly the same functionality as Winpcap.

Delphi now rules the ring 0 world of windows!!

P!

http://www.nvidia.com/object/io_1212391368499.html

In the past I have considered doing work on ARM devices. I would need to get my Opascal compiler (currently i386 which I don’t use right now) to run on the ARM.

P!

Screenshot…

Have fun everyone

P!

After more than 5 years, I finally have PetrOS and the other Trumpet products solely in my own name along with the rest of the IP of the Trumpet Software company. This has major implications for the future of PetrOS and ClassiOS. I’m not sure what else to say except it’s been so long, I felt like I was in a straight jacket not being able to code with any great freedom and having to use clean room techniques. Sadly, the reason it has taken so long is that my divorce settlement has taken that long to sort out, the IP being one of the last items to be finally be resolved.

The impact hasn’t fully hit me yet, but I can feel my wings again. Look forward to some new releases.

P!

Also, of interest, I got myself a small test system (wafer-lx) for embedded work -see pic. It has an AMD LX-800 CPU, 1 gig of ram, and a 4 gig hi speed Flash drive. This little beauty packs quite a punch – more details are below. I’ve got Classios to boot up on it with full TCP/IP networking. I can even boot it via DHCP/TFTP using the PXE protocols. P!

Some more pics.

Tech Specifications

What triggered the original development of Petros was the release of the Win32 specification and I felt that this was certainly a step forward in the DOS/Windows PC world. Win3.x was pretty rough as an OS and there was a need to go native instead of on top of DOS. I wanted to do it in pascal, but there wasn’t a 32 bit pascal compiler around at the time so I started writing my own. It was pretty much a spare time project over the years I ran Trumpet and I started with virtually nothing. Also, I’d always wanted to write my own pascal compiler and it didn’t seem too hard a job. Initially I stuck to plain pascal, but it was clear that I would need objects to be at least relevant to the modern world. All said & done, the compiler was a simple one spitting out assembler code, not a full language. Eventually in 2002 I did an amd64 version of the compiler but at that stage I felt it had reached the end of its useful life – it needed a rebuild too.

As far as the OS was concerned, I had done some initial OS research with my work at the Psych dept at the uni. I had a small run time OS which ran on top of DOS, but was interpreted. However it had limitations due to the underlying DOS and lack of address space. Hence one of the reasons for writing Petros – the others are more obvious, like wanting to have an alternative to windows. There was also a ton of stuff to learn – how to boot from bios, manage the hardware resources and so forth – all difficult due to the lack of documentation (remember no internet back then – you couldn’t just google those things)
Back to classios…. after resigning from trumpet in 2004, the then petros forum was falling into disrepute so I formed a new forum at http://groups.google.com.au/group/OPascal-OS?hl=en to continue the discussion taking place. It still seems clear that despite the advances in Windows over the past 5 years, that there still is need for a windows compatible OS which is small and easy to manage. It’s a tall order really as there is so much baggage in Windows you have to support, but one possibility is to build a reduced footprint windows which would do all the basic things – perhaps just enough to run a web browser and manage files. You can read more on what transpired at the forum.

Anyway, the latest is that I now have a kernel of sort running. It can read files from a FAT12/16/32 file system and can load and run concurrent user processes. I still have to implement a user file i/o layer, but the basic proof of concept is happening. As an aside, this version is completely written in Delphi by using a customized system.dcu. One cool feature is that I can use full exception handling in the kernel, a major improvement over petros. It’s still a long way from where I left off with petros, however I can do accelerated systems development through the use of a x86 emulator I also wrote during the intervening years since leaving trumpet. I can develop the code and compile in the delphi 200 IDE and then choose a menu option to boot the new kernel directly from delphi. I don’t have full delphi debugger integration but the emulator has a built in step debugger which helps greatly. I can also write debug messages to an I/O port directly which the emulator will print out in an isolated window. I’ll post a screen shot of that some time soon.

So basically, I have a kernel which is almost usable. I can shoehorn my new tcp stack which is completely new as well. Should be able to get a minimalist server running soon.

P!

Just as an aside… I’ve been aware that things might break in the past 10 years or so when I built IPv6 into Trumpet Winsock 5.0. My latest TCP stack for DOS (nothing to do with Trumpet) also has IPv6 and as far as I’m aware, it’s one of the few IPv6 DOS TCP implementations around. Ok, ok. it doesn’t do full IPsec and so forth (remember it’s only 640K in DOS), but it has the basic connectivity required to get going. Anyone who wants to try out a beta, let me know…

P!

I’m presenting a poster this afternoon on GELLO, a querying language written by the HL7 people. It’s a far cry from the TCP/IP work I did in the 90’s but still in the compiler writing vein that I’ve been doing over the past 20 odd years or so. The company I work (Medical-Objects) for is known for it’s HL7 and vEMR work around Australia, and the work I’ve done with GELLO has catapulted it onto the international scene as we produced one of the first implementations worldwide.
I’m little tired still as the “boys” have a tendency to work into the wee hours with stuff for the conference (like setting up servers on Monday morning at 2:30 am!!)
P!