Automating the QFE creation process

Well, this is my first blog post from my new position on the Sustained Engineering team.  While my office move was done a few weeks ago, and I’ve been doing the job since then as well, it was just made official today (at least, that’s when it finally filtered up through the many various DB layers to show up in our address book).  So today, officially, I am no longer on the Embedded team.

I’ll wait until you can compose yourself.  :-)

What I’ve been doing for the past week or two is trying to get our new automation tool simplified for the non-Embedded folks over here in WinSE.  My colleague in crime and Part-Time Bottle Washer Jay Kremer did a great job with the tool, but even after it was completed and being used, it was a hands-on process that he babysitted through the process.  It is a vast improvement over the old process, but it requires you know the XPE QFE process, XPE architecture, and have the time to do it.  In short, it’s not going to fit into the fully automated hands-off processes WinSE currently uses to put security bulletins together.

So what I’ve been doing to writing some wrapper apps to go around the automation tool that enable:

• One button push operation – basically, call the wrapper and point it at a folder full of updates.
• Batch processing – the tool works on one update package at a time.  The wrapper lets us work on all the updates at once.
• Automatically select the right SP level.
• Accumulate all the updated components into one rollup SLD – this required some fancy footwork to replace the previously used rollup with the one we just got through creating.

Now, it’s still not ready for the WinSE build lab to take over – some updates can’t be handled this way, there are some other oddities in the automation tool itself that need to be tweaked, and no one here is going to want use code written by a PM (go figure, since the last shipping code I wrote was pre-MS, early 1995 in Clipper) – but it’s better than the previous manual process.  Next steps are to spec out the changes we need for V2 of the tool, get a dev assigned to do the work (tougher than it sounds), and push this baby out the door.

News

New Blog

Have you checked out the new XP/LH Embedded Team blog yet?  You haven’t?  Why not?  Oh, I see, you’ve been busy.  Out of town, you say?  Off visiting the in-laws for a week?  Well, most libraries, even in that little town your spouse’s parents live in, have internet access – why not break away for a while and read some cool stuff?  You can’t tell me that your father-in-law account of the fish that got away is that compelling… :-)

