Have been a little busy with my day job of late but I have continued tinkering behind the scenes, learning (stage by stage) about how to build, deploy and debug a Windows CE OS on an ARTiGO box.

I'll shortly be posting the steps you need to go through in order to build a bootable USB key. It's not as simple as it should be, but when all is said and done, it's not as hard as it seems ;)

Stay tuned for step-by-step instructions explaining just how to build a bootable USB key that can get your ARTiGO online and ready to receive your Windows CE OS!

In my previous post, I discussed how to assemble an ARTiGO device. Now that the device is assembled and working, I need to get some software onto it.

The ARTiGO is essentially a small form factor PC. Therefore, as any PC owner knows, the machine has a BIOS that provides, amongst other features, the ability to select where to look for the software that is to run on the machine.

When my ARTiGO booted up, I was presented with the BIOS' boot screen:

The device would then attempt to boot from the attached HDD. The problem is that the HDD is currently empty, and I'd like to use some kind of bootloader that will signal Visual Studio and ask it to download a Windows Embedded CE image to run.

There was no on-screen indicator of what to press during boot-up to enter BIOS setup mode, so I started by hitting [ESC] and [F12]. It turns out that [ESC] takes you to the boot menu where you can select which device type to boot from:

• Hard Drive (either attached PATA/SATA drive or USB drive)
• USB-Zip
• USB-CD/DVD
• USB-
• Legacy Network
• Network Agent (PXE)

While this is fine for the occasional boot, I wanted to setup my default boot device options and so needed to configure the BIOS itself. However, because there were no on-screen hints, I had to read the user's manual (online or from the accompanying CD) to see that in order to get into the (Award) BIOS setup, I had to hit [DEL] during bootup.

This gave me the usual BIOS configuration experience, including the ability to turn off the above boot screen and show me the BIOS boot info, and select from which devices, and in which order the machine would try to boot.

I knew I'd be needing to play around with the bootloader for a little while, so configured a bootable USB key (more on this in my next post) as my primary boot device, followed by PXE and then my HDD.

Booting from PXE will also let me try out scenarios where the device might be able to bootstrap from the network, saving me from having to continually shuttle boot files from my dev machine to my ARTiGO via a USB key.

In my previous post, I outlined the decision making process that led to my selecting the Via Artigo Pico-ITX kit with which to build a prototype of an embedded device.

There are already videos available of unboxing and assembling an Artigo (in case you don't like to RTFM), so won't go into this in detail here. However, there is a useful tip below, so please be sure to read on :)

The Artigo kit contains everything you need to construct the foundation device for many prototyping projects.

The kit contains a motherboard, case, power supply board and all the necessary cables. Additional serial IO, DVI, PS/2 and ATX power cables come in the box.

The (demure) case exposes a power switch, power LED, HDD LED, 4 x USB 2.0 sockets, microphone in, audio out and holes for the VGA and network sockets mounted on the motherboard.

Core to the unit is the EPIA-PX motherboard. This tiny (approx 72mm x 94mm) board houses VIA's C7 CPU and the VIA VX700 Unified Chipset that provides all IO, video and audio capabilities. Pin connectors for the case's front panel connectors are arranged towards the front of the board. An IDC and SATA connector for a HDD are mounted to the side. VGA and network sockets are mounted at the rear of the card. The motherboard chips are shrouded by a heatsink and fan to expel unwanted heat.

Note that this is a low-power consuming CPU from a PC perspective, but not from an embedded perspective! VIA have recently announced an updated VX800 chipset and Pico-ITX board that supports the new 1.5GHz C8 x86 CPU or a fanless 1GHz Eden low-power x86 CPU. No word yet on when the Artigo kit will be updated to include this new board.

Underneath the board, you'll notice a socket for RAM. Unlike the eBox 4300, this board doesn't support flash RAM, nor does it ship with DRAM - you have to add your own DRAM and HDD. Whilst this may seem like an encumberance, it's actually nice to be able to add considerably more RAM to this board than the 512MB DRAM that is welded onto the eBox.

