031215

0830 - I went up to the bridge at 0630 again today. Emil and I had a raging talk about evolution and the Rare Earth theory. The Captain came in half way through it all and listened. He never has much to say, though.

One thing I forgot to mention last night was that the Second Officer told everyone late yesterday that he'd heard on short-wave that the US had captured Sadaam Hussien in Tikrit yesterday. He also said that they had actually captured four or five Sadaams (doubles). That was all the news. It will be interesting next Saturday to arrive in new Zealand and see what the news is.

Sometime between now and Saturday, we're going to loose a day due to the International Date Line.

Had breakfast at 0730 and John was there. I told him about Sadaam and then we discussed what the US might d with him and then segued off into Capital Punishment and incorrigibility.

Weather is about the same. Seas are calm, we have a mild wind coming from the Southeast. The sky is a mix of clouds and blue sky. The clouds look like the cumulus sort for the most part. it think it is all pretty typical for this part of the world.

I'm going to continue to work on memory leaks today. I pretty much blunted my brain on it all yesterday but then I tend to start thrashing from one approach to another when nothing's working and, at some point, I become ineffective.

One is that when I put up a full screen picture of an item, I have owner-draw buttons overlaying the image along the left side of the screen. In this situation, I find that the iPAQ is repeatedly re-executing the WM_ERASEBKGND message handler even though the image and the owner-draw buttons are all displayed correctly. My suspicion is that the WM_DRAWITEM (used for the owner-draw buttons) and the WM_ERASEBKGND message (used for the image painting) are dueling back and forth each trying to have the last word. I will test this theory first and if it is true, I will then try to correct it. This is a bad problem because each time through the WM_ERASEBKGND handler code, we leak a small chunk of memory. Since it re-executes repeatedly, it isn't long before memory has dropped to critical levels.

The second problem, I just alluded to, above. That is that each time we call the CUtil::ImageDisplay() routine, we lose a bit of memory. I took a quick look and I don't see any obvious reasons why this should be so but then I am using some poorly documented calls into the IMGDECMP.DLL and it may have internal problems or I may not understand some critical point about how to use its interfaces.

In any case, if I can solve the first problem, the second is manageable if I cannot deal with it here without access to the Internet.

Today, in the afternoon, the Chief Engineer, Antoni, took John and I on a tour of the Engine room. The photos from this adventure can be found on the December 16th page since that's when I processed them.

Before we went on the tour, I was feeling photographically inspired so I walked around and shot a lot of other photos of the ship above decks.


A tool room	On the aft deck	Pulleys on the aft deck	The door to the steering control room below

Muster station and pulleys	It's dark under the cargo containers	Container support structures at the stern	Looking off the stern

Another view off the stern	Looking forward on the starboard side towards the superstructure	And looking up from the same point at the cargo container support structure	telephoto looking forward

A life preserver	Typical box where container tie down rod parts are kept	Containers. Note, how the tie down rods brace them	The hatch covers are massive. Pins like these hold them down tight.

Between rows of containers. Note, the electrical connections for 'Reefers'	The forward self-inflating life raft.	A pressurized water hose used to damp fires in the hold.	The port anchor assembly on the bow.