Mail Archives: djgpp/1997/04/18/13:27:41
Dominique DOT Biesmans AT ping DOT be (Dominique Biesmans) wrote:
> I'm sorry guys, but it's virtually impossible to use a Windows SDK in
>a DOS environment. In theory it can be done of course. You would need
>to program a software layer that is capable of loading & executing
>windows executable formats. Mainly vxd's & DLL's but you'll also need
>to emulate some (or a lot?) of the windows kernel functionality
>because DirectX uses windows calls to allocate resources, etc...
>Basicly, you would need a Windows95 subsystem running on top of DOS.
>But good luck, once you have finished that, you aren't far away from a
>Freewin95! :-)
In a last defence of my original intent to use OEM-shipped DirectX
drivers, let me at least state how *I* would have designed DirectX.
Then maybe any residual misclarity might be cleared up. I would have
designed it that the Drivers were as simple as possible: that they
contained functions much like blit(), stretch_sprite() etc. in
Allegro. This made the most sense. Then, the DirectX .dll's, MADE BY
MICROSOFT, would contain the object-code for the actual DirectX COM
protocol. So, when you create DirectX objects, manipulate them, this
is done by Windows DLLs which of course will by the satanic nature of
windows calls gaschmillions of other Windows-specific functions. You
are right then, we cannot emulate DirectX. But what I was proposing
was totally different. Without restructuring Allegro at all, just have
it so that the equivalent of "blit()" in the OEM-shipped DirectX
driver be called by Allegro's blit() and function, and so on. Of
course, all the functions aren't going to match, but oh well. So I'm
talking about scrapping the Windows SDK and everything else that
Windows does that noone worth the air they breathe gives a rats ass
about, and just stealing the DirectX drivers. I cannot honestly see
Microsoft leaving it up to the OEM to write a bunch of COM-protocol
code which may as well be done universally by DirectX libs Microsoft
can control. I pictured the OEM-shipped drivers being quite simple,
allowing the DirectX libs SHIPPED BY MICROSOFT a unilateral interface
to graphics cards, etc... I'm NOT SUGGESTING and NEVER WAS SUGGESTING
we bother with whatever Microsoft DirectX SDK is out there; the idea
is more or less hijack the drivers that the OEM is now required to
ship. And I still maintain that this can be done, since it makes most
sense in terms of compatability and control for Microsoft to have
these OEM-shipped drivers as simple and straightforward as possible.
Adding Win95 API calls is going to be a much easier approach, of
course, but it's also likely to be slower, and then Allegro can't take
advantage of hardware-accelerated cards from plain old unadulterated
DOS. Which is ok, as I pointed out in another post, since anybody who
shells out moula for a hipper-than-hip acclerated video card probably
has Win95 coming out thier ears. Oh well. Nevermind how awesome it
would be for linux users to be able to play games utilizing DirectX
acceleration, nevermind how much better it would be to take advantage
of DirectX drivers without having to pay homage to Microsofts
particular views on how exactly we should design our games' internal
object components, or have to shell out for a DirectX SDK.
Sorry, this isn't really aimed at you Dominique, I'm just defending my
original position, which I still see as being doable. Before we decide
we should look into what an OEM-shipped driver is really all about.
Before then, we can't really decide if it's better to do a "DirectX
port of Allegro", or just modify Allegro to take advantage of
OEM-shipped DirectX drivers.
Am I getting through?
- Calvin -
- Raw text -