Anthony Tuininga wrote:
> What I meant is that shadow functions will have to be defined=20
> which call the real functions. These will look very similar=20
> to the ones defined in the Oracle include files. If/when such=20
> things change those changes will have to be reflected. Note=20
> that this technique assumes that Oracle __never__ changes or=20
> removes their API for a particular function. They only add=20
> functions. I'm not convinced this will always be the case=20
> which makes this technique somewhat of a risk -- fairly low=20
> but still a risk.
The same risk already exists with every Oracle application,
even when explicitely linked with a specific Oracle oci.lib,
even the current cx_Oracle:
When loading a DLL, Windows checks every function by its name,
but has no way to check for the number or type of the arguments
(unless they use the C++ call convention, which encodes the=20
types in the function name).
Actually, the "shadow functions" we are about to write are
very close to the code embedded when linking with oci.lib.
As long as there is a file named oci.dll, Oracle will have to=20
ensure compatibility between releases.
--=20
Amaury Forgeot d'Arc
Ubix Development
www.ubitrade.com
|
