OK, I bit the bullet and pulled out TortoiseCVS and MS VC++ 6 and changed
the server code to solve my dilemma.

I can confirm that the source code with the R1_5_2 tag certainly does use
the following order for determining the root directory (location of
firebird.conf and other files):

1) FIREBIRD environment variable.
2) Registry value:
HKLM\Software\Firebird Project\Firebird Server\Instances\DefaultInstance
3) The exe parent directory.

I can also confirm that the Firebird 1.5 windows installer runs instreg.exe
when installing superserver which creates the registry value used in step 2
above. That's where my problem was and I can't simply delete that registry
value as FB might be installed after my application is installed.

SOLUTION
========
I modified the server source code to add a new command line parameter "-m
<InstanceName>" to tell the server what its instance name is instead of the
hard-coded "DefaultInstance". The specified instance name is used when
looking up the registry value for the root directory.

I can now set the server command line like this:
fbserver.exe -m MyInstance

And add the following registry string value:
HKLM\Software\Firebird Project\Firebird Server\Instances\MyInstance

With value "C:\Program Files\My Application\"

All tested and it works as expected. I now have two firebird server services
installed in different directories with different Windows service names (I
use a custom service installer for my instance), and each uses a different
root directory to read different firebird.conf and aliases.conf files,
configured with a different RemoteServicePort and RemotePipeName, and my
instance with CreateInternalWindow = 0.

Thanks to all who assisted with this problem.

Regards,

Jarrod Hollingworth
Backslash
jarrod@...