Just wanted to put up a short posting to explain why I've been almost entirely absent from the community forums for the last couple of weeks.

I'm dealing with a number of issues at the moment, and simply haven't had any time available to me. I'm working hard on finishing the WinPMail to Visual C port, aiming for a release in the very near future, and am completing a v4.53 release of Mercury which should also be out very soon. There's also a relatively low-importance security update for MercuryI which I've had to track down and fix - I should be able to release that in the next couple of days, although I stress it's a fairly low-risk issue, because it requires a successful login to work.

As well as this, we're doing some system modifications here and I have had some personal issues to attend to.

So, I apologize for the silence, but I should be back in the mix before very much longer.

Cheers!

-- David --

[Rant mode on]

Another week where I've been very quiet... This time, though, I find I'm actually quite angry at the reason. For the last three-odd weeks, I have been writing a help system and porting the Pegasus Mail help to it. Why have I been doing this? Because Microsoft broke its contract with developers.

Ever since it was first released, Pegasus Mail has used a Windows help system called WinHelp: WinHelp was a standard part of the operating system and worked quite well. Over time, for reasons I've never really quite understood, Microsoft drifted away from the WinHelp model towards a new help system called HTMLHelp, which uses Internet Explorer to display help pages. I personally never thought HTMLHelp offered any real advantages; furthermore, changing to HTMLHelp would have taken considerable time and effort, and

worse, would have required all my translators to go through the same

awful conversion process, something I wouldn't wish on anyone. I and my translation teams have made a very extensive investment of time and effort in WinHelp, and based on the feedback I regularly get from people, nobody was noticeably unhappy with it (one of the more regular pieces of "nice" feedback I get from people is how comprehensive the help system is).

Enter Windows Vista. Quite late in the pre-release process for Vista, Microsoft suddenly announced that they didn't like WinHelp any more, they didn't think anyone should be using it, and they wouldn't be including it in Vista. What's more, they specifically forbade developers dependent on WinHelp from distributing it with their applications. Microsoft's position was apparently that everyone should be using HTMLHelp, regardless of the effort, expense or practicality of doing so. I also have to say that Microsoft offered exactly zero assistance in moving between formats; there was an existing conversion tool, but it was useless.

That's not the end of the story, though. At some point in the endless patching process for Internet Explorer, Microsoft made a change that effectively crippled HTMLHelp: if an attempt was made to display a help file stored on a shared volume (for instance, a file server), the help file would simply fail to work with an incomprehensible error message ("Action cancelled"). While there are some possible fixes for this problem, they all involve an overall reduction of security and are fairly technical (registry editing). What's more, because the problem would occur in our help file, people would come to *us* for technical support on the issue, even though it's actually a bug in a Windows system component.

So here we are: under Vista, the only help system available to us is one which will fail to work in one of the most common installation scenarios for Pegasus Mail. The one that works fine (WinHelp) can only be downloaded from Microsoft by the end user - we can't supply and install it ourselves. From a developer's perspective, this is a nightmare. In the end, the ONLY solution available to me was to write my own help compiler and display subsystem, so I can continue to use the sources that I and my translators have so laboriously produced. This has not been an easy process, but I think the results are good: my testers got the first working cut of this code last night, and so far the feedback has been quite positive.

But I can see you're asking why I claim that Microsoft has broken a contract... ?  When programmers develop for an environment like Windows, they use programming interfaces called "APIs", provided by the environment's developer - in this case, Microsoft. The API is a contract between Microsoft and the developers who use it, a contract that says "Provided you follow the rules we lay out in the documentation, we'll guarantee that your program will work as you expect, and that it will continue to work as you expect in future". In this case, Microsoft have reneged on the deal. Instead of simply leaving developers like me in the lurch, they could have done any of a number of things: they could have allowed us to distribute WinHelp with our applications; they could have provided proper transition tools; they could have ensured that the system they WERE providing actually worked properly... But they did none of these things. They didn't even give much in the way of warning (six months is far from adequate for something as important and substantial as a help system).

So, I've written a complete help system. I think it's probably quite a lot better than what we had, and it's at least as good as HTMLHelp; what's more, it will work correctly even where HTMLHelp does not. But I should not have had to waste a month of my life doing this when there are so many more interesting and important things to do. I really wouldn't have thought Microsoft could have sunk much lower in my estimation, but it's one of their talents that they always seem to be able to do so. Grrr.... [8o|]

[ Rant mode off ]

-- David --

Yesterday, the US Dollar hit its lowest point ever against the New Zealand Dollar.

