Cook Computing

I was planning to buy an iPod Nano but I'm now waiting for the second version. The first doubts came when scratches were mentioned a couple of weeks ago on Tech Ronin:

By the way, my local Apple store has a whole table with about 20 nanos heavily wired for people to play with. You should see the scratching on the screens of those things. They're as bad as my 3G iPod got. I wonder how they've managed to get that scratched just being looked at even by a lot of people?

Now discussion of the over-delicate screen is everywhere. I just read an article in the Times which mentioned the issue.

What are the odds that engineers at Apple knew this was a problem but their views never made it up the management chain? I've seen that happen several times in my career. Can internal blogging open up communication? Maybe, but there would still be the issue that being the bearer of bad news can be career limiting.

Maybe Apple is structured so that people with first-hand experience of issues have a voice? But that leaves the problem of how they could ship something with such an obvious flaw. Was there no field testing? I once bought a pair of running shoes which initially caused blistering round the heel. It was a well-known problem, mentioned on websites and mailing lists. Previous and subsequent versions of that model were fine. Again the company must have designed and produced those shoes without any realistic field testing. Its too late to fix problems when the product has shipped. The damage has been done.

I've spent some time recently investigating a .NET Remoting problem. On the system in question clients implement lease sponsorship. In some cases clients fail to unregister sponsors and so objects on the server are kept alive indefinitely, leading to system failure due to running out of virtual memory space. I thought I would implement some server-side code that would forcibly disconnect objects if they had not been called for a period of time, say one hour, using RemotingServices.Disconnect. If clients failed to unregister sponsors then this new code would ensure that leakage would only ever be up to one hours worth.

But this does not work. The following happens:

• Client requests client activated object and registers a sponsor for it.
• Client makes calls on object and then fails to unregister its sponsor.
• After one hour server calls Disconnect for this object.
• Client attempts call on object and it fails (as expected - "RemotingException - Requested Service not found").
• But calls are still made to the sponsor and object not GC'ed
• Object is only GC'ed when client process is killed.

I'm not sure yet whether this is a Remoting bug or whether I've misunderstood something. Things were so much easier with DCOM. No fiddling around with sponsors and when used in this type of scenario CoDisconnectObject worked just fine.

I've got used to ignoring Google ads in blogs, irritating as they are, but I have to draw the line at ads appearing in the feeds in my aggregator. These invoke an immediate unsubscribe.

When I'm working from home I like to go for a short walk at lunchtime (We've been watching Its Me or the Dog recently. The dog trainer has mentioned several times how important it is for a dog to be taken for one or more daily walks to provide some mental stimulation from the change of environment. I guess the same applies to software developers). Anyway, a couple of days ago I was walking past one of the ponds in the Coxley Valley, when I suddenly saw a flash of blue iridescence streak across the pond. It was a Kingfisher, the first I have seen here. Back home I thought I'd see if there was anything on the web about the valley and came across a fascinating website by Richard Bell, his Wild West Yorkshire illustrated nature diary. He lives lower down the valley from us and the diary has many interesting snippets of information about the wildlife hereabouts. I'm surprised I never came across the site before.

These were the highlights of another dreary day spent trudging through diagnostic log files.

Of the PDC slides I mentioned a couple of days ago DAT316 - Future Directions: Developing Custom Applications using the new Exchange 12 API's - caught my attention. Just out of curiosity really. I doubt if we will move from Extended MAPI to these web service API's on the product I work on. It took a huge effort get to a point where we could use MAPI reliably because of problems with the implementation of the MAPI API, not to mention poor performance, and moving to the new API's would involve an unquantifiable risk that a similar investment might be required. It would be interesting to meet up with developers of other Exchange-based unified messaging products and discuss how they have addressed the issues of getting information in and out of the Exchange message store.

Seen on Jason Langridge's blog, slides from the PDC are available here:

http://commnet.microsoftpdc.com/content/downloads.aspx

I didn't get to the PDC this year. For the first time ever nobody in our development group went.

Its always disconcerting when something you believe in turns out to be not quite what you thought. For a long time I've thought that as long as you build .NET assemblies that are verifiable then you have 100% type-safe code and when running you are guaranteed not to experience any memory corruption. Then a week ago Matthias Kestenholz posted to the Mono list about a problem running XML-RPC.NET on Mono.

$ ./rpctest2.exe *** glibc detected *** free(): invalid next size (fast): 0x084818d8 ***

I replied:

The error you're then seeing looks like a Mono problem, on the basis that the XML-RPC.NET assembly is verifiable and so type safe.

But I had some nagging doubts as to whether this is true. In fact code can be verifiable yet still make calls to unmanaged code using P/Invoke. For example peverify determines that this program is verifiable even though a call to unmanaged code is made (the choice of AddAtom here is arbitrary and could be a call to any unmanaged dll):

using System;
using System.Security;
using System.Security.Permissions;
using System.Runtime.InteropServices;

class AtomSetter
{
  [DllImport("kernel32.dll")]
  static extern ushort AddAtom(string lpString);

  public static void SetAtom(string atom)
  {
    AddAtom(atom);
  }
}

class Program
{
  static void Main(string[] args)
  {
    AtomSetter.SetAtom("foo");
  }
}

To ensure that unmanaged code is not called from an assembly you have to use Code Access Security. In this case if we add a SecurityPermission attribute to the AtomSetter class we get a SecurityException at runtime.

[SecurityPermission(SecurityAction.Deny, UnmanagedCode = true)]
class AtomSetter
{
  // ...
}

By default assemblies running from a local drive have full trust and can call unmanaged code via P/Invoke. Maybe this particular permission should be denied by default. Obviously there have to be calls into unmanaged code at some point but I would prefer this to be allowed by default only in the Framework libraries and not in any of my own code.

Larry Osterman has a post on the advantage of shared services on Windows, arguing that compared to Unix a Windows process is a relatively expensive entity and so it is inefficient if an application splits itself into more than one service each running in its own process.

Each process running drains the system of resources that could be used for your application, so it's important to reduce the number of system processes running. It always annoys me when I install some application and discover that it's installed three or four processes that run all the time on my machine, especially when those functions could have been combined into a single process.

My experience of working on a product running in a single service was that this was a nightmare from a maintenance point of view. Memory leaks and memory corruption can be depressingly difficult to diagnose when you have in the order of hundreds of thousands of lines of C++ code running in the same process. Things are made worse because development was split across several teams and so there was sometimes an unwillingness to fix problems. There was usually no sense of ownership until a problem could be proven to be in a particular product area. The leaks and corruption would get fixed eventually but only after a lot of effort that would have been better directed towards something more productive.

You could argue that more defensive coding techniques and more rigorous development processes should have been in place but it would have been difficult, although worth the investment in my opinion, to introduce these to a product containing a large amount of legacy code. Another recurrent problem was the use of third party libraries. Most of these contained bugs which compromised the reliablity of the system as a whole and with hindsight several of these should have been isolated in their own processes.

I think it was this experience that biased me so much against C++. I don't think it is impossible to develop highly reliable software in C++, its just that the cost of doing so successfully is much higher than most people think and also requires a higher caliber of C++ developer than most teams will be able to recruit. My recruiting experience of the last year or so is that very few developers want to do C++ development now. All interviewees for C++ development positions have indicated some concern about how long it would be before they would move to .NET development (.NET because we don't do use Java). For companies that stick with C++ this is going to be a major problem over the next few years.