IMPORTANT NOTE : When assembling your Artigo, be sure to properly mount the DRAM module. If you do not, your device will not boot and you will not see the BIOS boot-page appear when you power on your device. This one problem frustrated me for several hours until I saw mention of this very issue in the VIA Arena Forums. After disassembling my device and examining my Artigo's memory board I saw that I had not pushed the memory board all the way into the socket:

I unclipped my memory board and re-seated it, pushing it home at 45° before clipping it down (notice that the memory board's edge connector is now barely visible and that the locking clips are now properly seated):

Once that was done, I reassembled my Artigo, connected the VGA and the power sockets, turned on my device and saw the BIOS boot screen:

Woot! :) Just don't ask about the Bunny! Let's just say that my girls like to decorate stuff! :D

Next step ... getting some software onto this thing :)

As I mentioned in my previous post, I am building a prototype of a cool new idea for a product. This product will be an embedded system that controls several devices.

I know that the resulting device is going to need to be small, consume relatively little power, cost-effective and yet must process large amounts of continually varying data. It's also going to need to support a variety of devices, most of which can be connected via USB. It'll also need to support WiFi and possibly cellular Internet connectivity.

The requirements above pretty much exclude the really low-end 8-bit and even 16-bit embedded microcontrollers due to the data processing requirements that the device will require. So, I'm going to be using a 32-bit CPU of some kind.

Now, whilst the resulting product may well end up using a power efficient ARM (or similar) core, along with various ancillary support (USB, WiFi, etc), the prototype device doesn't need to be quite so stringent. In fact, it'd be quite useful to have a little more processing power, sockets, etc., available during prototype so that I can try new things out before finalizing any productization plans.

So, do I use an emulator or a real device? The problem with the emulator route is that I would only be able to test the prototype out from my desk at home. This won't work for me, so I decided to explore how I might go about building a real prototype.

When I began investigating prototype hardware, I quickly learned that that there are now a rapidly growing number of hobbyist computing devices that will fit my needs nicely. Products like Via's Artigo Pico-ITX kit provide support for pretty much everything I will need to get this sucker running:

• Low power x86 CPU
• Up to 1GB RAM
• HDD Interfaces (PATA & SATA) for persistent storage
• SVGA (the final product won't need video out, but it'll be useful while prototyping)
• 4 x USB sockets
• 1 x 10/100mbps network socket
• Only costs around $350 (inc tax) from Fry's!

Okay, so if I know what kind of tin I'm working with, what about the software?

When it comes to prototyping this device, I need to focus on getting the thing built as quickly and as easily as possible. Therefore, I won't be building my own Real Time Operating System from scratch - there's just too much that would need to be done: Memory manager, CPU scheduler, USB IO, Storage IO, TCP/IP v4 & v6 stacks, WiFi and wired networking, etc.

So which RTOS do I use? Symbian? QNX? VxWorks? Linux? Windows Embedded CE?

I am a Microsoft developer. I have been for years. Back when DOS was around I was generally dividing my time between hand-coded assembly and C on UNIX, but ever since working in commercial software development, I've been a Windows developer: first in C/C++, then In Delphi, now in C#.

When looking into the available RTOS options, Windows Embedded CE just made perfect sense to me: It's features are very impressive - particularly for Windows CE 6.0. I'm already very familiar with most of it's API, it's tools support is pretty stellar and is very cost effective. It also supports .NET Compact framework and .NET Micro Framework which may also help shorten time to completion. Via also ship a free Board Support Package (BSP) for the Artigo for Windows CE 6.0.

So there, in a nutshell was my decision making process for how to build the prototype: I am going to use Via's Artigo Pico-ITX kit running Windows Embedded CE, Visual Studio 2005 (for the OS & drivers etc.) & Visual Studio 2008 (for the apps).

Next: Building the Artigo! Stay tuned.

