Quote
What DirectX API could Delphi directly consume w/o a wrapper layer,
before?
You're missing the point.
There have been major philosophical shifts in the history of DirectX,
which could just as well happen with .Net, and more or less mean you'll
have to start rewriting the compiler, RTL and all other components
from scratch or near enough. And MS can make such changes without
any impact to C# users f.i, only by reworking the innards to fix flaws
or accomodate new concepts. Similarly, whole chunks of the .Net standard
library can (and *will*) be dropped without warning.
But unlike for the Win32 API, MS doesn't bother to ensure stability
of say, DirectX 5, when DirectX 7 came out, and thus, new release
introduce behaviour changes in what are officially "freeze" old release,
that should behave now as they behaved in their days.
With classic APIs, MS never dropped DLLs, and kept maintaining them
in stable state. With "new" APIs, ala DirectX, MS doesn't hesitate
to drop things, and thus force you to update a lot of code just to
get minor upgrades or feature additions (f.i. shaders in the 3D world,
in OpenGL you can integrate them to your old code where you want,
but in DirectX, if your app is based on DirectX7 that won't be possible
until you port it to DirectX9, which can mean a lot of code rewrite
with zero benefits).
Besides, do you know a DirectX API that .Net can consume w/o a wrapper layer?
DirectX 9 doesn't qualify, it is a wrapper around the COM interfaces (unlike
what MS claims, you can access the underlying COM interfaces through
undocumented means), and neither will announced DX10 plans allow it unless
a major philosophical shift occurs in .net 2.0.
One could also point that in Delphi 8, the support for pro APIs like OpenGL,
is quite... erm... let's say you'd better not need anything beyond a spinning
triangle.
Eric
