Comment by RyJones
2 days ago
Probably. A lot of people really loved MSMAIL; not so much Exchange.
I have more long, boring stories about projects there, but that’s for another day
2 days ago
Probably. A lot of people really loved MSMAIL; not so much Exchange.
I have more long, boring stories about projects there, but that’s for another day
And sometimes they loved MSMAIL for the weirdest reasons...
MSMAIL was designed for Win3.x. Apps didn't have multiple threads. The MSMAIL client app that everyone used would create the email to be sent and store the email file on the system.
An invisible app, the Mail Pump, would check for email to be sent and received during idle time (N.B. Other apps could create/send emails via APIs, so you couldn't have the email processing logic in only the MSMAIL client app).
So the user could hit the Send button and the email would be moved to the Outbox to be sent. The mail pump wouldn't get a chance to process the outgoing email for a few seconds, so during that small window, if the user decided that they had been too quick to reply, they could retract that outgoing email. Career-limited move averted.
Exchange used a client-server architecture for email. Email client would save the email in the outbox and the server would notice the email almost instantly and send it on its way before the user blinked in most cases.
A few users complained that Exchange, in essence, was too fast. They couldn't retract a misguided email reply, even if they had reflexes as quick as the Flash.
I re-wrote MSPAGER for Exchange. Hoo boy what a hack that was! A VB3 app running as a service, essentially. I don't know if you remember romeo and juliet; those were PCs pulled from pc-recycle by a co-worker to serve install images.
My neurons are firing on "MSPAGER" in recognition, but romeo and juliet draw blanks - which is a good thing. Because if you know the infrastructure, but you weren't involved in the implementation, then there's typically a bad reason why you know how the sausage is getting made. :)
Also, I survived Bedlam DL3 (but I didn't get the t-shirt).
see https://techcommunity.microsoft.com/blog/exchange/me-too/610... for the explanation for the Bedlam reference.
1 reply →
> A few users complained that Exchange, in essence, was too fast.
That is something that's actually pretty common and called "benevolent deception" - it has been discussed on HN some years past, too [1].
[1] https://news.ycombinator.com/item?id=16289380
I wouldn't call either Mail Pump's slow email processing a "benevolent deception", nor Exchange's quick email processing an attempt to be perceived as a fast email server.
In MSMail/Exchange Client/Outlook, the presence of email in the Outbox folder signifies that an email is to be sent, but that the code for sending the email hasn't processed that particular email.
MSMail being slower than Exchange to send email is a leaky abstraction due to software architecture.
Win3.x doesn't support multithreaded apps, using a cooperative multitasking system. Any app doing real work would prevent the user from accessing the system since no user interface events would be processed.
So the Mail Pump would check to see if the system was idle. There are no public or secret/private Windows APIs (despite all the MS detractors) for code to determine if the system is idle - you, the developer, had to fall back to using heuristics. These heuristics aren't fast - you didn't want to declare that the system was idle only to discover the user was in the middle of an operation. So the Mail Pump had to be patient. That meant the email could sit in the outbox for more than a second.
Exchange Server was a server process running on a separate box. When an email client notified the Exchange Server that an email was to be sent (whether via RPC or SMTP command), Exchange Server didn't have to wait in case it would block the user's interaction with the computer. Exchange Server could process the email almost immediately.
But there was a happy resolution to the conundrum - no, the Exchange Server didn't add a delay.
Some architect/program manager had added a "delay before sending/processing" property to the list of supported properties of an email message. The Exchange/Win95/Capone email client didn't use/set this property. But a developer could write an email extension, allow the user to specify a default delay for each outgoing email and the extension could get notified when an email was sent and set this "delay before sending/processing" property, such that Exchange Server would wait at least the specified delay time before processing the email message.
The user who desired an extended delay before their sent email was processed by the Exchange Server, could install this client extension, and specify a desired delay interval.
Outlook eventually added support for this property a few years later.
I notice that Gmail has added support for a delay to enable the user to undo sent emails.
Ha, maybe my old memory is rusty, but I feel like I recognize this name and you had an old blog with some quotable Raymond Chen -- one bit I remember was something like
"How do you write code so that it compiles differently from the IDE vs the command line?" to which the answer was "If you do this your colleagues will burn you in effigy when they try to debug against the local build and it works fine"
Yup, that’s me.