I've had a few bright ideas for cool products in the past. Some of these ideas turned to dust when I found that several other people had the same idea some time before me and have fully implemented the resulting product. Others turned out to be infeasible for a variety of reasons. A few have been shelved only to find that someone else later implemented said product ... much to my annoyance.

A few weeks ago, I had a bright idea for a new product. I've searched online and can't find anything quite like what I am considering building. So I've decided to build a prototype of this product to see what it'd take to make it all work.

The specific details of what this product will be are not important right now - I'll (hopefully) be able to share the details on this product sometime later. For now, we'll code-name this product Sentinel!

The thing that I want to build requires an embedded system to control several devices.

Now, I've been a computer and gadget geek for years. When I was 12, I got a Dragon 32 for Xmas ... and the love affair with computers began. A year later I was lucky enough to upgrade to a BBC Micro ... that's when the fun really started. The Beeb was an amazing machine - it had built-in A/D converters (one of the only home computers to do so at the time) and a variety of serial and parallel interfaces. It was a home hobbyist's dream. My Beeb rarely had its cover on and was regularly seen to be spewing wires and probes as I interfaced it to all manner of things.

When I went to university, I took Computer Science and Microelectronics. I was fascinated by how computer hardware and software interacted and how these amazing machines *really* worked. After college, I worked at a company that was split 50-50 between hardware and software engineers. The hardware crew designed incredibly powerful Transputer-based signal/image processing cards and hardware; the software teams designed sophisticated apps and systems (usually in Occam and/or C) to make the hardware sing. It was very cool stuff back then.

It's been a few years since I build anything electronic ... and times have changed. So have available hardware. Whilst many existing and new products are built around 8-bit and 16-bit microcontrollers and microprocessors, the cost, size and power consumption of modern 32-bit CPU's has dropped to the point where it's often more cost-effective to build products based around these more powerful chips which in turn let products do more than ever before.

So, in order to build a prototype of this system, I'm going to have to do some work and un-learn and re-learn many things to get it all working! I'm going to need to decide *how* to build it. Do I build it in an emulator? Do I build a real device? Do I write my own OS or use a pre-existing OS? How do I build, debug, test and deploy said system? What are the challenges of building an embedded system using today's technologies vs. those of yesteryear?

I'll be regularly blogging my progress in building this prototype here, covering many of my strategy, design and implementation choices, problems, successes and failures.

Stay tuned :)

Ever wondered what the key bindings for your favorite Visual Studio actions were for C# or VB? Here are the downloadable posters you can pin to your wall :)

Visual Studio 2008 C# Key Bindings

Visual Studio 2008 VB Key Bindings

Enjoy!

Gert has just announced the release of the VS 2008 Database edition Power Tools:

The “DataDude” team is happy to announce the availability of the Power Tools for Visual Studio Team System 2008 Database Edition.

The Power Tools for 2008 contains all the functionality we shipped in 2005 plus:

• Command line SQL Static Code Analysis execution through MSBuild, this was the biggest customer request, which is why I was holding the release. This enables SQL Static Code Analysis to be an integrated part of Team Build!
• Data Generation Wizard; this is another customer request where we allow users to create a new data generation plan by pointing at an existing database, the plan will be fully configured by the wizard to pull all data from the database using the Sequential Databound Generator. This way users can use an existing data set and only override columns which impose risks because of for example privacy concerns and save about half a day or more of configuring a data generation plan from scratch, one column at the time.
• File based data generator; this allows you to insert the content of files in to the database (works for string and binary, not for XML yet).
• XML based data generator; this allows you to generate XML based on an XSD (the XSD has to be provided as file right now, and cannot be selected from database or inherited from the data type).
• Unique Regular Expression generator; this adds the ability to generator unique values using the RegEx String generator.
• Refactoring Command Generator has been made available as a MSBuild task for better project build integration so it can be made part of the pre-build and pre-deployment stages in the project. This allows users to automated the results of refactoring to some degree in to the project.

We added two new test conditions for Database Unit Tests