In that one sentence, you can see encapsulated much of the financial pain and difficulty that developers like me have been experiencing for quite some time. Many people don't realize that different countries use different currencies, and that those currencies' values change over time in relation to each other. What this means is that when someone pays me some amount in US Dollars, I actually receive a different amount in New Zealand Dollars (my local currency). The amount I receive depends on a floating, variable rate called an "exchange rate", which is the amount a bank will pay for a foreign currency, and which is affected by all sorts of economic factors.

For the last five years, the US Dollar has been in a kind of freefall against most other currencies, as the US economy flirts around the edge of international collapse. This has meant that US currency has been worth less and less - but most people probably don't realize *how much* less. Well, as a matter of interest for myself, I did a comparison yesterday. On July 18 2002, if someone had paid me US$1000, I would have received NZ$2039.15. Five years later, the same US$1000 would have yielded NZ$1250.93 - that's a difference of $788.22, or well over a third. My New Zealand dollars still buy me pretty much what they bought me five years ago (inflation is pretty low over here), but I'm getting far fewer of them. Standard economic wisdom has it that I should simply increase my prices to cover the currency changes, but if I did that, a US$150 license would now be costing close on US$250, and most customers simply won't wear increases like that. What's more, my so-called "business model" has traditionally made it quite difficult for me to increase prices in any event, because I have always felt it was a matter of honour to accept any price I had previously advertised.

By contrast, if someone had paid me EUR1000 in 2002, I would have received NZ$2024.29, whereas now I would receive NZ$1724.13 - still a drop (reflecting the relative strength of the New Zealand economy), but nothing like as severe a drop as the USD, where more than a third of my income has simply vanished in a puff of banker's logic.

I bet most people have never even thought about things like this - after all, not many people really do much in the way of international transactions... But for people like me, for whom almost every transaction is international, it's quite a serious issue, and there's no sign of relief on the horizon. So, we tighten our belt a little more and eat out a little less... <grin>.

Important disclaimer: This is not intended as any form of solicitation of support from my users, who have been generous and kind beyond my expectations: it's just an exposition of a problem most people probably aren't even aware exists, and is provided purely as an insight.

Cheers!

-- David --

Regulars here may have noticed that I've been a bit quiet for the last week or so... I've been putting in one last heave of effort to complete the internal interface overhaul that I've been working on for a while (it has felt like forever at times).


It's been quite a task: something like 25,000 lines of code have had to be more or less completely rewritten from scratch, and a considerable amount of debugging has been required to get everything just right... So what  benefits do you, the end user, get from all this work? A fancy new user interface? A whole lot of new and powerful features? Pet peeves finally corrected? Well, although it pains me to say it, the visible benefit you will see from all this effort is precisely nothing. [:(]

It's a bit like getting the engine in your car overhauled. It costs a lot of money, takes time, and is quite inconvenient, yet when it's done you don't really feel like you've gained anything - the car just goes the way it did before. The only real satisfaction is knowing that you'll probably get another 100,000km before you have to have it all done again. Well, a large software project is not much different, really: over time, things get tacked on and hacked on until eventually the whole thing looks like it's being held together by the machine-code equivalent of duct tape. You finally reach a point as a software author where the whole shebang becomes so hard to maintain that it's like a seized-up engine: only a major overhaul will get things running smoothly again. So it has been with Pegasus Mail - seventeen years of development has taken its toll, even though I consider myself a careful and tidy programmer: the best part of a year ago, it consisted of 460,000 lines of code written for a compiler that hadn't been supported in over five years, with as many untidy ends as a packet of homemade spaghetti: now, though, the program is hosted in a current compiler environment, and has internal interfaces that will allow it to grow in the ways it will need to produce version 5 in a maintainable manner.

So, doing this overhaul was about as much fun as a root canal from a sadistic dentist, but it was essential, and now we can move on. The next goal is to release a v4.42 build as soon as possible (lots and lots of small problems have been fixed, and my testers assure me that the new builds are much faster than the old ones), then to move onto v5, for which I have so many cool new ideas that I can barely wait to begin realizing them.

Cheers!

-- David --

With Mercury/32 v4.5 now into the end stages of pre-release confirmation (the release candidate archive went out to the beta testers last night), it's safe to say that the light is visible at the end of what has been a very, very long tunnel.

