I started reading the Riverworld series last year and finished the fourth book (the ending) tonight. It's a cool scifi concept - everyone who has ever died gets resurrected on a world with one big river running through it, in a valley bounded by unscalable mountains.  It essentially one big one-dimensional world, and it started off with such potential.  Unfortunately, the ending is disappointing. Just read the amazon.com reviews.

I recommend reading the first book, and just leaving it at that (it's has a somewhat satisfying ending).  I don't have much else to say about this series, but you can tell that I'm a little incensed by the anti-climacticness because I'm bothering to blog about it !  I took quite a bit of pleasure just reading the amazon reviews of the fourth book, so I can nod my head "right on brother!"  As I said, the first book was well-written and is worth reading, so don't let my review turn you off completely. Just ignore the other three books.  I wished I had read reviews before picking up the series, but I figured it must be pretty good since the Sci-Fi channel was making a series of it.  A lesson I learned... :)

Digital Picture Frame (Part 1)!

I was inspired to create a digital picture frame after seeing the Junktop Revival Wiki as well as Mike Hall's project. I wanted to reuse one of my old laptops, a Thinkpad, but the issue was that I didn't want a hard drive - a hard drive would just be too noisy for me. So out went XP, in came Windows CE.

Here are the features of the laptop digital picture frame:

• No hard drive
• Boots off a CD-ROM
• Recognizes and reads random pictures off of a USB Mass Storage device, fired by a timer. Storage device is hot-swappable.
• no keyboard or mouse necessary for basic operation
• two keyboard keys can increase or decrease the image display timer interval
• spacebar can jump to the next image
• after bootup, no more CD-ROM access is required. The whole Windows CE operating system is less than 10 megs, and fits neatly in ROM. (I can cut it down further if I looked hard enough )

The Application

The software was relatively straightforward.  Upon startup, it maximizes to take up the full screen and gives it a black background. It polls every five seconds for files.  The frequent polling is necessary because the USB storage device isn't ready immediately after the OS boots up.  Anyway, after the first time it reads the files, the timer interval goes to 60 seconds, which is adjustible by the keyboard.

For each tick of the timer, the program gets a list of the files in "\Hard Disk" (that's what Windows CE recognizes the USB Mass Storage device as) and displays a random image.  That's pretty much it.  If there's an error reading a file, the program simply just leaves the existing image up and waits for the next tick.

The image stretch logic is pretty simple - the app gets the dimensions from the Bitmap object, and stretches the picturebox that the Bitmap is displayed in to such that the proportions are maintained while maximizing the real estate of the screen.

I took Windows CE's Platform Builder 4.2, and generated a custom Windows CE OS.  I based it off the Mobile Handheld design, but took out a bunch of things, and added .Net CF and USB support.  Ideally, I wanted PCMCIA support in my device so then I could plug in a WiFi card, but I couldn't find a driver for the PCMCIA chipset, a TI1225 (note, this wasn't my Thinkpad I was looking at, this was in my Dell Inspiron. I flipped back and forth between the two laptops for this project ).

Windows CE 4.2 and 5.0 both came with drivers for the TI1250 chipset, but not the 1225. I went online and found a vendor who offered a TI1225 driver, but they didn't seem to be interested in giving me a copy  so I decided to forego it.  I didn't want to write a driver for this project. So, as I said, I added USB support for Mass Storage.

For the platforms, I added a CEPC and Emulator platform.

There were two custom modifications I had to make: Change the taskbar to be auto-hide and not on top, and launch my app (called "pictureframe.exe" for you creative types).

To set the taskbar state, I added these .reg keys to %_PROJECTOAKROOT%\files\project.reg

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shell]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shell\AutoHide]
      @="
"

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shell\OnTop]
      @=""

I got these reg keys by manually setting them in the emulator, and using Platform Builder's remote registry editor to see what changes in HKLM\Software\Microsoft\Shell.

The second task - to boot up my app, I first added this line to my project.bib file:

    pictureframe.exe pictureframe.exe NK S

to include the application in the image. Then I added these lines to project.reg to have the OS automatically boot up my app:

    [HKEY_LOCAL_MACHINE\init]
    ; @CESYSGEN IF CE_MODULES_SHELL
         "Launch99"="pictureframe.exe"
         "Depend99"=hex:32,00

The first value specifies that pictureframe.exe is to be launched, and the second line says to wait for Launch50 (hex 32) to be executed before launching pictureframe.  Launch50 is explorer.exe (you can find this in shell.reg in the release directory).

