FiveTech Support Forums

We're seeing a reproducible regression in DEFINE MAIL / MAPISendMail() attachment delivery between FWH 26.03 and the current 26.08 build. Same machine, same Outlook profile, same Exchange Online mailbox, same recipient, same file — only the linked FWH library version changes.

Code (unchanged across all tests): harbour LOCAL oMail, lSent

DEFINE MAIL oMail ; SUBJECT cSubj ; TEXT cText ; FILES cSndFile, cSndFile ; FROM USER ; TO MailTo, MailTo

SEND MAIL oMail

lSent := ( oMail:nRetCode == 0 ) // returns 0 (success) in every version tested

Symptom: MAPISendMail() returns SUCCESS_SUCCESS (0) in all versions — the send appears to succeed locally, and Outlook's own Sent Items shows it as sent. But on the recipient side (Outlook, both Windows and Mac clients, mailbox hosted on Exchange Online), the attachment shows as not downloaded, with a "try again later" prompt that never resolves on retry. No attachment ever becomes available to the recipient.

Versions tested (same source, same test, only FWDIR changed):

┌─────────────────────────────────────────┬────────────────────────────────────────────────────┐ │ FWH version │ Result │ ├─────────────────────────────────────────┼────────────────────────────────────────────────────┤ │ FWH 25.12 (fwh642512) │ Works — attachment delivers and opens normally │ ├─────────────────────────────────────────┼────────────────────────────────────────────────────┤ │ FWH 26.03 (fwh642603) │ Works — attachment delivers and opens normally │ ├─────────────────────────────────────────┼────────────────────────────────────────────────────┤ │ FWH 26.08 (current, freshly downloaded) │ Fails — attachment stuck undeliverable, every time │ └─────────────────────────────────────────┴────────────────────────────────────────────────────┘

What we've ruled out on our end before posting: we diffed mail.ch, tmail.prg, and mapi.c line-by-line between 26.03 and 26.08 — the only changes in mapi.c are the new MapiFillAddressIfEmpty() recipient-address fallback and some GetProcAddress cast cleanups; nothing touches MapiFileDesc/lpszPathName/lpszFileName. We also extracted the compiled mapi.obj from both fivehc64.lib versions directly and confirmed the binary matches that source diff — so whatever changed isn't in the mail-handling source itself. We also confirmed our own application code and the exact TO/FILES call are identical across both builds.

Given the mail-specific source is unchanged, is there anything elsewhere in the 26.09 build (a linked dependency, manifest, or process-wide initialization change) that could affect how Simple MAPI attachments are staged/delivered through Exchange Online — even though MAPISendMail() itself reports success? Happy to provide a Process Monitor trace comparing both builds if that would help narrow it down.

Dear Tim,

Short answer: nothing I can find in the 26.03→26.08/26.09 delta plausibly explains this — and your source-level diligence is correct. Details:
Mail stack is functionally unchanged
tmail.prg and mail.ch have zero diff since 26.03. The only semantic change in mapi.c is MapiFillAddressIfEmpty() (26.07, commit 29a55fab7), which is a no-op for your TO MailTo, MailTo form (address is already non-empty). GetProcAddress casts, static keyword order, and an xhbcompat.h include (no-op on Harbour builds) are the rest. Your mapi.obj binary comparison matches.
Non-mail candidates I checked — all weak
Candidate Verdict
fwunicode.c hbcdp_to_wincdp() now skips OEM codepages (26.06) Not on this path — mapi.c passes raw hb_parvc() pointers, no FWH codepage conversion
Dark mode expanded to TWindow (2026-08-19) Only if app calls FW_SetDarkMode(.T.)
files.c share-mode/_sopen changes None — only warning cleanups / SHA256 define
Process CWD / lChDir in TMail:Activate() Unchanged since 2018
Manifest / comctl32 v6 Lives in the app's .rc, not the FWH libs — same EXE resource either way
xHarbour compat layer (hb_parvc shims) Only if you link xHarbour variants — you're on FiveHC64 (Harbour+MSVC64), so no-op
FIVEWIN.CH static decls moved / TRY-CATCH map Preprocessor only, doesn't touch DEFINE MAIL
Nothing in 26.09 initializes a process-wide hook, MAPI wrapper, or file-staging path that could alter MapiFileDesc delivery.
What the symptom actually implies
MAPISendMail()==0 + Sent Items shows sent + recipient sees an undownloadable attachment means the message was submitted with bad attachment content/metadata, not that FWH "failed to attach." Since FWH only passes lpszPathName (a pointer into your Harbour string) and lets Outlook/mapi32 read the file, the realistic failure modes are:

