Direct3D 10 is very different from DirectX 9. The latter was designed with modern GPUs in mind and so is based around an entirely programmable pipeline. DirectX 9 is predominantly a fixed-function API with various places where you can insert shader programs into the pipeline. This means that DirectX 10 is easier to support because there's less provided by the API.
Supporting D3D 9 is akin to supporting OpenGL 2. You need to expose most of the programmable interfaces but also have a load of fixed-function stuff work, typically (on modern hardware) by providing shader programs that do the same thing. Supporting D3D10 is more similar to supporting OpenGL 3, where most of the complexity is in moving data to and from the GPU and compiling shader programs.
With Gallium, there are two aspects to supporting these APIs. The first is the compiler turning programs from a source language (HLSL, GLSL) into TGIR. The second is the state tracker, which handles API-specific state. The former part is about as complex for D3D 9 and 10, as they have similar shader language support. The latter is a lot simpler for 10, as it is a much less stateful API.
The ones he insists don't exist because the Guardian article is all lies?
If you're going to issue a denial, you should at least get your story internally consistent.
A small reactor could power a U.S. Navy warship, and eliminate the need for other fuel sources that pose logistical challenges
A navy ship, what about a cruise liner? With cheap energy, you could process the deuterium from sea water for fuel, grow food in artificially lit enclosures below decks and have a self-sustaining artificial ecosystem that could spend years between trips to port.
Well, thank you for clarifying that you need to be entertained during your briefing of safety procedures that exist to save your life.
I've flown a depressing amount over the last couple of years. United actually does have pretty entertaining security briefing (although they're less funny the fifth time you've seen them in a week), but they insist on showing you a couple of minutes of adverts after telling you to pay attention for the important security briefing, but before showing the security briefing. If you want people to pay attention, then ban airlines from showing ads before the briefing, because after being advertised to for a couple of minutes, you can bet that I've unplugged my noise-cancelling headphones from the jack and am reading a book until they put the screen back under my control again...
#include <stdio.h>
int x;
int main(void)
{
struct x { void *a, *b; }foo;
printf("%ld\n", sizeof(x));
}
Try compiling this as both C and C++. It's completely valid in both languages, but the output will be different in each.
Look at K&R, ANSI, C90, C14, etc. Many of these standards were never fully implemented in any particular compiler. K&R was supported in early gcc releases but deprecated and then dumped in gcc-2.95->early 3.x releases. Many of the later releases break features of the earlier ones piecemeal despite the original standard never having had a 'stable' release that could properly generate code for all applications (While rare, there are still many corner cases, even in perfectly 'valid' C programs that thanks to developer error, or mistake implementation of standard features resulted in code generation bugs. Some of which weren't fixed before a standard was deprecated or altered for compatibility with C++ for instance in a manner that broke a formerly 'conforming' application.)
There is no such thing as C14. C90 isn't really a thing either (it's C89, with a few errata fixed). C89 was the first ISO standard C. K&R wasn't a standard, it was just the documentation of a specific implementation. To claim that it wasn't implemented is nonsense - it was implemented, it was never standardised.
After C89, both versions of the C standard (C99 and C11) have been backwards compatible. They are not always backwards compatible with vendor extensions. C99, for example, added an inline keyword (which was bad because inline was in the space of identifiers reserved for the user) that had different semantics to the GNU extension. Code compiled by gcc with -std=c89 would work with -std=c99, but code compiled as -std=gnu89 would break. Both gcc and clang have a -fgnu89-inline flag to work around this limitation. Every valid C99 program is also a valid C11 program.
Were they sufficiently technically incompetent that they didn't discover an attack that the Russians have been using, or were they sufficiently inept in a more general intelligence sense that they didn't realise that leaving US and allied machines vulnerable might be a problem?
Truth has always been found to promote the best interests of mankind... - Percy Bysshe Shelley