That's pretty much it. Next is the:

CD Preparation

I took a standard CEPC boot floppy disk (there is none in the final version), and modified it so that it will mount the CD-ROM drive as drive R:, and execute:

    loadcepc /L:800x600x16 r:\nk.bin

The image is nk.bin, and the /L flag is the resolution to run the OS at (the Thinkpad could only do 800x600, the Dell could do 1024x768).  After I created the CEPC boot disk, I booted up Nero, selected CD-ROM (boot) as the CD type, and had designated the floppy drive to be the source of the boot image.  I was surprised at how complicated this was, actually. I thought that Nero could just put a DOS boot sector on the CD, but it needs a source drive to copy it from. When you think about it, it kinda makes sense (copyrights of DOS 6.22 and all that). 

In the end, I had a spanking usable Windows CE image with my software on it!  (OK, it wasn't this simple, it was a very iterative process ).

I'll post the hardware hacking part next time. I'm trying to keep these entries short!  If anyone wants more specifics on the source code (ugly) or the Windows CE project (easy), just drop me a line.

Mike Hall recently blogged about me building a digital picture frame. It is true :).  I'm going to post some images and some text about it once I write something up - I downloaded BlogJet for that very purpose.  It's written in .netCF, running on a custom Windows CE OS. The reason I used Windows CE is that I wanted something compact that could operate without a hard drive - no noise! I was then able to burn the whole OS and app onto a CD (flipping necessary reg keys to start up my app).  Another advantage of CE is that I could potentially copy this onto a CF card, and use an IDE-to-CF adapter to completely remove the laptop of moving parts.

Here's a quick preview:

BTW if anyone knows of anyplace where I can download cool 1024x768 wallpaper for free without any watermarks, let me know ;)

Thanks to mikehall, I'm up and running on blogjet now. Testing an image upload... I took this at the 2002 Tulip festival (overexposed so it looks great).  OK I admit I edited the sky since the original pic was all white :)

As some of you may know, I’m in the process of writing an RSS reader for my Microsoft Smartphone 2003.  It will be running on Net CF.  Since it is an offline RSS reader, I wanted to have the ability to download RSS files for offline reading.  So I had a function, StartDownloadAll() which would iterate through each feed that I’m subscribed to, download the data, eliminate dupes and old items, and save them. In the code, sprinkled throughout, I have lines like:

this.text = “Getting data”;

where this refers to the form.

When I ran through my prototypes, I realized that it was too slow to do this synchronously, I needed to spawn a thread to do this so the UI can still be responsive to the user.  So because C# makes it so easy to create new threads, I ran StartDownloadAll() asynchronously, in its own thread (I’m glossing over some hairy synchronization details, which I’ll get to below).

The problem with doing this is that in C#, you’re not allowed to update a control from a thread that did not create it.  If this was Win32, I would have been more alert, but C# lulled me into a false sense of “everything will work, or else it will throw an exception”.  However…

After I did this, my program started behaving erratically. I’d get random Close() events (and who knows what else could have gone wrong?).  Eventually, I realized my mistake and converted offending functions to use Control.Invoke() (Actually, I used a modified ControlInvoker class).  This leads me to the questions:

1. Should NetCF throw an exception instead of just providing undefined behavior when someone updates the UI from a separate thread? In light of .Net’s attempts to prevent users from shooting themselves in the foot, would this be a good philosophy to follow? I recall hearing that Avalon will provide this functionality, but it’s just a rumor…  I don’t even work in the Windows division so I probably wouldn’t know :)
2. Would it be costly to have a class verify that a control was created on a different thread before calling Invoke? I might actually code something up, but I don’t think it will be trivial – I’d probably have to manually keep track of which controls were created on which threads.

OK, enough of that.

I mentioned some hairy synchronization details.  Here’s something that I found out (and probably you .NetCF experts have better workarounds)… suppose I have

The QuitDownloadingStuff() method will cause the running download thread to quit, and wait for it to quit before proceeding.  However, as part of the quitting in the other thread, it does the Control.Invoke() equivalent of:

            this.text = “Aborting…”;

This calls back into the UI thread, which is waiting for this function to exit, and thus we end up in a deadlock!  I was sorely confused when this was happening to me – since I didn’t have any double-locking going on.  I fixed this by having QuitDownloadingStuff() return immediately, and I launched a timer to detect whether the thread is actually dead before allowing closing to proceed.

If anyone has any better ways of doing this, let me know, I’m all ears! :)