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. 🙂

PaGoDump & PaGoRestore v9.0.4 are out

Microolap Technologies is happy to announce that new version of GUI utilities for backing up and restoring a PostgreSQL database provides full PostgreSQL v9.0.4 support. Support for 8.4.8, 8.3.15 and 8.2.21 versions added as well.

You’re welcome to download the latest release from our website at:
http://microolap.com/products/database/pagodump/download/

Full changelog:
[+] v8.2.21 dump & restore libraries added (pg_dump-8.2.21.dll, pg_restore-8.2.21.dll)
[+] v8.3.15 dump & restore libraries added (pg_dump-8.3.15.dll, pg_restore-8.3.15.dll)
[+] v8.4.8 dump & restore libraries added (pg_dump-8.4.8.dll, pg_restore-8.4.8.dll)
[+] v9.0.4 dump & restore libraries (pg_dump-9.0.4.dll, pg_restore-9.0.4.dll)
[+] v9.0.4 client libraries added
[*] Error logging improved
[*] Speed up parallel restore when the archive contains many large objects
[-] “Cannot use custom restore library, always ‘pg_restore.dll’ used” bug fixed
[-] Fix parallel restore to handle comments on POST_DATA items correctly
[-] Fix restore to cope with long lines (over 1KB) in TOC files

Please don’t hesitate to ask any questions or report bugs with our Support Ticketing system available at http://www.microolap.com/support/

Windows path in libpq connection control functions

I already wrote a post about using Windows paths in SQL statements. But today I was playing with SSL connections to PostgreSQL from MicroOLAP Database Designer for PostgreSQL and found one interesting thing:

warning Windows user! Replace your usual slashes (backslashes, actually) with the slashes like this one: ‘/’, in the file system path parameters passed to libpq database connection control functions, e.g. PQconnectdbParams, PQconnectdb, PQconnectStartParams etc.!

WRONG:

PQconnectdb(“dbname=’carsales’ host=’localhost’ port=5434 user=’sslguy’ password=” sslmode=’require’ sslcert=’C:\MySSL\postgresql.crt’ sslkey=’C:\MySSL\postgresql.key'”);

RIGHT:

PQconnectdb(“dbname=’carsales’ host=’localhost’ port=5434 user=’sslguy’ password=” sslmode=’require’ sslcert=’C:/MySSL/postgresql.crt’ sslkey=’C:/MySSL/postgresql.key'”);

PaGoDump & PaGoRestore v9.0.0 are out

Microolap Technologies is happy to announce that new version of GUI utilities for backing up and restoring a PostgreSQL database provides full PostgreSQL 9.x support.

You’re welcome to download the latest release from our website at:
http://microolap.com/products/database/pagodump/download/

PaGoDump changelog:
[!] Support for PostgreSQL 9.x introduced
[+] Allow to dump comments attached to columns of composite types
[+] Make “Verbose Messages” option output the client and server versions in text output mode
[*] Make “Drop Database” option also remove large objects
[-] Fix to properly dump large objects when standard_conforming_strings is enabled

PaGoRestore changelog:
[!] Support for PostgreSQL 9.x introduced
[*] Make “Clean Objects” option also remove large objects
[*] Now emits large-object data in hex format when generating script output

Please don’t hesitate to ask any questions or report bugs with our Support Ticketing system available at
http://www.microolap.com/support/

Opening URL under Wine

note This article available in Russian.

Imagine the following situation. Our product can detect if it is running under WineHQ already. And, indeed, our product has many places from which we must open URL’s:

  • information about the product,
  • checking for updates,
  • online help,
  • technical support page
  • and so on.

Trying to call ShellExecute head-on, passing the URL as parameter, and … Nothing happens!

The thing is that Wine, honestly emulating everything, wants to start a web browser not installed in the system, but installed under the Wine. There are no any browsers installed yet. Therefore, nothing happens.

Of course, you can install the browser, but why not open the required documents in their native system applications? This raises the question of interaction of the Wine and the operating system.

There are a number of commands available in Wine.

We are interested in winebrowser command, which opens the URL in the native operating system application. And taking into account that URL can refer to the file, we have really serious mechanism in our hands.

winebrowser httр://www.winehq.org

winebrowser ftp://ftp.winehq.org

winebrowser irc://irc.freenode.net/#winehq

winebrowser file://c:\\windows\\win.ini

On a KDE system the first two might open in Konqueror, the third in Konversation, and the last in KWrite.

As a result, applying the function GetWineAvail (), described earlier, our code might look like this:

//Delphi Code

procedure OpenUrl(url: string);
var
  S: string;
begin
  if GetWineAvail() then 
    S := 'winebrowser ' + url
  else
    S := url;
  ShellExecute(0, 'open', PChar(S), nil, nil, SW_SHOW);
end;

...
  OpenURL('mailto:support@microolap.com?Subject=PgMDD:%20Support');
  OpenURL('httр://microolap.com/products/database/postgresql-designer/');
...

or like this:

//C Code
void OpenUrl(char * url);
{
    char s[255];
    if (GetWineAvail())
    {
        strcpy(s, "winebrowser ");
        strcat(s, url);
    }
    else
    {
        strcpy(s, url);
    }
    
    ShellExecute(NULL"open", s, NULLNULL, SW_SHOW);
}

...
  OpenURL("mailto:support@microolap.com?Subject=PgMDD:%20Support");
  OpenURL("httр://microolap.com/products/database/postgresql-designer/");
...

Building PostgreSQL 8.0.x using MinGW under Win… Magician wanted

Compiling the fresh PostgreSQL releases is not a problem under Windows using MinGW as you probably know.

One of my clients asked me to build pg_dump\pg_restore if it’s possible of course. Yes, I know that 8.0.x and 8.1.x branches are not supported anymore. At least officially. I was just curious.

Well, I spent a day making compiler happy. I built the client library libpq.dll, but dump and restore utilities are beyond my power.

The last words were:

pg_backup_archiver.o:pg_backup_archiver.c:(.text+0x43a): undefined reference to `__’
collect2: ld returned 1 exit status
make: *** [pg_dump] Error 1

Possibly my changes caused this. Since I’m not so familiar with GCC universe I’m still confused about it. Gurus’ advices appreciated.

And the last but not least. Is there any chance that MinGW compatibility patches for 8.0.x and 8.1.x branches will be committed officially?

Regards

PS Kids don’t do drugs!

Dialog Windows Trick

Wow. I worked with Windows a lot of time. But today I discovered amazing thing. To copy dialog window content just press Ctrl +C.

Imagine Notepad asks you about closing unsaved document:
notepad

Abra… Hmm… cadabra… Whatever 🙂 The result is:

—————————
Notepad
—————————
The text in the Untitled file has changed.

Do you want to save the changes?
—————————
Yes No Cancel
—————————

Fraking magic! 🙂 Take care people!

PS This trick is for standard dialog windows only (MessageBoxXXX stuff).