Now, I would never attempt to defend the fact that there has been a three year gap between releases - a delay like that is damaging, and it should never have happened. Suffice it to say that I have learned a number of difficult lessons about managing large, complex projects as a result of this process, and that it should thus be possible to avoid having it ever happen again. That said, though, I suspect that very few people out there really have any idea what it's like to make a release of a piece of major software, especially when that software is commonly used as critical infrastructure... So, here are some purely personal insights into why I find getting up to and through a release so hard.

1: Testing, testing, testing   Those of you who use it may have some appreciation of just how feature-rich Mercury is: the program has settings for almost anything imaginable, and under the hood, there is a very rich plugin interface that allows clever people like Lukas Gebauer to add the things I either can't or haven't. The more feature-rich a program becomes, the harder it is to test, because there are so many more variables and so many more paths through the code. Add to this the fact that Mercury is heavily threaded (a technical term meaning that it can be doing many things at the same time) and that thread synchronization issues are among the hardest problems to reproduce, diagnose, and fix, and the testing process becomes a literal minefield. Testing Mercury is far, far harder than testing Pegasus Mail - orders of magnitude harder. Every time a feature is added to Mercury, testing begins again almost afresh, because every addition can have side-effects - unanticipated problems where the addition disturbs something already in existence - that have to be tracked down.

2: The dreariness of maintenance   There was an interesting thread in the off-topic forum here recently where a community member asked why programs had bugs. On the surface, his comment was perfectly fair, but in truth, any program larger than a few lines is going to have problems that creep in: the larger the program, the more possibilities there are for bugs, and complexity increases those possibilities even further. Software is never finished - it's always growing and changing, which means that the bugs are growing and changing too. Allied to this is the perpetual process of rewriting code - taking things that used to be "good enough" but now are not, and making them "good enough" again. At some stage in the life of all large software projects, you reach a

stage where you spend more time tracking down bugs and rewriting old code than you