1. Outlook read different bytes / partial file at send time (lock, OneDrive placeholder, cloud-attachment path), or
2. Something post-submission — but that can't correlate with FWDIR unless the submitted bytes differ.
   Critical bisect you can do without ProcMon: open the sent message in Sent Items on the sender side in each version and check the attachment there (size, openable?).
3. Broken in Sent Items too → client-side staging confirmed → ProcMon will show it
4. Fine in Sent Items, broken only for recipient → EXO modern-attachment/cloud-upload issue; then compare whether 26.03 submitted a binary attachment vs 26.08 a OneDrive/cloud one (paperclip vs cloud icon in Sent Items)
   Yes — send the ProcMon trace, with these filters
   Process is <yourapp>.exe OR OUTLOOK.EXE OR SearchIndexer.exe
   Operation is CreateFile, ReadFile, CloseFile
   Path contains <attachment filename>
   What to look for:
5. Sharing violation / ACCESS DENIED on the attach file
6. Short reads (EndOfFile vs requested length)
7. Different path in 26.08 (temp staging, OneDrive ~ placeholder, \\?\ long path)
8. Whether Outlook even opens the file (if it never does, the dialog/silent-send path diverged)
   Also worth one cheap experiment: drop FROM USER (that's what sets MAPI_DIALOG via param 7) and retest 26.08 — if silent vs UI send changes the result, we've narrowed to Outlook's compose path rather than the FWH binary at all.

Hola,

La semana pasada tuve que migrar mi envio de email MAPI a OLE porque el MAPI llevaba dias dando problemas. En mi caso yo lo asocio con un update de Windows que entre otros me dejó esa perla, pero no la única. MAPI tiene por lo menos 25 años y me parece a mi que Windows no lo tiene presente debidamente al hacer actualizaciones. Con outlook local se puede usar OLE. Hay otros casos donde debo seguir con MAPI porque usan Thunderbird y llegados los problemas veré que hago.

Resumiendo: Segun a mi me parece Windows no quiere que sigamos usando MAPI. Hay que buscar alternativas. En estos casos probar un ejecutable de hace unos meses puede ser solucion para salir de dudas

Salu2

Antonio,

Please know, after my client notified me of this problem, and I duplicated it, I I spent many hours on this evaluating from every perspective. I've used Claude and we have looked at all possibilities. Consider this:

1). The problem arises even if there is no attachment connected. If the attachment is included, it is able to be opened in the "sent mail" and read perfectly.
2). The exact same file is used as an attachment. The exact same email addresses are used. The .exe is built with the exact same files. The only difference is FWH 26.03 which works and 26.09 which results in an error from the server.
3). You mention fwuhicode.c. I have never implemented unicode. All of my code is ANSI. Could that be causing a problem ?

By process of elimination, because EVERYTHING is the exact same except building with the libs in FWH 26.03 works perfectly, and FWH 26.09 fails, then all other factors can be eliminated and we have to see what element of of 26.09 is different from 26.03. It could be some other function in another file that is called by 26.09's process ... but the FWH version is the ONLY variable.

My concern is that multiple AI tools are interacting with these files, but not necessarily each other ... and testing is done with very small sample code. In this case, I'm talking about a highly integrated, real world application, and ultimately that is the goal for all projects using FWH. I have used Claude extensively to review, compare, and test any possible issues in my code, and tested all the other factors.

One final note. The error messages are being sent to a Microsoft Exchange Server account. It is support@masterlinksoftware.com. If anyone wants to test it, they can use FWH code to send an email to that account via MAPI. In our case we are using Outlook as the MAPI client. We ruled out the exchange server because code sent straight from Outlook directly, that matches the code from our FWH application, is received with no problem at all.

Tim

Dear Tim,

The only difference is FWH 26.03 which works and 26.09 which results in an error from the server.

Ok, then we just need to compare the changes between them :idea:

Many thanks for your great feedback

Dear Tim,

There is just a small change in mapi.c

If you grab mapi.c from FWH 26.03 and use it with FWH 26.09, it should solve the problem.

We are building some tests here to double check if the problem comes from such little change.

Antonio,

Thank you. That was it.

I compiled mapi.c from FWH 26.03 (source\winapi\mapi.c, built with -DFLAT) and linked it ahead of fivehc64.lib, with everything else on the current FWH build. MAPI email with attachments now works again. The recipient (Exchange Online, both Windows and Mac Outlook) receives the attachment normally. With the current mapi.c, the message shows as sent in Outlook, but the recipient's attachment never downloads ("try again later").

Comparing the two files, the only change that affects behavior is the new MapiFillAddressIfEmpty(), which is applied to the originator, each recipient in MAPISENDMAIL, and MAPIADDRESS. Our call is:

