Little tips on writing portable plugins (and rant on MSVC)

Having written a smallish plugin for a cross-platform database program FileMaker using a template that included projects for Xcode and VC, here’s a few tips on what you should think about when you start writing a plugin that should work on multiple platforms.

1. Work on the Windows version first. If you’re at home on non-Windows platforms, MSVC will surprise you in numerous ways with its oddities and weird, outdated support for C.
2. Write as much code in C for portability.
3. Write in C90. Microsoft Visual Studio will barf a lot at you otherwise.
4. If you disregarded #3 and wrote the code in C99 (for example, you declared variables during the function body instead of on the top of the function), you’ll have to switch to C++ to avoid changes to your code.
5. Don’t write smart code. For example, MSVC barfs at the following:

   typedef struct _IVRect
   {
     int x, y, w, h;
   } IVRect;
   
   IVRect r = { .x = 5, .y = 6, .w = 7, .h = 8 };
   
   // but the following is ok. just don't change the order of
   // struct members. if you do -- woe upon you:
   IVRect s = { 5, 6, 7, 8 };
   

   and it especially barfs at the following:

   // given int IVRectSurfaceSum(const int rectCount, Rect * r):
   int surface = IVRectSurface(2, (IVRect[]) 
     {
       { .x = 5, .y = 6, .w = 7, .h = 8 },
       { .x = 1, .y = 2, .w = 3, .h = 4 } 
     });
   

6. Use as many open source libraries available for majority of your platforms.
7. …but always check what MSVC can swallow and what your target app uses. I have used version of libxml2 that depended on the newer zlib1.dll than has shipped with FileMaker. The only solution I found is — replacing FileMaker’s zlib1.dll. That’s nasty.
8. Always write a small test C program that uses the same functions as your plugin. Port that to every platform first. On Windows, I couldn’t get stdout from my plugin once it ran under FileMaker. If I could’ve, I would’ve saved about a day of frustration why signing with xmlsec didn’t work. (xmlsec’s debug output wasn’t displayed anywhere, either).
9. Get used to #ifdef _MSC_VER. Get really, really, really used to it.

Since I’m not sure you could figure that out… I have a very low opinion about Visual C++. I did hear it produces nice, fast code. But that doesn’t change the fact that it’s terrible to use with low coverage of modern C. Actually, scratch that: nonexistent coverage of modern C.

I mean, it’s so nasty that I’m wondering if I should have built a helper static library (or a DLL) which contained the C code using MinGW, and then used this helper library in the plugin itself.

Visual C++ was — for me — slow, had little conformance with modern standards, and every time I had to copypaste something somewhere using GUI, a little part of me died. A slightly larger part if I had to overwrite something else, as was the case with zlib1.dll.

I don’t know. Sure, it’s mostly familiarity-with-other-IDEs speaking out of me. Sure, tons and tons of people prefer and absolutely love Visual C++. Good for them.

But, I apparently love modern language features far, far more. So, if you are like me, and if you are forced to build something with MSVC (an example might be — the SDK you’re writing the plugin with chose to use C++, hence the ABI is locked into MSVC), you really, really, really should constantly doublecheck if MSVC will eat up what you try to serve to it.

Because if you used to work with Windows, and if you are nowadays mostly targeting another platform (or at least another compiler), and if you think you’re writing portable code — you may be in for a nasty surprise.

Especially if you use third-party libraries!

–
via blog.vucica.net