OK, let me qualify this by starting off and saying that it's technically possible to write a wrapper library for SDL and OpenGL for about 75-90% of DirectX (that's basically what the WineX guys do, near as I can tell). Here are the problems with doing so:
1) I seriously doubt that anyone can get all of the (current) DirectX API without running into IP suits. Granted, that hasn't really stopped the WINE crowd or the WineX guys, but eventually even they'll run into a patent violation suit...
2) Performance. The Linux and BSD kernels are pretty radically different from the WinXX/NT kernels. If you'll recall, MS had some issues with DX over v3 on the NT4 platform, which has a few of the same user/kernel separation that your run-of-the-mill *nix kernel has. (Flame warriors, forgive me for comparing the two. Yes, I realize that the NT kernel moved display drivers into kernelspace, killing stability, and that various Unices have some form or another of Direct Rendering. I'm talking about the whole enchilada here, not just display output...) I would imagine that writing a libdirectx would be no easier/harder than the construction of libwine.so, with many of the same hurdles, plus one or two. DX has a shorter "upgrade" delay than, say, the MFC or ATL libraries, it's quite an ugly moving target... Second off, how likely do you think it is that every inch of the DX API is documented? That, too, may change slowly with the court ruling, but I'm willing to bet that more than a few functions out of the API are not documented...
3) You'd also have to implement at least portions of COM/DCOM. It's difficult to say how much of it is already usable from WINE (I'm sure that they've gotten into some of the reimplementation details by now), but there would have to be considerably more developed to get excellent performance out of it.
So, I figure your best odds on getting a DirectX port over to *nix is to pick a major distro, and see if the WineX guys are hiring...
The competitors that are building faster using IDE's probably either:
a) only target one platform
or
b) have already created the above mentioned abstraction layers, consolidated on a single MAKE utility, and tweaked their IDEs and environment to utilize both properly.
In all honesty, the guy screaming about abstracting data/view, client/server, OS/homebrewed wrappers makes a lot more sense from where I'm sitting (with my virtually nonexistant experience as a paid coder) than the people suggesting that the entire development team stop and learn from 1 to 3 new languages and/or libraries to the proficiency necessary for the type of app they're working on.
I seem to recall that the OEM's description of their licensing agreement with MS went something like this:
If Vendor X sells a PC with a home use version of Windows preloaded, they would pay the discounted licensing rate to MS, which is IIRC ~$100.
If Vendor X sells a PC with any other OS installed, Vendor X pays MS the approximately $200 that a regular, non-OEM, Windows license would cost off-the-shelf at Wal-Mart or Best Buy.
If Vendor X has an additional $200 of cost for PCs without Windows, how do they sell the machine at an equivalent margin? Mark the price for the PC without Windows up by $200, of course!
Now, which is more sellable, a $500 Windows PC, or the same $500 PC with another OS installed being sold at $400 (cost of HW, minus ~$100 windows OEM license) + $200 (penalty for not selling Windows preinstalled on the OEM Bulk Licensing rate) + cost of licensing another OS?
As an FYI, I used to work in a small screwdriver shop that was pretty vigilant about the handling of their licenses and pretty solvent in their desire not to lose their status as a Microsoft Certified Solutions Provider. And yes, when I asked about it being more expensive to sell a machine with no OS, they mentioned something about a licensing agreement.
BTW, I apologise already for not posting any links to back up those statements, just something I remember from a while back...
Slashdot Mirror
OK, let me qualify this by starting off and saying that it's technically possible to write a wrapper library for SDL and OpenGL for about 75-90% of DirectX (that's basically what the WineX guys do, near as I can tell). Here are the problems with doing so:
1) I seriously doubt that anyone can get all of the (current) DirectX API without running into IP suits. Granted, that hasn't really stopped the WINE crowd or the WineX guys, but eventually even they'll run into a patent violation suit...
2) Performance. The Linux and BSD kernels are pretty radically different from the WinXX/NT kernels. If you'll recall, MS had some issues with DX over v3 on the NT4 platform, which has a few of the same user/kernel separation that your run-of-the-mill *nix kernel has. (Flame warriors, forgive me for comparing the two. Yes, I realize that the NT kernel moved display drivers into kernelspace, killing stability, and that various Unices have some form or another of Direct Rendering. I'm talking about the whole enchilada here, not just display output...) I would imagine that writing a libdirectx would be no easier/harder than the construction of libwine.so, with many of the same hurdles, plus one or two. DX has a shorter "upgrade" delay than, say, the MFC or ATL libraries, it's quite an ugly moving target... Second off, how likely do you think it is that every inch of the DX API is documented? That, too, may change slowly with the court ruling, but I'm willing to bet that more than a few functions out of the API are not documented...
3) You'd also have to implement at least portions of COM/DCOM. It's difficult to say how much of it is already usable from WINE (I'm sure that they've gotten into some of the reimplementation details by now), but there would have to be considerably more developed to get excellent performance out of it.
So, I figure your best odds on getting a DirectX port over to *nix is to pick a major distro, and see if the WineX guys are hiring...
Not intended to be flammable, just my $.02...
The competitors that are building faster using IDE's probably either:
a) only target one platform
or
b) have already created the above mentioned abstraction layers, consolidated on a single MAKE utility, and tweaked their IDEs and environment to utilize both properly.
In all honesty, the guy screaming about abstracting data/view, client/server, OS/homebrewed wrappers makes a lot more sense from where I'm sitting (with my virtually nonexistant experience as a paid coder) than the people suggesting that the entire development team stop and learn from 1 to 3 new languages and/or libraries to the proficiency necessary for the type of app they're working on.
I seem to recall that the OEM's description of their licensing agreement with MS went something like this:
If Vendor X sells a PC with a home use version of Windows preloaded, they would pay the discounted licensing rate to MS, which is IIRC ~$100.
If Vendor X sells a PC with any other OS installed, Vendor X pays MS the approximately $200 that a regular, non-OEM, Windows license would cost off-the-shelf at Wal-Mart or Best Buy.
If Vendor X has an additional $200 of cost for PCs without Windows, how do they sell the machine at an equivalent margin? Mark the price for the PC without Windows up by $200, of course!
Now, which is more sellable, a $500 Windows PC, or the same $500 PC with another OS installed being sold at $400 (cost of HW, minus ~$100 windows OEM license) + $200 (penalty for not selling Windows preinstalled on the OEM Bulk Licensing rate) + cost of licensing another OS?
As an FYI, I used to work in a small screwdriver shop that was pretty vigilant about the handling of their licenses and pretty solvent in their desire not to lose their status as a Microsoft Certified Solutions Provider. And yes, when I asked about it being more expensive to sell a machine with no OS, they mentioned something about a licensing agreement.
BTW, I apologise already for not posting any links to back up those statements, just something I remember from a while back...