do adding new features. This maintenance can't be avoided and mustn't be rushed (or else you'll typically just make things worse), but unfortunately, programmers are almost always relatively normal human beings, and like change and variety in their lives: having to spend most of your time reinventing or reworking old things can be pretty dreary, and on a cold Winter's morning, it's often the last thing you'll want to do. Maintenance, therefore, can be a slow process, if only for human reasons.

3: User expectations   It's a common truism in the industry now that user expectations get higher with each passing day: users expect programs to run flawlessly, to be easy to use, to cost nothing, and to have feature sets that match their every need. With higher expectation has also come lower tolerance, whether tolerance for errors, tolerance for ease of use, or even tolerance for appearance. The problem with higher expectations is that they are, obviously, harder to meet - but worse, they are usually exponentially harder to meet: making something "prettier" is actually a very difficult and time-consuming process, and even though it produces little actual tangible benefit, users expect it, even in programs like Mercury. If it's not there, lower tolerance means that people get more aggressive and more turned off. The difficulty and expense of producing programs that meet user expectations these days is reaching the point where only large corporations with huge resources will ever be able to afford the process. User expectations are basically killing the small-to-medium sized player.

4: Resources, resources, resources   I suspect most non-software-developers really have no conception of what it costs to produce a piece of software - "A PC on a table in your bedroom - what more do you need?" (that's an actual quote from someone who shall remain nameless, by the way). There are compilers (Visual Studio costs over $2000 here now), documentation tools (FrameMaker costs $1700), file servers for each supported environment, test servers, testbed systems for various versions of Windows, high-speed Internet links (unfortunately very expensive in New Zealand), domain names, certificate fees, support subscriptions and upgrades for software and development tools, books and reference materials, third-party software licenses (we pay over US$2000 per annum for the very small number of third-party tools we license), sundry development tools (such as Igor Arsenin's excellent TaskInfo product), electricity, banking and business costs, accounting costs... The list goes on. The cost of doing business gets higher every year, and peoples' willingness to pay in support seems to dwindle (and please, don't think of this as me criticizing my user community - it's a general statement about the world the Internet has become). Reduced resources mean making do with less, which in turn extends the time to release.

5: The dread of feedback   This one's a strange one, because it's a complete flip-flop from what I used to experience. In the earliest days of Pegasus Mail and Mercury, releases were exciting, because they were my chance to show the world all the cool new things I'd done. Because the world was more of a community back then, I got lots of supportive mail each time I did a release, which was also exciting and uplifting. These days, in the first few days after a release, the mail I tend to get is different: sure, there are still people who write to say thank you without strings or qualifications, but more normally the messages start with "Version xx is great, but...". It's really hard to describe how soul-destroying it is to release something you've worked really hard to produce, only to start getting wishlists and gripes almost immediately. When I say "gripes", I'm not saying that people are necessarily rude - it's usually just people expressing their annoyance that their pet feature or fix didn't make it into the release. And then there is the out-and-out rude mail; sadly, I always get a couple of those: these are the people who tell me that I should "just stop wasting my time and get a job at McDonalds (if they'll have me)". (And yes, that one's an actual quote as well). There's only a few, and they're always from people who either have a serious grudge of some kind or are simply ill-bred or psychologically troubled, but they have an impact out of all proportion to their importance. Just one of those messages can depress me so badly that I'm incapable of being a functioning human being for the remainder of the day. After seventeen years of doing this, you would think that I might have developed a thicker skin about this kind of thing, but I haven't: it really hurts, and over time, the anticipation of the mail I know I'm going to have to handle has made the process of release more and more daunting, more and more difficult.

Now, this probably all sounds like me complaining, but I'm not really... All I'm doing is summarizing a reality that became inevitable once the Internet reached the level of being a commodity. I should probably toughen up and lighten up, especially since I still actually enjoy the development process for the most part. If only the business of doing a release wasn't so stressful... But wishful thinking doesn't change the world.

Cheers!

-- David --

PS: If there are other software developers out there who read this, I'd love to hear your comments and experiences on the release process.

Last weekend, I wrote my first ever program in C#. Now, admittedly, in keeping with long-established historical tradition, it was only "Hello world", but even so, it felt like a step into a whole new universe.

I've been writing programs for a very long time now - getting on for thirty years, in one form and capacity or another. I've mostly written in C, although I did a lot in Pascal back in the CP/M days (I can hear the younger members saying "CP what?!?" as I write this), and have even written programs in (ugh) Basic. I'm probably one of only a handful of people left alive who can actually remember how to program in Focal-8, and I've spent years trying to forget how to write in Fortran... But C# is a sign of how much the world has moved around me, and how different everything has become.

For someone used to using the Windows Win32 API and writing procedural code, the C# and .NET way of doing things can be quite mind-boggling, particularly when you throw in some of the new .NET 3 features such as Avalon (Windows Presentation Foundation). There is quite literally so much information density there that I find myself asking again and again how anyone can ever learn enough of this stuff to be able to work with it competently. It's also daunting to think that the way you've been doing things for nearly twenty years is finally reaching the end of its usefulness, and that soon (all too soon!) change is going to be forced upon you whether you like it or not... So the world moves on.

I guess there are two ways you can deal with change - you can either resist it and hope that enough other people resist it to cause it to fail, or you can embrace it early and hope to reap the benefits over time. Both approaches have risks, but historically it's a truism that (in the immortal words of Douglas Adams) "Resistance is useless!" - or, if you take a more sinister viewpoint, "Resistance is futile - you will be assimilated". I for one find the intricacy and depth of the C# / .NET combination strangely seductive - the first time I've been able to say that about a Windows technology since Windows 95 was introduced. Whether this is the path I need to be walking is something I'm thinking about a lot at the moment: I haven't made my mind up for sure one way or another, but I'm definitely approaching it with an open mind, and even some enthusiasm.

Time will tell, I guess.

Cheers!

-- David --

I'm perpetually mystified by the human propensity for self-delusion: we seem to be able to talk ourselves into the most ridiculous things, whether through hopelessly naive optimism, stupidity or selective memory. A wiser head than mine (George Santayana, if I recall correctly) once summed it up quite well, saying "Those who do not learn from the mistakes of history are doomed to repeat them".

From the preceding paragraph, you should be able to glean the idea that I'm not best pleased with myself at the moment. I've got myself into a quagmire, and like all quagmires, it's wider and stickier than I ever expected. I'm talking about the changes to the internal object interface used by Pegasus Mail.

When I originally took this on, it was a logical, worthwhile futureproofing modification that was only going to take a week or two to finish: that was nearly two months ago. Now, don't get me wrong - the "worthwhile", "logical" and "futureproofing" parts are all still completely valid, but seventeen years of doing this should have taught me that it was never going to take only a week or two - especially when the addressbooks became involved.

Pegasus Mail's legacy addressbooks are a source of unending grief for me: they're some of the oldest data structures in the program, dating from the DOS version. Back in the DOS days, programmers had to be really, really careful about how they used memory, because there wasn't much of it available. As a result, the addressbook code is incredibly contorted in places to allow the smallest possible memory use, even though in the days of gigabytes of RAM, the notion is now totally irrelevant. Unfortunately, slanting the entire development of a piece of code towards one priority like this is quite pernicious, because it debilitates almost every other part of the code. The result is that the legacy addressbook code in Pegasus Mail is fragile, awkward, convoluted and unbearably tedious in places, and I really don't like working on it very much.

Now, Pegasus Mail v5 will have a new addressbook format which will, I believe, be an absolute market leader - much more an information manager than an addressbook, its capabilities will make it enormously useful to almost everyone, unlike the antiquated and minimalist excuse for an addressbook we have at the moment. The design for the new format is done, and quite a lot of the code is even written: the problem is that I can't abandon the existing format - I'd get lynched - so I have to make sure that the two formats co-exist, if only to provide an easy migration path for existing users. This means that I have had to overhaul the old addressbook code once more so it can use the new interface I've designed.

The update on the old code is now mostly done, fortunately - although it's been quite a trial. There's still a bit to do though, so it's back to the salt mines for me. *sigh*.

Cheers!

-- David --

Think of the Czech Republic and depending on your frame of mind, images of fantastic architecture, beautiful women, or a long and rich cultural heritage might flicker through your thoughts. For me, though, when I think of the Czech Republic, I think of Lukas Gebauer (and I apologize now for not getting the accents in his name right).

Lukas is a software developer, and a very clever one indeed. He wrote the SpamHalter Bayesian spam filter for Pegasus Mail, and has written numerous plugins for Mercury, three of which (SpamHalter, ClamWall and GreyWall) are now standard components in the Mercury distribution. What probably amazes me more than anything else about Lukas is that he has written these very high-quality programs with almost no assistance from me - not that I wouldn't have been glad to provide it, but he seemingly hasn't needed it! I doubt I could have written code to use my own interfaces with so little assistance, so his work is all the more special because of that.

His latest plugin, GreyWall, is possibly the most startling plugin you'll ever encounter for Mercury. It uses a new event interface I developed for Mercury/32 v4.5, and simply turns away any connections from unknown server/sender combinations with a temporary (400-series) error. For real mail, all this means is that the first message from a particular server may take a few extra minutes to be delivered (all subsequent mail goes through with no delays). For spam zombies, however, the effect is quite dramatic. Current generation spam zombies are not set up to handle retry conditions - if they get one, they typically just skip the address and move on: this means that enabling GreyWall will result in a huge amount of your incoming spam being "turned away at the door", costing you no bandwidth, time or processing power. Experience in the test team has shown that enabling GreyWall can reduce spam levels by up to 90% even with no other filtering in place, and with a near-zero false positive rate!

As I noted above, GreyWall is now a standard part of Mercury, installable directly from the Mercury installer. When you decide to install GreyWall, or SpamHalter, or ClamWall, think of the Czech Republic and of Lukas, and consider going to his site to offer a little financial support to him: he's a very rare breed, and we all benefit from his work.

-- David --
May 6 2007

 

I've recently had to take a small diversion from getting Mercury/32 v4.5 ready for release to prepare a patch for v4.01. The patch works around a vulnerability in the IMAP server where sending IMAP "literals" formatted in a particular way would crash the running copy of Mercury/32. While I was at it, I corrected a couple of fairly significant memory leaks in the IMAP server - these had been discovered during the implementation of the audited memory allocation manager in v4.5 (see my last blog post for more on this).

Having to prepare patches like this raises very mixed feelings in me: on the one hand, I accept that vulnerabilities are inevitable in software that exposes itself to the world, and feel that I should be grateful that the vulnerability was discovered before (as far as we know) any particular damage resulted from it. On the other hand, though, some of the people who seem to spend so much time discovering these vulnerabilities also strike me as being sad, dangerous individuals with fairly significant social problems. The fact that I had to learn about this vulnerability very indirectly (i.e, the person who discovered it made no effort to report it to me) annoys and saddens me. OK, get your jollies by trying to break other peoples' work - that's fine, and it's even quite constructive and helpful from a certain perspective; but if you succeed, for Heaven's sake tell the author so he can fix it! Any kudos you might get for being such a clever bunny and discovering an obscure problem is immediately eviscerated by not acting responsibly with that discovery.

Anyway, to whomever discovered this weakness - my sincerest thanks: one day, perhaps I'll be able to meet you and shake you warmly by the throat.

-- David --

 

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 right that it was really essential to do this work.

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 that 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 --

 

This is a short post to indicate where we stand with Mercury/32 at March 26 2007.

The next release of Mercury/32 will be v4.5 - the skip in version numbers indicates that a huge amount has gone on internally, but that it doesn't look that different. V4.5 has been almost entirely about reliability, scalability, performance and robustness: on the surface, not much has changed, but "under the hood" there have been thousand of changes and improvements. That said, there are some new features there as well:

• Disclaimers: a new filtering rule action makes it easy to insert text into any message. While intended mainly to allow sites to inject disclaimers into the mail sent by their users, it can also be used for many other purposes.
• Public folder delivery: Mercury can now deliver directly to Pegasus Mail public folders, making the facility vastly more useful
• Delivery status notifications: Mercury can now generate customizable progress notifications for messages that are delayed or being retried
• Mail Queue overhauled: The Mercury main mail queue has been totally overhauled and should now be both vastly more reliable and anything up to 100 times faster than before
• Spamhalter and Clamwall included:  Lukas Gebauer's terrific Spamhalter Bayesian filter and Clamwall Antivirus integration modules are now a standard part of the program
• Many reliability improvements, especially to the mailing list editor, the MercuryI IMAP server and to error reporting in most modules

Starting with v4.5, Mercury will become a licensed product. We have spent a long time agonizing over this move, and exactly what it means: what we have come up with is essentially an honour system. As shipped, the program will have no restrictions or limitations, but will have an enlarged status bar indicating that it is unlicensed, and will inject a "Sent by an unlicensed copy of Mercury" header in all outgoing mail. Licenses will be free for individuals, families and charitable organizations. Businesses, government bodies and academic institutions will be obliged to purchase licenses based on the number of users they have. Once a license is installed, the enlarged status bar will return to normal and the outgoing mail header will be removed. These license terms represent a compromise between my personal desire to make Mercury totally free, and the reality of needing funds to live and continue development; the idea is to provide sufficient motivation for sites who are likely to pay for a license to do so, without placing overly onerous restrictions on those who cannot justify doing so.

Mercury/32 v4.5 is essentially ready for release now: I just have to finalize the licensing issues, and it will then be made available almost immediately.

Cheers!

-- David --

Just a short initial note to describe where we stand at 26 March 2007...

For the last few months, I have been porting the Pegasus Mail codebase (300+ source files, 450,000+ lines of C code) from the ancient Borland compiler I have used for many years to Microsoft Visual C++. The process has proven to be quite a lot more involved than I expected, and I and the test team have spent a lot of time tracking down issues resulting from the port. The primary benefit of this move is improved debugging, and we have already tracked down numerous small to medium reliability problems as a result of doing so. Moving to Visual C++ also gives me a future development path for the Windows environment, so it was really an essential task.

In the course of the port, I also decided to make some major changes to one of the internal interfaces Pegasus Mail uses. This process has been even more complex, but provides the basis for a very significant new plugin programming API that will be available in future.

The overall process of porting, checking, and modifying the interfaces is, however, now mostly done, and I hope to get back to significant coding of new features soon. I wouldn't care to estimate when we might have another release of the program, but probably not before the end of May at the earliest at this stage. The exact feature set that will appear in the next version is also still not firmly decided - as we get tighter on it, though, I'll provide information here.

Cheers!

-- David --

 

Over the years, a comment I have heard frequently is that people would like to know a little more about the person behind the programs... This blog is my answer to that request: I'm sure it will bore many people, and annoy some, but such is the way of the world... [;)]

As such, this blog is intended as a piece of pure self-indulgence... [:)]  It's

a place where I will periodically comment, rant, muse, or ponder things

that interest me at the time. There is no democracy here: only I can post in this blog - I hope, however, that people will perceive it as a benevolent dictatorship.

My interests are quite wide and varied, but include photography (I was a professional photographer many years ago), fine wine, music, English literature, comedy and cooking, so expect to see that type of stuff occurring here from time to time.

I don't guarantee that I'll update this blog frequently or copiously, but I promise I'll do my best.

Cheers to you all!

-- David Harris --
Author, Pegasus Mail and Mercury.

This blog is intended as a kind of diary on the development of Mercury/32. As I work on the program, I will periodically make

postings here describing what's being done, and what plans are being

made.

Only I and my formal beta test team can post or reply in this blog - if

you are a registered member and see an issue on which you would like to

comment, please start a new thread in the appropriate forum.

Cheers!

-- David --

This blog is intended as a kind of diary on the development of Pegasus Mail. As I work on the program, I will periodically make postings here describing what's being done, and what plans are being made.

 
Only I and my formal beta test team can post or reply in this blog - if you are a registered member and see an issue on which you would like to comment, please start a new thread in the appropriate forum.

Cheers!

-- David --