The tale of how PostgresDAC became the cross-platform component suite

As some probably know Delphi XE2 now have compilers for Win32, Win64, Mac and iOS. And as you probably guessed, we were inundated with questions from our customers about support for this zoo in our DACs.

Frankly speaking this situation is perfectly described in Joel’s Spolsky “Fire and motion”. We thought: “This just can’t be done in a sane time!”

However “you never know what you can do till you try” and “the devil is not so black as he is painted”. So we decided to port PostgresDAC first. The main reason was the using of libpq.dll client library, which may be built for a huge amount of target platforms.

Thus we don’t need to worry about low-level network routines and may pay the whole of the attention to the middle layer, have no idea how to name it.

As for Win64 platform, then were no problems at all. We’ve prepared x64 deploy libraries and we done with it. There were no dangerous places in our source code were address arithmetics may produce unsuspected behavior. This simplicity is understandable. We just stayed within one Windows platform in general.

Then it was Mac’s turn. When we started I have never seen MacOS before… That was scary move. Especially for my self-esteem. :)

We crossed the fingers, chose OS X as the target platform and the fun began. I knew our code was Windows-centric, but I was so far from the real understanding of the scope of the tragedy. :)

Here is the seven deadly sins for the cross-platform library written in Delphi:

1. Using of Windows unit is prohibited. The only things you have are System ans SysUtils. Deal with it!

2. Using of VCL units (Controls, StdVCL, ExtCtrls etc) is prohibited. There’s no VCL on Mac, FireMonkey only.

3. Using of forms is prohibited. So no custom dialogs, message boxes etc. You have no idea under which platform library is built. Well, this is so true for console application too. That’s why we’ve removed annoying trial screen.

4. Ignoring compiler directives is stupid. Remember the first sin? Yeah, sometimes you’ll need low-level OS’s functionality. If so, do it smart:

{$IFDEF MSWINDOWS}
Winapi.Windows,
{$ENDIF}
{$IFDEF MACOS}
Macapi.CoreServices,
{$ENDIF}
{$IFDEF POSIX}
Posix.SysTypes, Posix.Stdio, Posix.Stdlib
{$ENDIF}

5. Using of messages, window procedures, handles, file mappings and other Win-shit is prohibited. That’s why our TPSQLMonitor is still useless for Mac. We need to rewrite it from scratch. And we ready for it.

6. Use correct type naming, e.g. LongWord instead of DWORD.

7. Use proper functions or implement them for all platforms. No place for ZeroMemory, CopyMemory, GetTickCount on Mac etc.

You know, when I wrote the number of seven I didn’t think that I’m so damn write! Of course in your case there may be dozen of others incompatibilities. That was just a joke. :)

Nerd.

Tagged with: , , , , ,
Posted in PostgresDAC, PostgreSQL
4 comments on “The tale of how PostgresDAC became the cross-platform component suite
  1. Clemens Eisserer says:

    Windows and OSX only is unfourtunatly not what most consider Cross-Platform :(

  2. neznayka says:

    Здравствуйте.
    Не могли бы Вы набрасать пример PSQLDatabase1.Execute с созданием парамеров? То AV получаю при создании параметра, то “Нельзя это выполнить с открытм датасетом.”
    Спасибо.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Archives
Map of wandering
Follow

Get every new post delivered to your Inbox.

Join 80 other followers

%d bloggers like this: