The long, boring story of post-version 1.08 HappyMail
Sometime during the summer of 1994, my boss asked me if I knew of an alternative to the known VINES Windows e-mail packages. I mentioned the existence of HappyMail (hereafter, I'll use "HM"). I downloaded it and showed it to him. He thought it was great, but wanted a few things changed.
I changed what I could through the Resource Workshop... icons, strings, logos, etc. ... but eventually he wanted more substantive changes.
I contacted David Ritchie and asked for the source code. He said it was already posted on one of the more popular VINES ftp sites. He also mentioned that the public source code would not compile to the same executable as he was distributing. There were 3 third-party libraries that he was using for spell-checking, some visual elements, and for the file viewer.
He said that if I could provide him with proof that I had a license to use those libraries, that he would send me his code. My boss agreed to that and I purchased two of the libraries. The file viewer library was VERY expensive, and we didn't really need it. David sent me his code (minus the file viewer library) and I was able to successfully re-compile the project in Borland C++ 4.5.
The two libraries are:
ProtoView Control Library (CTL), ProtoView Development Corp.
To resolve the file viewer gap, I wrote a small program called FILEVIEW.EXE which I distribute with all my other HappyMail code. I integrated it into the LAUNCH.C and VIEW.C units of HM as follows:
Errval = ShellExecute(hDlg, NULL, "FILEVIEW.EXE", aRec.FileName, ".", SW_SHOW);
For our internal purposes, this file was always to be found in one of our standard directories, C:\UTIL, so I hard-coded that into HM. That's given lots of people headaches, and I'm sorry for that.
FILEVIEW is a plain text viewer that will also view binary files via a hex-view option. While it was a far cry from the slick viewer that was in David's original HM, it suited our purposes.
So, finally, with my changes, the boss as happy, expending only a tiny fraction of what a commercial Windows VINES e-mail product would have cost.
Very soon after that, we encountered a problem... the file buffer for the body of the e-mails was too small. So, I poked around in the code a bit and found the area in LIBRARY.C which specified the size. I changed it to:
MAXBODY = (unsigned long) 61440L; /* was 6144L */ MAXMSGBODY = (unsigned long) 58000L; /* was 6144L */
I can't tell you now why I choose those numbers, but since no one has since complained about it, I don't much care. :-)
At about the same place in the code, there were some lines that checked for the VINES version number. Rather than fool around with that, I simply removed all that code since we were running at versions greater than 4.11 (David's organization was running some 4.11 and some that were newer.)
At this point, with my bosses permission, I repackaged HM a bit and placed it in the public domain. The world cheered! Well, not really, but a lot of people were pretty happy with the changes.
Then Banyan made the sky fall... they changed the way confirmation was handled, from the server to the client. Since the HM client didn't know squat about confirmation, anyone who used HM with the newer mail DLLs would be doomed to have confirmation not work.
Our INTERNAL solution was to use the older DLLs. There turned out to be nothing in the newer DLLs that we really needed. But since a lot of the users of the public domain version didn't have that option, I attempted to add the confirmation code. "Attempt" is a good word, because, to-date, I have yet to fix it ALL. Most of it works, but there are two scenarios I'm aware of that don't work (or, rather, work too well)... one is: when you've created a message with confirmation, but you save it and not send it. The next time you open it, the mail service will send YOU a confirmation... every time you open it. There are other scenarios which are not yet accounted for.
The line for certification looks something like this:
uStat = VnsSendMailCertification(hVNMAS, UserName, FoldName, MsID, VNS_CERTIFY_READ);
but the real trick is where to put it. I'm still working on THAT!
So that is the long, boring story about version 1.09 of HappyMail.
If YOU would like the complete code as provided to me by David Ritchie, I'll be happy to send it to you. As he required it of me, I would also require it of you to provide me with proof of license of the two 3rd party toolkits he used in the "final" version.
I will most likely send you MY code, rather than his, since I'm not quite sure I have his original code, intact.
You can contact me as follows:
Now... I'm always being asked: when is the (insert problem here) going to be fixed? The most common problem is, of course, the confirmation. The only way I can answer that question is: when I fix it. I have two full time jobs, a family with two young boys, a house and yard to keep up, and mucho bills to pay. I'm afraid the honest truth is that HappyMail is WAY down on my list of things to be working on.
About half of the work I've already done on HappyMail was done at work. But the company I work for is one of the many that have initiated the move away from VINES (to NT, of course; if it's any consolation, it was against my recommendation). Anyway, about six months ago we shifted to Notes mail, so I haven't needed to do anything with HM since then. So, when will it be fixed? When I fix it!
That's the best I can do. I can't even gaurantee that I'll EVER get around to it, ever. I'm sorry to disappoint so many people, but it just isn't cost-effective nor time-effective for me to work on it. However, I've not lost interest, so if the opportunity strikes, I will do my best.
-- Robert Laird (written 2/1/97)