One of the difficulties with linking objects is the handling of exceptions. The 64 bit exception model is table based, in contrast to the stack based 32 bit model.
I don’t think that the exception tables are written correctly for code linked in objects. If exceptions are raised then this can lead to abnormal process termination. Process just disappears. Poof!
One common way that this happens is floating point exceptions that are by default unmasked by the Delphi RTL. I have found it necessary to mask them when calling into any linked object code to avoid exceptions being raised.
And compiling with cl can be a bit of a game. It’s stack checking options need to be disabled. And there are a few other key switches that help. And then there’s the forward declaration trick to help the one pass compiler cope with C objects that are expected to be linked in a separate step.
Anyway, it can be quite a challenge at times, but I’ve yet to find a plain self contained C library that has defeated me!
The first public showing of that demo did not include main thread protection. It originates from a session at the the 1995 Borland Developers Conference where Ray Konopka showed the below code from Bob Ainsbury.
Calls to MAPISendMail should work without a problem.
For all other MAPI method and function calls to work in a MAPI application, the bitness (32 or 64) of the MAPI application must be the same as the bitness of the MAPI subsystem on the computer that the application is targeted to run on.
In general, a 32-bit MAPI application must not run on a 64-bit platform (64-bit Outlook on 64-bit Windows) without first being rebuilt as a 64-bit application.
If you ever wonder why you get no (or incomplete) RTTI from a control that you inherited from a DevExpress one – then look into cxVer.inc where it has the following lines:
+Martin Wienold was wondering (and so was I at first) why he could not properly resolve a form from the DI container that inherited from TdxRibbonForm despite writing a public method with [Inject] attribute on it but it was never called.
Warning: If you are using DevExpress or any other source code that does this (changing the $RTTI directive) and build these sources together with your application (in contrast to using precompiled dcus or even packages) on a version <XE6 then you might suffer from this issue: [WayBack] #79943: {$ RTTI} flag scope which causes RTTI to disappear even from units that did not have the $RTTI in them.
The Project Options in the Delphi IDE has a few option (like the Search Path) each with an ellipsis button (the one on the right having only three dots ... in the image below) to pop-up a dialog.
Delphi Component/Tool vendors have to support a truckload of Delphi and C++ Builder versions which can be a pain: they have to work around problems in Delphi and C++ Builder versions that have long been abandoned by Borland/CodeGear/Embarcadero/Idera/…
This means that sometimes the Delphi Component/Tool vendors have to work around stuff in a way normal applications vendors would never do.
Recently I learned that sometimes this can be a painful thing: keeping DFM files in binary state.
I’m not kidding about either the DFM file format nor about supporting old versions:
That’s why TeeChart still has most DFM files stored as binary files (again the ‘most’ word).
For version control and searching this is a pain, so normal application developers (the ones not using Delphi XE5 Update 1 for Android work) should run convert.exe with the -t (target=text) switch on DFM binary files.
Especially when using Delphi 2007 on Windows x64 system (8.x, 7, Vista, 2012 Server, 2008 Server, …), the Delphi specific .Targets files used by msbuild are simply installed to the wrong location.
The Wiert Corner - irregular stream of stuff 
