<p>Mercury/32 v4.5 is all about stability and robustness, and it was with this in mind that I began a major overhaul of the way memory is handled in Mercury about two weeks ago. It was a toss-up whether it was more important to get a release out the door or to make these important changes, but in the end, I decided that I've spent so long trying to get v4.5 <b>right</b> that it was really essential to do this work.</p><p>The changes insert a new layer between Mercury and the system, responsible for tracking the way memory is allocated, used and deallocated. For those of you who aren't programmers, the computer's RAM is a finite resource that you have to ask to use, and when you've finished using it, you have to give it back to the system. If you use a piece of memory, but don't give it back, then you end up with what's commonly known as a "memory leak" - the program uses more and more memory until eventually the system runs out and crashes. This all sounds straightforward, but as a famous man once said, "nothing is ever <span style="font-style: italic;">that</span> easy"... There are many paths through a program, and it's perilously easy to lose track of a chunk of memory you've allocated, resulting in it never being freed. The problem is so fundamental that I don't think it's unreasonable to say that just about every widely-used Windows application will have memory leaks at some level - it's just that for many programs, particularly those that run for short periods then terminate, it's not an issue (Windows always recovers all memory allocated by a program when it terminates). In a program like Mercury, which can run for weeks at a time, though, memory leaks can get to be a serious issue - hence the need to audit memory use closely. This is what the new code I have now implemented does - it allows me to see at a glance any memory that is not being released when the program exits. The new audited memory allocator has already proven worth the release delay it has caused, though, because it has allowed me to track down a number of memory leaks in the MercuryI IMAP server - leaks that I would never have had a chance of finding otherwise. In some ways, the new allocator is a crystallization of what has happened right throughout the whole process of developing Mercury/32 v4.5 - it's crucially important, has had an enormous impact on the reliability and robustness of the program, and, alas, is totally invisible to the end user. As a programmer, it can be frustrating to know just how much effort has gone into something "under the hood", as it were, yet also to know that the end user will have no idea or understanding of that effort... *sigh*. Oh well, I guess that's why programmers get all the money, gorgeous chicks and fast cars they do... <wry grin> -- David --  </p>