• ChecksumCondition – Which you can use to verify that the checksum of the data set returned by a database unit test matches the checksum of an expected data set.
• ExpectedSchemaTestCondition – Which you use to verify that the column names and data types of the returned data set match expected values.

Download page:
http://www.microsoft.com/downloads/details.aspx?FamilyID=73ba5038-8e37-4c8e-812b-db14ede2c354&displaylang=en

Installer download:
http://download.microsoft.com/download/f/b/8/fb8d1c0d-c0c4-4004-ab86-12396b2a3ee3/VSTSDB2008PT.msi

Documentation download:
http://download.microsoft.com/download/f/b/8/fb8d1c0d-c0c4-4004-ab86-12396b2a3ee3/Power Tools 2008.doc

Go download and have fun! :)

CONGRATULATIONS TO ALL THE KIDS WHO WERE BORN IN THE 1940's, 50's, 60's and 70's !!

First, we survived being born to mothers who smoked and/or drank while they
carried us.

They took aspirin, ate blue cheese dressing, tuna from a tin, and didn't get tested for diabetes.

Then after that trauma, our baby cots were covered with bright coloured lead-based paints. We had no childproof lids on medicine bottles, doors or cabinets and when we rode our bikes, we had no helmets, not to mention, the risks we took hitchhiking .

As children, we would ride in cars with no seat belts or air bags. Riding in the back of a van - loose - was always great fun.

We drank water from the garden hosepipe and NOT from a bottle.

We shared one soft drink with four friends, from one bottle and NO ONE actually died from this.

We ate cakes, white bread and real butter and drank pop with sugar in it, but we weren't overweight because ...

WE WERE ALWAYS OUTSIDE PLAYING!!

We would leave home in the morning and play all day, as long as we were back when the streetlights came on.

No one was able to reach us all day. And we were O.K.

We would spend hours building our go-carts out of scraps and then ride down the hill, only to find out we forgot the brakes. After running into the bushes a few times, we learned to solve the problem.

We did not have Playstations, Nintendo's, X-boxes, no video games at all, no 99 channels on cable, no video tape movies, no surround sound, no cell phones, no text messaging, no personal computers, no Internet or Internet chat rooms ...

WE HAD FRIENDS and we went outside and found them!

We fell out of trees, got cut, broke bones and teeth and there were no lawsuits from
these accidents.

We played with worms and mud pies made from dirt, and the worms did not live in us forever.

We made up games with sticks and tennis balls and although we were told it would happen, we did not poke out any eyes.

We rode bikes or walked to a friend's house and knocked on the door or rang the bell, or just yelled for them!

Local teams had tryouts and not everyone made the team. Those who didn't had to learn to deal with disappointment. Imagine that!!

The idea of a parent bailing us out if we broke the law was unheard of ...

They actually sided with the law!

This generation has produced some of the best risk-takers, problem solvers and inventors ever! The past 50 years have been an explosion of innovation and new ideas.

We had freedom, failure, success and responsibility, and we learned ...

HOW TO  DEAL WITH IT ALL!

And YOU are one of them! CONGRATULATIONS!

You might want to share this with others who have had the luck to grow up as
kids, before the lawyers and the government regulated our lives for our own good.
And, while you are at it, show it to your kids so they will know how brave their parents were.

Kind of makes you want to run through the house with scissors, doesn't it?!

Back in the day, I used to love having a PC equipped with a VGA graphics card and an additional Hercules graphics card attached to a green-screen monitor. When debugging applications, the app could run on the main screen and the debugger could run on the green-screen. This was particularly beneficial in the early days of Windows when debuggers were text-mode apps which forced the screen to toggle between text screen and Windows GUI as you stepped through code. Some older graphics cards and monitors used to take several seconds per switch to re-sync making single stepping through code a VERY painful experience.

And then, along came debuggers that could run within console windows or were native Widows apps and the need to switch between text-only and graphical screen resolutions suddenly went away. However, I always missed having my debugger & source on one screen and the app being debugged on another.