If you haven’t checked out the newest blog on Embedded Avenue, you should.  Andy and Lynda from the test team have setup the blog as a clearinghouse for all the tribal knowledge collected over the past four years of XPE.  These tow guys know their stuff, and they know how to pass it on to other folks.  They also update it much more frequently than I update my blog :-(.

BTW, check out Andy’s post about Rawdeps and cooking.  There’s a bit of a contest at the bottom – i.e. you could win something.

News

For those of you way out of the loop, there’s a group formed last year called the Windows Embedded Developer’s Interest Group (WE-DIG for short).  It’s comprised of a bunch of embedded developer’s from our the Puget Sound who work with Microsoft Embedde technologies – XPE (of course – the only MS embedded OS that actually has embedded in it’s name), WinCE, PocketPC, and others like Media Center and Tablet.  We meet monthly on MS campus – you can register at our website for access to member only content, notifications of new meetings, and other interesting stuff.

Of course, if you don’t live within commuting distance from Redmond (heck, on bad days, people who live in Bellevue aren’t within commuting distance), then making the meetings is going to be tough.  That’s where registering on the website comes in – Mike Hall, our esteemed A/V nerd, videotapes every meeting, then dumps them to the website for the world to see.  Well, not the world – the WE-DIG registered users world.

And, if you’re planning on coming to MEDC in May down in Vegas (Vegas baby!), we’ll have our May meeting there.  I’m pushing to have it around the $5 blackjack tables, but am being overruled in favor of a quieter, more professional venue (to which I say: who is more professional than a Vegas blackjack dealer?)  You’ll get a chance to meet the board (including yours truly, the aforementioned Mike Hall, and a host of others – logon to find out who else is on the board), see what we do at meetings, and enter our monthly raffle to win some cool stuff.  What kind of cool stuff?  Well, in our first meeting, we gave away a Motorola MP200 phone – we haven’t hit that high again, but we do get books, dev kits, some HW, and general swag.

(More) Possible licensing issues with Linux in Embedded systems

ZDNet is reporting a German visitor to CeBit trying to notify about a dozen companies that their products which use Linux are in violation of the GPL by not returning the modified source to the community.  The protagonist in our story, one Harald Welte, is the author of netfilter/iptables and a one man wrecking crew when it comes to tracking down GPL violators as part of the GPL Violations Project.

This story, I think, is very illustrative of the problem open source has when it comes to defining a profitable business model for your open source solution.  There are a lot of companies thinking GPL source is public domain, grabbing it, adding their own valuable IP, then retaining those changes.  Any lawyer can tell you GPL’d source is not PD, and while there are some enforcement issues with GPL’d source (for example, there’s no legal way to sell a license for no money, and while that’s a technicality of the law, it’s still an issue to deal with), Welte and the rest of the open source community are well within their rights to demand these vendors turn over current source to their projects.

Now I’ll ask you – let’s say you’ve just used Linux to develop a home router/firewall solution, adding significant IP to make the firewall as bullet-proof and state of the art as possible, maybe incorporating some new inventions you’ve developed.  Are you going to be willing to turn that source over to the greater GPL community?  Remember, anyone can get the publickly available source, from developer’s to researchers to gifted 15–year old script kiddies who live to wreak havoc and ruin.  Can you patent your inventions since they’re based on GPL?  What if someone takes your source contributions, tweaks them a little, and starts selling a competing product?  How do you enforce your IP rights over that?  How do you keep from going out of business?

I like Linux, but then again, I’m a computer hobbyist and have been since junior high school.  As an alternate OS, it’s kinda neat to play around with, and there are a few things it has the XP doesn’t yet (for example, a full OS install including office software and development system in about 4 Gb of disk space), but there is no way I’m basing any derivative works from it.  As a profitable embedded business model, Linux makes absolutely no sense whatsoever.

Changes a' comin'

A quick update on some changes happening here at Microsoft.

First, the bad news – I am no longer a part of the Embedded team.

Now, the good news – I am moving to the Sustained Engineering team to handle servicing of XPE.  What this means is that XPE servicing will now be part of the servicing infrastructure for all of Windows.  This includes not only security and other updates, but also future service packs for XPE.  My friend and teammate Jay has done a great job with servicing since he joined the team 18 months ago, but if the team is ever to concentrate solely on Longhorn Embedded, they need to have the resources that were previously dedicated to servicing XPE.  So, we give servicing to the servicing experts (along with some resources, like me) and the Embedded team can work on bigger and better things.

Ramifications?  Well, by bringing XPE into the larger Windows servicing structure, we hope to get security bulletins out quicker.  We’re also hoping to get other non-security updates out in a timelier manner, and without so much internal hoo-haw over testing and verification.  Also, because we’ll be treating Embedded like any other Windows product, we hope to avoid problems like we saw with the .Net update last week.  Plus, the Embedded team can dedicate 100% of their attention on Longhorn Embedded, which is a very good thing.

Now, before you start getting your hopes up and inundating me with questions and comments – this won’t happen tomorrow.  It will take a while.  Embedded has been on its own path with regard to servicing for so long that I expect a lot of churn just trying to integrate into the main servicing processes.  As you can imagine, there is a lot to hand over, and we’re still hammering out the details and getting past the he-said/she-said stage of the relationship.  I won’t make any predictions on when things will happen – most of my predictions have been BS in the past.

So there you have it – change can be a good thing, and I’m hoping this will be a very good thing.

As a bit of an aside, this has been in the works for months – I’ve known about it since before XMas last year.  This past January, the entire Embedded team wasin a big office move.  Since I knew I’d be moving once more when I got into the WinSE team, I only unpacked two of my boxes (books, some HW, and stuff for my desk) – the other boxes have been sitting here, unopened, for two months.  My WinSE office move is tonight, so I’ve been looking forward to getting everything out of the boxes again.  However, I’ve heard a rumour that another office move is planned in the near future, so I may never get my stuff unboxed.  Such is life at Microsoft – when you’re trying to carry 1000 canaries in a truck that can only carry 500, the trick is to keep 500 flying at all times…

One last thing – I added a new link to the Mobile and Embedded Device Convention (MEDC, or what used to be just Embedded Devcon) on the upper left.  I plan to be there in Las Vegas in May with my wife, and my money plans to stay.  Hope you can make it – it should be a fun time.

Update on the .Net security updates

OK, we’ve had one of our best people (namely Aaron Stebner) working on getting this working.  He’s got a set of steps that workaround the previously mentioned problems with applying the .Net security updates to XPE runtimes.  Look for the updates to be back on the OEM Secure Site within a week – in the meantime, you can DL the bits from the Download Center to test these steps out (Aaron shold repeat them on his blog as well).

1. Figure out the exact version of the .Net Framework you have (major and minor version plus service pack).
• If you are using the .Net 1.0 component we shipped in XPE SP1, it will be 1.0 SP2.
• If you are using the .Net 1.1 component we shipped in XPE SP2 or as a QFE to XPE SP1, it will be 1.1.
• If you are using the .Net 1.1 component in the value-add folder of XPE SP2, it will be 1.1 SP1.
2. Go to the Download Center and locate the hotfix that matches the version of the .NET Framework you have.
• If you are using .Net 1.0, get the test package from http://www.microsoft.com/downloads/details.aspx?FamilyID=33d4d33e-473f-4842-a3a8-c8266aee8fab&DisplayLang=en.
• If you are using .Net 1.1, get the test package from http://www.microsoft.com/downloads/details.aspx?FamilyID=e54be8be-22af-4390-86e1-25d76794d5c7&DisplayLang=en.
• If you are using .Net 1.1 SP1, get the test package from http://www.microsoft.com/downloads/details.aspx?FamilyID=9bbd5617-49ae-40bf-b0fa-f9049349c6f5&DisplayLang=en

You will need to choose the version that is specifically marked for "Tablet PC / Media Center" (for 1.0 hotfixes) or "Windows Server 2003" (for 1.1 hotfixes).  Note that you can’t use the regular Windows XP Pro update – we use a different install method for .Net on XPE that confuses the update installer.
3. Download the exe for the hotfix from the Download Center.
4. Extract the exe to a local folder by running
   
   <name of exe> /x:<folder>.
   
5. If you have .Net 1.0 SP2 or .Net 1.1 SP1 installed (not .Net 1.1 in XPE SP2), you will need to add an additional registry value – the update package is checking this registry key as a prerequisite.  You need to add
   
   HKLM\Software\Microsoft\Updates\.NETFramework\1.1\SP1,(DWORD)Installed=1.
   
   Note that this key name should be changed as needed to 1.0 or to a different service pack level if there is a higher .Net Framework SP installed.  This key is unnecessary for .Net 1.1 installs.
6. Go to the folder that you extracted the .Net Framework hotfix to in step 4 above and open each of the update*.inf files in the update folder.  There is a [Version] section at the top that you will need to update the following values for:
   
   NtBuildToUpdate=2600
NtMinorVersionToUpdate=1
MinNtServicePackVersion=###
MaxNtServicePackVersion=###
ThisServicePackVersion=###
   
   The values of Min, Max and This for service pack should match the CSDVersion value in your registry at HKLM\System\CurrentControlSet\Control\Windows.  For example, for XP Embedded SP2 this value should be 512, for XPE SP1 this value is 256.
7. Now you can run update.exe from the update folder on your embedded device (assuming your embedded device has the Desktop QFE Installer support component, or includes the dependencies update.exe needs to run correctly).

We have verified these steps via PSS and Test, and they work as advertised.

Pain in the butt?  You’re right – we’re working on a quicker, simpler way of doing this with DUA.  If you’re not using DUA, you’ll have to either do these steps manually or script them yourself – the easiest way I can see would be to prep the install in steps 1–4 and step 6 once, then write a script that makes the registry changes and runs the installer for steps 5 and 7.

Suit may revise chapter on tech history: Origins of MS-DOS

The article itself isn’t what’s interesting here (well, it’s interesting, but on a different level)  – it’s the last three paragraphs that summarize the relevant portions of the book “They Made America”:

Describing the development of CP/M, [Harold] Evans wrote that "[Gary] Kildall created the bedrock and subsoil out of which the PC software industry would grow."

"Entirely out of his own head, without the backing of a research lab or anyone, he wrote the first language for a microcomputer operating system ... before there was even a microcomputer," Evans wrote.

Huh?  Obviously, the author never read “Fire in the Valley”, or just chose to ignore Steve Wozniak, Steve Jobs, and the entire Apple computer company, who had a working microcomputer (which I cut my programming teeth on back in the day) well before IBM ever decided to make the PC.

I remember when a personal computer – a normal desktop machine – had less memory in it than the smallest flash cards you can buy.  My first computer, and Apple //c, had 128Kb (yes, that’s kilobytes) or memory, which was double the RAM of the other Apple ][ models.  Nowadays we’re building embedded systems that run on 1Gb CF cards with half a gig or RAM, and my 64Mb Pocket PC can use 512Mb SD cards no bigger than my thumbnail.  I’m not sure what to be more depressed over – that I can carry more computing power in my pocket than I had twenty years ago, or that I’m not even 40 yet and already talking nostalgic about “the good ole days”…

Suit may revise chapter on tech history: Origins of MS-DOS

Bill Gates to Receive Honorary UK Knighthood

Yes, we all know that, as a U.S. citizen, he can’t carry a title of nobility, but there is is anyway.  He can’t go by Sir William, but he can sign his name Bill Gates, K.B.E. (Knight of the British Empire).  And no, I don’t know if he’s taking jousting or swordsmanship training… :-)

Yahoo! News - Bill Gates to Receive Honorary UK Knighthood