As I mentioned yesterday I’m currently playing around with Linux on an embedded PC.
Stage 0: was to get a build environmet set up. That’s complete now and I have a build of the 2.4.31 kernel running whilst I type this.
Getting a build machine set up was pretty painless. I downloaded the evaluation of VMWare Workstation 5 and had hoped to grab a pre-built image from Red Hat but the only images that they have available are enterprise server builds that were around 900->1000mb downloads with no details about what had been installed on them.
One of my clients has asked me to do some investigative work for them in relation to Linux running on a Vortex86-6071LV (a PC/104 format PC which is 386 PC on a board that’s around 6" x 4" x 1/2").
Should be fun.
The machine in question is actually a VOX-064-TS thin frame PC with a touch screen which is pretty cool. The ‘disk’ is a 32mb solid state device and it’s kinda weird to see this tiny PC boot up via the usual AMI BIOS screens and then into Linux in around 10 seconds from this super fast disk (I want solid state disks for my dev box!
I’ve been using SharpReader as my RSS reader for ages. I downloaded a version of it way back when I first got into blog reading and stuck with it because it worked, to a fashion. I ignored the bloaty .Netness of it and the fact that sometimes it disapeared from my task tray yet was still running, and that sometimes it ran really slowly, and that the way it presented new postings was a bit crap…
Last week I posted an entry about the simple, hand built, mocks that I use for testing in C++. Whilst I stand by my previous assertion that writing the mocks yourself gives you an further insight into your design from a client perspective I think the discussion that I had with Roy Osherove after last week’s posting has made me appreciate the power of having mocks that support the programmatic specification of ’expected’ behaviour.
My Unicode Byte Order Mark hassles yesterday were brought to light by one of my mock objects. It was the expected output log for the object that had been converted from UTF-16 to UTF-8 by CVS without asking… Whilst writing that piece I realised that I probably needed to write this piece. You see, I spend most of my time in C++ and I write most of my Mock objects myself rather than having some framework do it for me and something that I found very useful and simple is the idea that my mock objects create simple logs of what happens to them.
My project house-keeping yesterday ended up with a rather strange discovery. I have some test log files that contain Unicode characters and are stored on disk as UTF-16 with the correct 2 byte ‘byte order mark’ (BOM) header of 0xFF 0xFE. When I discovered that I needed to save some test logs as Unicode I hacked together some code that dealt with the UTF-16 BOM and did the right thing. Yesterday’s mammoth CVS checkin and test was obviously the first time that I’d checked these files out of CVS and run my tests.
As anyone who has downloaded any of my code from here, or my company site or CodeProject will know, I have a particular way of doing things. The code I write tends to follow a particular style and as such assumes particular dependencies. The approach that I tend to take when I’m making stuff available on the web is that if you want to use the code I’m giving away, then you need to adjust your code in whatever ways you need to be able to consume what I provide.
I’ve had a busy few weeks. I’m waiting for a client to come back to me about a quote for some work and whilst I’m waiting I’m putting together a prototype for a product that I’m interested in producing. The prototype has been going well but since I know I have a limited amount of time to work on the system I’ve been working to a very tight deadline. Still, at least it’s of my own making and at least there’s a reason for it.
I’ve spent much of this week moving from a hand crafted prototype to a code generated version of the same code. The code is all repetitive boiler plate, sort of like the stuff that MIDL generates for you. The code generated version is considerably better code and has evolved faster than the hand written code because I was free to adapt and improve the code at the “single entity” level whereas when I was prototyping the code all improvements needed to be made to all of the entities involved.
Christopher Baus bemoans the problem of getting all the libs that he wants to use linked in statically on Linux. Chris wants an executable that will run on lots of different systems with the least amount of pain for all concerned and to do this he’s linking as much as he can statically so that he has a known set of functionality available.
I know this will sound like heresy, but that’s pretty much my approach on Windows and it has been for a long time.