As the price of graphics cards and screens continued to drop, and as PC's and Windows' ability to support multiple screens improved, I eventually acquired a second screen letting me run the debugger on one screen while the app rendered on the other.

But as I started to work on multiple machines at the same time, I then hit another dilemma ... how do I retain my multi-screen environment when I have to switch between several physical boxes?

Alas, KVM's are just not a solution - they're unpredictable at best, horribly unreliable at worst and didn't smoothly support multi-monitor scenarios.

Then, a few years ago, Citrix, Microsoft and others introduced Terminal Services (TS) capabilities to Windows and other OS'. TS essentially streams all the User Experience (UXP) commands that would normally be directed to a machine's graphics, audio, printer, keyboard, etc. drivers to a remote PC running a Terminal Services Client (TSC). The TSC app would then translate these commands to render the same UXP on the local machine so that to all intents and purposes, the user could believe that they were actually sat at and operating the remote machine.

Whilst TS can be a massive boon to many enterprise scenarios enabling administrators to consolidate many thousands of user's PC's apps and environment into one server infrastructure. However, TS capabilities are not just limited to enterprise environments.

Thankfully, Microsoft opted to include a TS client (MSTSC) within Windows client OS' which meant that instead of having to buy a KVM and a ton of cables, I could instead control multiple machines from one client PC using MSTSC application (also known as Remote Desktop).

Whilst MSTSC was great in that I could now have my local desktop on one screen and other machine's desktops on other screens, all controlled from the same keyboard and mouse with no fiddly screen-switching to perform, I sometimes wanted to view a remote machine's desktop spanned across two screens.

Vista has now made this not only possible, but easy and simple!

To start MSTSC, it's often best to use the command line because there are a few options available which (for some reason) aren't exposed through the Tools  | Options dialog.

For example, to connect to a remote machine called RichDev01, you could type (or create a shortcut for) the following:

MSTSC \\RichLaptop01

When executed, you'll then be shown the remote machine's desktop. For example, here's my laptop's desktop (where I am writing this post), accessed from an MSTSC instance running on my dev box:

On a multi-monitor machine, I am also able to access the local machine's desktop (on the left) AND the remote machine's desktop (on the right) simultaneously:

Whilst this is great (so I can keep up with my email while my dev box builds, for example), I sometimes want to be able to access the remote machine's desktop as if it was attached to the two screens.

Thankfully, this was a feature added to Vista (and enhanced in Vista SP1)! Below is a screen capture of my laptop's desktop, viewed across my dev machine's two screens:

How do you do this? Simple - you call MSTSC with the /SPAN command-line option; for example:

MSTSC \\RichLaptop01 /SPAN

It turns out that spanning your target desktop via an MSTSC session has a valuable hidden feature: When you maximize an app on the remote desktop, it will expand to fill the entire space available to it, rather than the current screen! Just what you need when parsing complex logs or comparing files etc!

Anyone out there with more than two screens that can test out if a remote machine's desktop can be spanned across more than two screens?

Scott has just announced that the .NET Framework Library Source Code now available!! As Scott states: You can now browse and debug the source code for the following .NET Framework libraries:

• .NET Base Class Libraries (including System, System.CodeDom, System.Collections, System.ComponentModel, System.Diagnostics, System.Drawing, System.Globalization, System.IO, System.Net, System.Reflection, System.Runtime, System.Security, System.Text, System.Threading, etc).

• ASP.NET (System.Web, System.Web.Extensions)

• Windows Forms (System.Windows.Forms)

• Windows Presentation Foundation (System.Windows)

• ADO.NET and XML (System.Data and System.Xml)

We are in the process of adding additional framework libraries (including LINQ, WCF and Workflow) to the above list.

Note: The primary goal here is to enable developers to view source code to the underlying .NET Framework while building apps. As such, the ability to view the source to .NET is granted under a read-only reference license.

Happy hacking! :)

