There's nothing to advertise there. DDraw API was fully retired with D3D8, and developers are all using D3D12 (and maybe D3D11 a little still) nowadays.
DDraw's abilities have become pretty much encompassed by D3D since 8. Yeah the techniques might have changed (color-keyed blits -> alpha-test) but the effects are still achievable in D3D8 and upwards as-is. You can still lock surfaces and fill them by the CPU just as before. I don't know if they still promote palletized formats in the cap bits (would be interesting to know), but all that can be emulated in pixel shaders.

I'm guessing that's what DDraw does now in modern Windows. I doubt drivers have any explicit support for it anymore. It's all translated to a newer D3D DDI by MS, so it just works.

wbahnassi wrote on 2023-12-10, 13:13:

There's nothing to advertise there. DDraw API was fully retired with D3D8, and developers are all using D3D12 (and maybe D3D11 a little still) nowadays.
DDraw's abilities have become pretty much encompassed by D3D since 8. Yeah the techniques might have changed (color-keyed blits -> alpha-test) but the effects are still achievable in D3D8 and upwards as-is. You can still lock surfaces and fill them by the CPU just as before. I don't know if they still promote palletized formats in the cap bits (would be interesting to know), but all that can be emulated in pixel shaders.

I'm guessing that's what DDraw does now in modern Windows. I doubt drivers have any explicit support for it anymore. It's all translated to a newer D3D DDI by MS, so it just works.

Palettized formats are still supported in the cap bits.

At least I thought they translate to a newer DDI for DDRAW but I have no way to believe this. On a XDDM driver, the DDRAW is loaded first followed by the Direct3d through it.

On WDDM, at least the older D3Ds (2-7) are translated to the D3D9 DDI; but I can't verify the same for DDraw. I checked on Process Explorer, it doesn't say what's being loaded for a pure DDraw app, while for pre-d3d8 apps it loads the D3D9 ddi.

Did a bit of reading on this a while back and the general consensus is that DirectDraw Emulation since Windows 8.1 is now handled directly by the GPU drivers, Microsoft has no control over if drivers support the emulation or not or even what parts of DDraw get emulated. AMD, nVidia and Intel all apparently do it differently and latest nVidia drivers are partially broken with DDraw 2 - 7 and have minor graphical issues with DDraw 8 emulation, not even sure they document it but I would be looking to them to get the information you want rather than Microsoft.

Some of the workarounds for the missing DDraw emulation and broken parts are actually impressive especially the work GoG does in getting older DDraw programs to work with modern Windows and GPU drivers.

it'd be like advertising MMX on new CPUs.

leileilol wrote on 2023-12-11, 01:08:

it'd be like advertising MMX on new CPUs.

I think advertising L2 on die cache would be more amusing.

DirectDraw was being used by DirectShow at some point, too, I remember.

I'd find it odd that HW vendors have to write anything for it in WDDM2. Anyways, the API is so simple it can easily be reimplemented as a replacement DLL that you can throw next to any DDraw game and have it evade any reliance on MS/IHV support.

As more or less already mentioned above, DirectDraw has been deprecated after DirectX 7, and it's still there because Windows continues to support many legacy APIs.
But there's absolutely no reason to advertise it, because they do not recommend developing new software for DirectDraw, as newer, more capable, and actively supported APIs are available.

Jo22 wrote on 2023-12-11, 02:58:

DirectDraw was being used by DirectShow at some point, too, I remember.

Yes, you could have these so-called 'overlay surfaces', which could be used to show hardware-decoded frames directly on the desktop.
Later they moved to Direct3D 9 surfaces, which could then be composited by the GPU.

Scali wrote on 2023-12-11, 10:33:

As more or less already mentioned above, DirectDraw has been deprecated after DirectX 7, and it's still there because Windows continues to support many legacy APIs.
But there's absolutely no reason to advertise it, because they do not recommend developing new software for DirectDraw, as newer, more capable, and actively supported APIs are available.

leileilol wrote on 2023-12-11, 01:08:

it'd be like advertising MMX on new CPUs.

Not in the manner to stick a DirectX logo on the box.

If I read a x86 programming guide, there's a possibility I will get on to read a guide for programming on MMX, SSE, AVX, ... And that will still work usually correctly (unless there's some "Max Payne on Ryzen 3000 bad programming" situation).

If I read a MS guide to do the same for a DirectDraw driver, I will end with a non-working driver, the available DirectDraw driver architecture guide is for XDDM only.

Most users won't bother about DirectDraw anyway in 2023, but it would've been good to know what would need to be done now.

BEEN_Nath_58 wrote on 2023-12-11, 14:24:

If I read a MS guide to do the same for a DirectDraw driver, I will end with a non-working driver, the available DirectDraw driver architecture guide is for XDDM only.

Most users won't bother about DirectDraw anyway in 2023, but it would've been good to know what would need to be done now.

Microsoft explains quite clearly that DirectDraw drivers are for legacy drivers only... The chapter on DirectDraw is under the Legacy branch for the Windows 2000 display driver model:
https://learn.microsoft.com/en-us/windows-har … play/directdraw

Scali wrote on 2023-12-11, 14:48:

BEEN_Nath_58 wrote on 2023-12-11, 14:24:

