How to handle odbc/registry

[Bill Medland]

The builtin odbc32.dll basically simply proxies the underlying unix ODBC 
provider (e.g. unixODBC or iODBC).

I have just discovered that somewhere in the compilation/link phase under 
Windows some standard ODBC function calls somehow actually get translated 
into direct registry calls.  For example the SQLGGetInstalledDrivers call 
actually gets translated into an OpenKey and EnumerateKey on the 
HKLM/Software/ODBC/ODBCINST.INI/ODBC Drivers

So should we have code within the registry code that recognises access to the 
ODBC tree when odbc32 is builtin and redirects it to the corresponding calls 
to the unix ODBC manager?