Paul Beach's Blog

Wednesday, December 20, 2017

Windows 10 is well known for encouraging a love/hate relationship
with its users. From the beginning Microsoft implemented a policy of
uninstalling users' software without their consent during installation
or update of Windows 10. Many articles on the net discuss this, for example however, until now, Firebird seemed to be unaffected.

Not any more. Windows 10 Creators Edition (Build 1709), released in
September 2017 seems to have added Firebird to its hit list of dangerous
applications. This problem was first reported here.
Because the report mentioned Firebird 1.5 it seemed unfortunate but,
hey, Firebird 1.5 has been out of support for eight years. It was first
released back in 2003 in the heyday of Windows XP and fourteen years is a
long time in the software industry. But not only had Firebird been
uninstalled, it was impossible to re-install it. This was likely to
affect one of our clients so we spent a long time trying to work around
that problem.

Since then we have heard reports from other clients whose customers
use Firebird 2.5. After updating Windows 10 to build 1709 Firebird was
nowhere to be seen. We have also heard that Windows 10 Enterprise is
affected so this is not isolated to the so-called Creators edition. And,
at the time of writing we haven't had any feedback about the status of
Firebird 3.0.

Luckily, Windows 10 does not block installation of any version of
Firebird from V2.0 onwards. But having to re-install is still very
annoying, and who knows when Microsoft might decide to change the rules
on that?
We spent a long time with our client trying to work out how to
re-install Firebird 1.5. Manually setting the configuration using the
Properties | Compatibility page and choosing an older version of Windows
didn't work. However, running the compatibility troubleshooter did,
even though the same setting were being chosen.

Unfortunately, there is so much clicking required that no ordinary
user could be relied upon to achieve the desired goal. And trying to
talk someone through that over the phone or by email would be extremely
frustrating for all involved.

Rebuilding the installer with a newer, Windows 10 aware version of
InnoSetup didn't work. But weirdly, a rapidly hacked version using an
InterBase template for InstallShield did. Hmmm. And hacking an InnoSetup
based installer together with the Firebird 1.5 zip package also worked.
So what was going on there?

What criteria does Windows 10 use to decide which programs to ban
from installation? There is a known bug in the cpl applet that ships
with Firebird 1.5 that can crash Windows Explorer so we tried building
an installer without that applet. But no, that wasn't it either.

Finally our client had a brainwave. What happens if
Firebird-1.5.6.5026-0-Win32.exe was renamed to, say, setup.exe? Well,
what do you know? It works. So simple that we really wanted to kick
ourselves for not thinking of it first. And as for the poor Brazilian
guy in the forum above, I hope he is sitting down when/if he finds out
the solution. It is enough to make anyone want to run screaming into the
woods.

Thursday, March 10, 2016

With the release of Firebird 3 RC2 it is time to concentrate properly on the port of Firebird on MacOSX, Firebird 3 was buildable but we don't have a proper installer, ICU is no longer directly included and there
are a number of other bits and pieces that need to be addressed.

The last time I built Firebird 3 was before I upgraded to El Capitan. I did the upgrade to address some issues with the Firebird installer.

Lets just say when I started ny first build I wasn't expecting too many problems....

When we build Firebird on OSX we arbitrarily point to the ICU location (build_environment/firebird/lib), after copying over the files from the initial ICU build, the Firebird build then finds the ICU libraries dynamically (when needed) because DYLD_LIBRARY_PATH is sey to point to the location via prefix.darwin (make.platform).

While the ICU libraries are being built we set the final actual framework install names and locations of the ICU libraries (using -install_name) and they then placed in the appropriate directory of the framework
when the installer is packaged and built.

Every time I tried to build Firebird it would fall over when trying to build msg.fdb with ISQL.
The error was:
"Could not find acceptable ICU library"
which seemed very strange as I know it was placed exactly where it should be and where DYLD_LIBRARY_PATH should be picking it up.

Setting DYLD_LIBRARY_PATH in my default terminal worked successfully, checking DYLD_PRINT_ENV seeemed to show the path being set etc., after much head scratching I eventually put the following line of code into unicode_util.cpp at the function:
UnicodeUtil::ConversionICU& UnicodeUtil::getConversionICU()

printf("DYLD_LIBRARY_PATH=%s\n", getenv("DYLD_LIBRARY_PATH"));

When I next ran the build, this is what was returned..

DYLD_LIBRARY_PATH=(null)

Something very strange was definitely going on. Some further research eventually turned up this thread on the
PostgreSQL forums

http://www.postgresql.org/message-id/561E73AB.8060800@gmx.net

"Apparently the behaviour is that DYLD_LIBRARY_PATH is prevented from being inherited into any system binaries. E.g. a shell. But specifying it inside a shell script will allow it to be inherited to children of
that shell, unless the child is a protected process in turn."

My reaction was the same as Tom Lane's but expressed in much stronger terms.

Wednesday, October 7, 2015

Background: The current Firebird automatic installer on El Capitan is no longer working, its format has been
finally deprecated. The installer is currently undergoing a complete re-write to comply with the Flat Package Format. Until this work is completed, you can manually install Firebird using the following method.

If you are upgrading from a previous version use:
./preupgrade
and then
./postupgrade

SuperServer

Download FirebirdSS-2.5.4-26856-x86_64.pkg.zip
Then follow the same steps as above, and ignore any errror messages that reference
a, /Resources/doc/doc: No such file or directory
b, chmod /Library/StartupItems/Firebird/Firebird: No such file or directory
c, /Library/LaunchDemons/org.firebird.gds.plist: service is already loaded.

Monday, June 1, 2015

When a transaction, marked as TRA_autocommit performs any of following actions, it is marked also as TRA_perform_autocommit

insert

update

delete

select with lock

post event

The TRA_perform_autocommit flag is checked when

the engine receives input message

the engine sends an output message

the engine starts to execute a request

the engine finishes executing a DDL request

When the TRA_perform_autocommit flag is detected, the engine runs on-commit triggers (not for DDL, that looks like a bug) and performs commit retaining. A new transaction will have TRA_autocommit flag set and TRA_perform_autocommit not set.

But if you want Firebird SuperServer to start automatically on reboot you could use the following org.firebird.gds.plist file in /Library/LaunchDaemons

and the command

launchctl load org.firebird.gds.plist

should now start Firebird immediately and also on reboot.

Update 2nd July 2015

I got an email from David Nock suggesting that the following plist would do a better job at managing SuperServer on Yosemite (10.10). Some brief tests suggest that he is right. I will be committing the following for 2.5.5, but I am documenting this here in case anybody wants to use this.

Wednesday, November 12, 2014

Nbackup performs two logical groups of operations - locking and unlocking a database and backup and restoring it. It doesn't make much sense duplicating locking and unlocking in using services, because that functionality is present remotely in via the SQL language interface (ALTER DATABASE). But backup and restore must be run on localhost and the only way to access them is via nbackup utility.

Therefore expanding the services API to support this functionalty is useful.