If I read a MS guide to do the same for a DirectDraw driver, I will end with a non-working driver, the available DirectDraw driver architecture guide is for XDDM only.

Most users won't bother about DirectDraw anyway in 2023, but it would've been good to know what would need to be done now.

Microsoft explains quite clearly that DirectDraw drivers are for legacy drivers only... The chapter on DirectDraw is under the Legacy branch for the Windows 2000 display driver model:
https://learn.microsoft.com/en-us/windows-har … play/directdraw

Windows 2000 driver model won't work anyways. Secondly, the site mentions "Windows 2000 and later" but not "how later?" Other users here have speculated that it is converted to a D3D DDI, but I couldn't verify it anyway like I did for old D3D.

Also the WDDM guide doesn't even mention Vulkan.

BEEN_Nath_58 wrote on 2023-12-11, 15:24:

Also the WDDM guide doesn't even mention Vulkan.

Why would it? Vulkan is not a Microsoft component nor was it ever part of DirectX.

BEEN_Nath_58 wrote on 2023-12-11, 15:24:

Windows 2000 driver model won't work anyways. Secondly, the site mentions "Windows 2000 and later" but not "how later?"

They actually do say that on the page that explains the XDDM model: https://learn.microsoft.com/en-us/windows-har … el-design-guide

The Windows 2000 Display Driver Model (XDDM) is the legacy display/graphics driver architecture that was used for Windows 2000 through Windows Vista and Windows 7.

The thing here is that there's some overlap between XDDM and WDDM. Vista was the first OS to support WDDM, but because most older hardware wouldn't have WDDM drivers, they continued to support XDDM as well in Vista and 7 (although as said before, it's not recommended for writing new software, it's only for legacy suport).

They also specifically say that with Windows 8 this backward compatibility was dropped:

XDDM and VGA drivers will not compile or run on Windows 8 and later versions.

leileilol wrote on 2023-12-11, 15:29:

Why would it? Vulkan is not a Microsoft component nor was it ever part of DirectX.

Yup, the same goes for OpenGL.
Windows provides some basic support for OpenGL, the so-called ICD (Installable Client Driver) interface, and some wgl*() support-APIs to integrate OpenGL with OS-specific stuff.
But the actual implementation of the OpenGL API is not done through WDDM. That is a vendor-specific solution. The ICD interface just helps you to access this driver interface. The rest basically bypasses Windows and the driver model, and has the driver talk directly with the application through a vendor-specific OpenGL runtime implementation.

I believe Vulkan is implemented in roughly the same way.

leileilol wrote on 2023-12-11, 15:29:

BEEN_Nath_58 wrote on 2023-12-11, 15:24:

Also the WDDM guide doesn't even mention Vulkan.

Why would it? Vulkan is not a Microsoft component nor was it ever part of DirectX.

Neither is OpenGL:
https://learn.microsoft.com/en-us/windows-har … el-architecture

Scali wrote on 2023-12-11, 15:30:

They also specifically say that with Windows 8 this backward compatibility was dropped:

XDDM and VGA drivers will not compile or run on Windows 8 and later versions.

If I am not wrong, XDDM doesn't allow DWM to run. Probably it was one of the features that needed Direct3D ddi based drivers; an old Intel laptop I had, had this issue.

It's clear the XPDM driver started with the DirectDraw route, forwarded to Direct3d with COM probably (because it wasn't a primary necessity back then). Now it starts at Direct3d, so how it goes back to DirectDraw doing is the missing link (and hence what I meant by the lack of it's advertisement).

Scali wrote on 2023-12-11, 15:33:

Yup, the same goes for OpenGL. Windows provides some basic support for OpenGL, the so-called ICD (Installable Client Driver) int […]
Show full quote

leileilol wrote on 2023-12-11, 15:29:

Why would it? Vulkan is not a Microsoft component nor was it ever part of DirectX.

Yup, the same goes for OpenGL.
Windows provides some basic support for OpenGL, the so-called ICD (Installable Client Driver) interface, and some wgl*() support-APIs to integrate OpenGL with OS-specific stuff.
But the actual implementation of the OpenGL API is not done through WDDM. That is a vendor-specific solution. The ICD interface just helps you to access this driver interface. The rest basically bypasses Windows and the driver model, and has the driver talk directly with the application through a vendor-specific OpenGL runtime implementation.

I believe Vulkan is implemented in roughly the same way.

Not surprising since Vulkan and OpenGL are handled by the same group of people, its bound to share many similarities with its older sibling. Probably a hot take but Vulkan in many respects is still very much OpenGL even if it doesn't share a code base, I personally consider it just a more advanced version of OpenGL.

Fun fact Vulkan was originally referred to as glNext

Microsoft depreciated DirectDraw and added its interfaces to Direct3D, starting with 8, so there was no need to develop and advertise the DirectDraw API itself any further (not sure if those interfaces still exist in later Direct3D though).

If you're a developer writing your software for modern windows, there's no need to use DirectDraw.

As stated by others, the ddraw.dll simply exists for compatibility with older software.

eddman wrote on 2023-12-27, 11:19:

If you're a developer writing your software for modern windows, there's no need to use DirectDraw.

As stated by others, the ddraw.dll simply exists for compatibility with older software.

Right. I was more interested on how it works now, given that the skeleton has changed in WDDM