DEFINE MAIL oMail ;
SUBJECT cSubj ;
TEXT cText ;
FILES cSndFile, cAttachName ;
FROM USER ;
TO MailTo
SEND MAIL oMail

TO MailTo with a single argument builds { { cEmail } }, so the new code copies the plain address into lpszAddress with no SMTP: prefix. I suspect that when Outlook receives a raw, unresolved lpszAddress, it creates a one-off recipient and changes how it encodes the message (possibly TNEF/winmail.dat), which would explain why the recipient can't open the attachment. Before this change, lpszAddress was NULL and Outlook resolved the name itself, which worked correctly.

Suggestion: only fill lpszAddress for non-Outlook clients, or add the "SMTP:" prefix when copying the name into the address. At minimum, please make it optional, since it breaks attachments with Outlook/Exchange.

For now I'll keep linking the 26.03 mapi.c. I'm happy to test a corrected version.

Tim

Dear Tim,

You reported the bug with TO MailTo (one parameter) — that's the SINGLE form where FWH fills the address automatically, and the fix handles it.

I'm asking if you also tested TO MailTo, MailTo (two parameters — explicit address) with attachments on your Exchange setup.

If the dual form also breaks attachments, I need to extend the SMTP: prefix fix to explicit addresses too; if it works fine, the current fix is enough.

I did test that before submitting this post and it also failed

I saw that suggested in another post.

Hi Tim,

Confirming from the current sources: the SMTP: fix only fires when lpszAddress is empty - MapiFillAddressIfEmpty() returns early when an explicit address is present (and when the name has no '@', or when SetMapiAddrFill(.F.) was called). So your dual-form result matches the code exactly: TO MailTo, MailTo passes the second element through verbatim, a bare user@domain stays untyped, and Outlook takes the same one-off-recipient path that breaks the attachment on Exchange Online.

Two workarounds for the dual form today:

1) Type the address yourself: TO cName, "SMTP:" + cEmail (the same works for CC/BCC and FROM - any explicit address may carry the SMTP: prefix). 2) SetMapiAddrFill(.F.) restores the pre-26.07 behavior, but only for the auto-fill path - it does not change explicit addresses.

For the library, the natural extension is to normalize explicit addresses too: when lpszAddress is present but has no SMTP: prefix and contains '@', prepend "SMTP:". That covers the dual form the same way the fill covers the single form, with SetMapiAddrFill(.F.) remaining the escape hatch.

Thanks for the precise bisect - knowing the dual form fails too is exactly what was needed.

Please note: I downloaded the latest builds for my FWH license for both FWH and FWH64. These are supposed to be the latest releases. Consider that with the following observation.

▎ Follow-up on the MAPI attachment issue. ▎ ▎ Confirmed: typing the recipient address explicitly fixes it with the stock libraries, with no 26.03 mapi.c needed. ▎ ▎ DEFINE MAIL oMail ; ▎ SUBJECT cSubj ; ▎ TEXT cText ; ▎ FILES cSndFile, cAttachName ; ▎ FROM USER ; ▎ TO MailTo, "SMTP:" + MailTo ▎ ▎ The recipient on Exchange Online (Windows and Mac Outlook) now receives the attachment normally. TO MailTo alone and TO MailTo, MailTo both fail: in both cases a bare user@domain ends up in lpszAddress. ▎ ▎ One note on the reply above: it describes a MapiFillAddressIfEmpty() that adds the SMTP: prefix, plus a SetMapiAddrFill() switch. Neither is in my installed FWH 26.09. source\winapi\mapi.c still copies the bare name into lpszAddress, and FiveHC64.lib (Sep 12) contains no "SMTP:" string and no SETMAPIADDRFILL symbol. If that code exists, it hasn't shipped yet. Until it does, anyone sending attachments through Outlook/Exchange with TO cEmail will hit this problem. ▎ ▎ A related point for anyone sending without an attachment: FILES "", "" still builds { { "", "" } }, and MAPISendMail returns 11 (MAPI_E_ATTACHMENT_NOT_FOUND). Setting oMail:aFiles := {} when there's no file avoids that. It might be worth having TMail skip empty file entries. ▎ ▎ Tim

Hi Tim, you're absolutely right, and thank you for checking your package. The SMTP: auto-fill (and the SetMapiAddrFill switch) landed in the library after the September 12 package, so your installed 26.09 doesn't have it - our earlier reply described the current sources, not what you have installed. Today's package (September 25) does include it, along with an xHarbour-related mapi.c fix worth having if you build with xHarbour. And thanks for the FILES "", "" finding - an empty attachment string triggering MAPI_E_ATTACHMENT_NOT_FOUND is exactly the detail we needed; clearing aFiles is the right workaround today.