Jeremy Clarkson, presenter of TV's "Top Gear" published his bank account details and home address in an article he penned for "The Sun", the UK's best-selling newspaper. Why? Because he wanted to illustrate his belief that the furore over reports of the loss of CD's containing a database of 25M people's personal details were much ado about nothing. He claimed:

"All you'll be able to do with them is put money into my account. Not take it out. Honestly, I've never known such a palaver about nothing"

Alas, this stunt has backfired on him! Clarkson subsequently wrote in his Sunday Times column that:

"I opened my bank statement this morning to find out that someone has set up a direct debit which automatically takes £500 from my account. The bank cannot find out who did this because of the Data Protection Act and they cannot stop it from happening again."

Clarkson, much chastened, had the good grace to admit that:

"I was wrong and I have been punished for my mistake.

He must be thanking his lucky stars that whoever managed to compromise his account didn't clean him out! Let this be a lesson to us all.

It is clearly all too easy for our identities to be abused and compromised and we should all take steps to do what we can to protect our personal identities.

Here are my top 5 suggestions on the absolute minimum steps we should all take to protect our personal identities:

1. Shred paperwork. Don't just throw away paperwork with your name, address, telephone numbers, account numbers, balances, credit details, etc., SHRED THEM!  Document shredders are not expensive and take just moments to make it much harder for malicious third parties to abuse your identity.
2. Protect your passwords: Passwords are a pain to use and open us up to innumerable identity attacks such as phishing. However, until alternative identity exchange mechanisms such as Windows CardSpace establish a strong foothold, passwords are going to remain as the primary way we secure access to websites and online services. So we will need to more effectively manage our passwords. Key tips for password management:

1. Don't re-use passwords: Avoid using the same password at more than one site. If your password is compromised once, you're open to much broader attack if your password is shared across several other sites. It's quite easy to choose a unique password and to augment it with some site identifier so that you can easily remember the password to use on a given site.
2. Never write down your passwords, nor store them in an unsecured store (e.g. a spreadsheet on your laptop). If you must store your passwords, store them in an encrypted and/or password protected store, and rather than store the password itself, store a hint or reminder as to what the password is.

Monitor your bank / credit card transactions monthly: I am as guilty as the next guy of not doing this as regularly as I should. Until recently. A few weeks ago I decided to take a more proactive stance regarding my financial position and invested in a money management package (I chose Microsoft Money, but tools like Quicken are great too). Whilst categorizing all my uncategorized credit card transactions, I found that I had been billed over $120 by TFN*GreatFun (Trilegiant's well documented scam). I am in the process of jumping through the (quite unnecessary) hoops required to have these charges reimbursed. Without Microsoft Money, I would most likely not have noticed these charges and so it has already more than paid for itself!

Hope this helps you avoid getting compromised.

Sorry ... couldn't resist it! Just HAD to post a picture of our cat!

Brad Abrams is asking whether or not the default behavior of the .NET runtime should allow your machine to run .NET applications stored on network shares by default.

Today, you can run native EXE's stored on a network shares without having to do any security work at the desktop. .NET application on the other hand will fail with a somewhat unhelpful "[exename] has encountered a problem and needs to close.  We are sorry for the inconvenience" error message.

This is, as Brad points out, a well known issue with some simple workarounds involving:

1. Configuring your machine to trust a given strong-named (i.e. signed) .NET EXE (using MSCORCFG.MSC; details here)
2. Alter your machine's Code Access Security Policy to trust a given network share (using CASPOL.EXE, as shown by Shawn)

I believe that softening the default Code Access Policy to permit .NET EXE's to run from default shares will introduce too many opportunities for malicious software authors to fool users into running apps that they think they trust.

Remember the ILoveYou virus which, as Dominick points out, copied itself to network shares as one of the avenues through which it spread its infection?

The only way I could accept such a sweeping change is if only EXE's that are Digitally Signed with a cert from a Certificate Authority in my trusted root store were permitted to run from a network share. Otherwise users WILL be fooled into running something that is less than desirable and which causes significant damage ... something I think we should all take steps to avoid.

In short, Just say NO!