The hardest/largest step would probably be to get it into this century, with the latest version of DirectX 9 (2005, Windows XP / Xbox 360 era). The step from 9 to 11 is also quite big, but a lot of APIs have stayed compatible.
The hardest/largest step would probably be to get it into this century, with the latest version of DirectX 9 (2005, Windows XP / Xbox 360 era). The step from 9 to 11 is also quite big, but a lot of APIs have stayed compatible.
Now DXVK does not support DX7, but a quick search found dgVoodoo2, which does emulate DX7 under DX11. Maybe that or a similar library can be used as a stepping stone.
Regarding porting legacy apps to 64bit, the most problems i've seen were concerning old libraries (on Windows). That usually requires replacing old libraries with new a version, and fixing includes. I've seen only a handful of bugs arising purely from 32bit vs 64bit differences.
So maybe it could work to port the codebase to DX9 but no further really.
Having no knowledge of the code, I imagine if you have a functioning graphics layer, most of the work would happen on the underlying physics models and high level drawing/scene APIs, not directly interfacing with DX.
What I'm sure you were getting at is a proper conversion to DX9 making use of the shader based pipeline.
That said, looking at the code I don't think porting to proper shader based DirectX would be terribly difficult for anybody experienced in setting up directx in a shader based pipeline. Nothing looks too fancy.
Of course it could be made more complicated by actually making use of shaders to improve over the fixed function design, but that is not required for an initial port.