Armitage Shanks wrote on 2025-03-30, 14:26:

DirectDraw and Direct3D 7 are very much supported in hardware, today.

Thanks for the answer, I can safely quote your reply if and when asked (instead of wasting my time explaining it again 😉 ).

As you mentioned that DD7 and its subset D3D7 is still well supported, what feature of earlier, DD6 and D3D6 and earlier, would you say has been phased out. If I didn't learn wrong, older DD and D3D has features stacked on top of another in a same set of libraries, so do you mean that specifically many of the older ones have been removed? I can only remember W-Buffer and overlay, there is more?

BEEN_Nath_58 wrote on 2025-03-30, 19:05:

Armitage Shanks wrote on 2025-03-30, 14:26:

DirectDraw and Direct3D 7 are very much supported in hardware, today.

Thanks for the answer, I can safely quote your reply if and when asked (instead of wasting my time explaining it again 😉 ).

As you mentioned that DD7 and its subset D3D7 is still well supported, what feature of earlier, DD6 and D3D6 and earlier, would you say has been phased out. If I didn't learn wrong, older DD and D3D has features stacked on top of another in a same set of libraries, so do you mean that specifically many of the older ones have been removed? I can only remember W-Buffer and overlay, there is more?

G'day,

You're most welcome and you certainly can.

Microsoft hold backward compatibility to a very high regard and in order for graphics card manufacturer's drivers to receive WHQL certification, they have to meet standards that include backward compatibility. I know for a fact that DD6/D3D6 is supported in Intel/AMD/NVIDIA drivers, to a degree that is very much the same that DD7/D3D7 is supported -- enough features for most games to run. I can't speak for earlier versions, but I would imagine, so long as the game/application is able to run on Windows 10/11 and is selective about what DirectDraw features it uses by checking the video driver capabilities, it would run. I have just completed work on a .dll which allows software developers to use DirectDraw/D3D 7 in a Windows 10/11 application. Why would I do this? As I mentioned earlier, DirectDraw on today's hardware is incredibly fast -- especially when directly accessing surface memory with Intel MMX/SSE/AVX instructions. It can be used with a very small amount of setup code, making it a handy tool for hardware-accelerated 2D graphics and for people who are learning computer graphics programming. My library sets up DirectDraw/Direct3D 7 and is ready to draw with just one line of code. If somebody is happy with basic 2D graphics, they could write a really fun and visually appealing game with DirectDraw today and without much effort. You could easily replace all of the missing DirectDraw features and add some which were never supported.

Your comment makes me curious. I'm going to try writing a DirectDraw 1.0 demo and see what happens. I am almost completely sure it will run, so long as I use DirectDraw 1.0 features supported by the GPU driver.

You didn't learn wrong. DirectDraw is a COM (Component Object Interface) interface and subsequent versions of the interface after the original are more or less stacked on top of each other. ddraw.dll in Windows today supports version 7 and all versions before it. Some features have indeed been removed, some without choice -- because of Windows DWM (Desktop Window Manager). DWM is responsible for composing the Windows UI and displaying it on the screen. It doesn't support Overlays and Windows in general won't support VGA/ModeX resolutions or 8-bit color. On my GPU, DirectDraw Clipper, Palettes and the left/right/up/down mirroring of drawing operations are only supported in software. Blitting, Flipping, ColorKeys (a fully transparent color when displaying an image) and scaling (done with either bilinear or bicubic interpolation which looks fantastic) are supported in the hardware and are a crazy level of fast. In fullscreen-exclusive mode, gamma ramps are supported in hardware but (at least on my GPU) DirectDraw will only run with vertical synchronization on, even if you force it off in the driver. If you're interested to see what features your GPU supports, search for the DirectX SDK. It contains an app called Caps Viewer which shows you. It's not 100% accurate though because it shows that you have a negative amount of video memory or over 1Tb of it 🤣.

Armitage Shanks wrote on 2025-04-01, 03:18:

I can't speak for earlier versions, but I would imagine, so long as the game/application is able to run on Windows 10/11 and is selective about what DirectDraw features it uses by checking the video driver capabilities, it would run.

Actually DDraw has mostly been fine on Nvidia and probably AMD too. It is just Intel right now, with its new set of drivers, that fails to have many features done correctly.
Alpha channel is a common issue nowadays for almost any card

Armitage Shanks wrote on 2025-04-01, 03:18:

I have just completed work on a .dll which allows software developers to use DirectDraw/D3D 7 in a Windows 10/11 application. Why would I do this? As I mentioned earlier, DirectDraw on today's hardware is incredibly fast -- especially when directly accessing surface memory with Intel MMX/SSE/AVX instructions. It can be used with a very small amount of setup code, making it a handy tool for hardware-accelerated 2D graphics and for people who are learning computer graphics programming. My library sets up DirectDraw/Direct3D 7 and is ready to draw with just one line of code. If somebody is happy with basic 2D graphics, they could write a really fun and visually appealing game with DirectDraw today and without much effort. You could easily replace all of the missing DirectDraw features and add some which were never supported.

On my GPU, DirectDraw Clipper, Palettes and the left/right/up/down mirroring of drawing operations are only supported in software. Blitting, Flipping, ColorKeys (a fully transparent color when displaying an image) and scaling (done with either bilinear or bicubic interpolation which looks fantastic) are supported in the hardware and are a crazy level of fast. In fullscreen-exclusive mode, gamma ramps are supported in hardware but (at least on my GPU) DirectDraw will only run with vertical synchronization on, even if you force it off in the driver.

Are you kind of a developer for a graphics hardware company or a company that works for DirectX, or a brand new GPU developer or a driver writer for a already developed vendor (if its not too personal) 😉?

Armitage Shanks wrote on 2025-04-01, 03:18:

Some features have indeed been removed, some without choice -- because of Windows DWM (Desktop Window Manager). DWM is responsible for composing the Windows UI and displaying it on the screen. It doesn't support Overlays and Windows in general won't support VGA/ModeX resolutions or 8-bit color.

Can you quote on why it was not possible to implement overlays the way 8 and 16bit colours are implemented on Windows 8+, through the DWM8AND16BITMITIGATION shim?

Edit: Probably you are the most qualified person to explain this, what's the significance of VGA/ModeX terminology in Windows lingo? I would automatically assume its support for 320x240x256 res which by default isn't available on modern OS, but you can enable it in the driver.

Does this resolutionmake it VGA/ModeX? The DX3 SDK states that ModeX isn't supported on NT, which answers the previous question as False.

In that scenario, what would you call this 320x240x256 resolution?

Also however https://bearwindows.zcm.com.au/vga.htm (see Part 2) talks about a (banked?) ModeX mode in Windows XP which means it returned, but was Windows ModeX always banked (like in Win9x?) and never allowed in unbanked form?

Also since you mentioned VGA, what other VGA mode other than ModeX could've been available?

BEEN_Nath_58 wrote on 2025-04-01, 08:21:

Actually DDraw has mostly been fine on Nvidia and probably AMD too. It is just Intel right now, with its new set of drivers, that fails to have many features done correctly.
Alpha channel is a common issue nowadays for almost any card

That's right. It did change a bit after Windows 7, because of DWM. In modern Windows, all rendering whether it be software or hardware, has to pass through DWM. NVIDIA supports all the "meat and potatoes" features in hardware but unfortunately Clipping is done in software using the driver. It's slow. Nothing can be done about the primary surface Clipper (what's visible on the screen) but I side-stepped the need for a backbuffer Clipper by automatically Clipping all drawing operations using AVX2-driven clipping. zero overhead.

BEEN_Nath_58 wrote on 2025-04-01, 08:21:

Are you kind of a developer for a graphics hardware company or a company that works for DirectX, or a brand-new GPU developer or a driver writer for a already developed vendor (if its not too personal) 😉?

Too personal? Not at all, ask whatever you like. I'm just a hobbyist! Over the years, Microsoft (and others) have tried offering graphics libraries for use with the C# language. The Microsoft offerings were...before the time was right, other offerings have their strengths and weaknesses but there's not a lot of choices, so I decided to write my own...which strikes a balance between power and ease of use. I think I've achieved that, but now I have to add sound and input, because it wouldn't be much good without it.

BEEN_Nath_58 wrote on 2025-04-01, 08:21:

Can you quote on why it was not possible to implement overlays the way 8 and 16bit colours are implemented on Windows 8+, through the DWM8AND16BITMITIGATION shim?

I can't speak for DWM8AND16BITMITIGATION, I've never used it. From a bare-bones developer perspective, Overlays haven't beren supported in the driver since Windows 7. That's with respect to DirectDraw doing the rendering natively.

If you have an old DirectDraw game which doesn't work correctly today, DDrawCompat offers a drop-in ddraw.dll which uses Direct3D11 to do the rendering and this includes Overlays. Again, haven't used it, so if the actual executable refuses to run on Windows 11 64-bit, I don't think it'll help. In that case, you'll need a virtual machine or retro system running Win9x, Windows 2000 *might* do it.

https://github.com/narzoul/DDrawCompat

BEEN_Nath_58 wrote on 2025-04-01, 08:21:

Edit: Probably you are the most qualified person to explain this, what's the significance of VGA/ModeX terminology in Windows li […]
Show full quote

Edit: Probably you are the most qualified person to explain this, what's the significance of VGA/ModeX terminology in Windows lingo? I would automatically assume its support for 320x240x256 res which by default isn't available on modern OS, but you can enable it in the driver.

Does this resolution make it VGA/ModeX? The DX3 SDK states that ModeX isn't supported on NT, which answers the previous question as False.

In that scenario, what would you call this 320x240x256 resolution?

Also however https://bearwindows.zcm.com.au/vga.htm (see Part 2) talks about a (banked?) ModeX mode in Windows XP which means it returned, but was Windows ModeX always banked (like in Win9x?) and never allowed in unbanked form?

Also since you mentioned VGA, what other VGA mode other than ModeX could've been available?

Mode X is a variant of VGA’s standard Mode 13h that allows for 320×240 resolution with 256 colors instead of the default 320×200. The key difference is that Mode X enables square pixels rather than the slightly stretched pixels of Mode 13h. It also utilizes planar memory, which allows for more efficient graphics manipulation compared to the simpler but more restrictive chained mode of Mode 13h.

While Mode X is commonly associated with 320×240×256, the term Mode X itself refers more to the planar memory arrangement rather than just the resolution. If a modern driver enables 320×240×256 but does not use planar memory, then it wouldn’t strictly be Mode X—it would just be a VGA-compatible resolution.

NT-based systems (including Windows 2000 and later) rely on the Windows Display Driver Model (WDDM), which does not support the low-level VGA register manipulations required for Mode X. This is why many older DOS-based games that relied on Mode X had compatibility issues on NT-based systems.

Mode X in Windows XP suggests that some form of banked VGA memory access was still possible, somehow? Historically, Windows 9x allowed direct VGA register access, meaning Mode X could be used in its unchained form. However, in Windows XP, direct VGA access was more restricted, meaning that any Mode X implementation would likely have been banked—requiring software to swap memory banks rather than accessing the full framebuffer directly. As you can imagine, this would be quite slow. I wonder what GPU was used, because they were sometimes banked in the PCI era and a) If it is PCI, how does it have an XP driver? and b) If it's AGP why on Earth does it have banked memory?

Other VGA Modes Beyond Mode X
Aside from Mode X, other VGA modes included:
- Mode 13h (320×200×256) – The standard VGA mode used in many DOS games.
- Mode Y (320×200×256, planar) – Similar to Mode X but retains the original 320×200 resolution.
- Mode Q (256×256×256) – A lesser-known mode that simplifies pixel addressing.
- Tweaked VGA Modes – Some developers used custom VGA register tweaks to achieve resolutions like 360×240 or 400×300, often referred to as "tweaked Mode X".

Fortunately, through emulation, any resolution imaginable can be faithfully displayed with the correct aspect ratio and color depth/palette. MAME is an excellent example. Arcade cabinets of the extreme yesteryear had very unconventional display modes, bizarre refresh rates (like 59.975Hz) and color palettes. MAME displays them all, just as they would appear if viewed on a genuine cabinet today.

Armitage Shanks wrote on 2025-04-20, 01:01:

I think I've achieved that, but now I have to add sound and input, because it wouldn't be much good without it.

Sound quite an ambitious project 😮

Armitage Shanks wrote on 2025-04-20, 01:01:

Overlays haven't beren supported in the driver since Windows 7. That's with respect to DirectDraw doing the rendering natively.

I think you might be a little mistaken but the last hardware I saw supporting overlays was a GTX 9*7*0 on Windows 10. I think Falcosoft here showcased that, I had a thread where someone replied.

Armitage Shanks wrote on 2025-04-20, 01:01:

If you have an old DirectDraw game which doesn't work correctly today, DDrawCompat offers a drop-in ddraw.dll which uses Direct3D11 to do the rendering and this includes Overlays

D3D11 renderer is used in dgVoodoo2. DDrawCompat uses the original DDraw API. Neither of which supports overlays yet. Currently only DxWnd supports overlays on GDI+ but the D3D9-DDraw chained implementation (for games like the GodFather) is unsuitable for my Nvidia (but works fine on old Intel). Although it can run plain overlay apps like mosquito.exe in DX SDK.

Armitage Shanks wrote on 2025-04-20, 01:01:

The key difference is that Mode X enables square pixels rather than the slightly stretched pixels of Mode 13h. It also utilizes planar memory, which allows for more efficient graphics manipulation compared to the simpler but more restrictive chained mode of Mode 13h.

However, in Windows XP, direct VGA access was more restricted, meaning that any Mode X implementation would likely have been banked—requiring software to swap memory banks rather than accessing the full framebuffer directly. As you can imagine, this would be quite slow. I wonder what GPU was used, because they were sometimes banked in the PCI era and a) If it is PCI, how does it have an XP driver? and b) If it's AGP why on Earth does it have banked memory?

So as much I understand, MODEX used planar memory in either a banker or linear framebuffer, but XP was limited only to the banked framebuffer.

I think no GPU manufacturer was ever interested in it: hence it was phased out and never heard of again. The only available driver I see is the VBEMP implementation for Windows NT, which probably allowed PCI? era GPUs to work on XP at some level. For example Quake 2 should have worked better in MODEX.DLL form (with the MODEX mode of the game) instead of running the system on VGA.DLL

G'day again, thanks for your reply.

BEEN_Nath_58 wrote on 2025-04-20, 05:31:

Sound quite an ambitious project 😮

Reasonably so, but nothing ground-breaking 😀 I started off by porting Microsoft.DirectX.DirectDraw from 32-bit .NET Framework 1.x C# to 64-bit .NET Framework 9.0.3 C++/CLI. I legit necro'd DirectDraw 7 (for developers anyway) and was surprised, if not shocked, at how fast it is on today's systems. This is especially true when directly accessing surface memory or using many-thread blitting. Sure, you can do that on Direct3D too, but there's a lot of mucking about if that's all you're interested in doing, not to mention some abstraction. I'm working on DirectSound at the moment.

BEEN_Nath_58 wrote on 2025-04-20, 05:31:

I think you might be a little mistaken but the last hardware I saw supporting overlays was a GTX 9*7*0 on Windows 10. I think Falcosoft here showcased that, I had a thread where someone replied.

I've always had an NVIDIA GPU but for some reason I had Overlays working on Windows 7 but not on Windows 8 (and beyond). When I was running Windows 8, I believe my GPU was an NVIDIA 780. It's probable that the issue was not the driver, nor Windows, but my usage of Microsoft.DirectX.DirectDraw as opposed to "native/unmanaged" DirectDraw code.

Caps Viewer incorrectly reports Overlays as supported, but all of the associated variables describing the supported caps return a value of 0, at least on NVIDIA. My current GPU is a 4090M/12Gb.

BEEN_Nath_58 wrote on 2025-04-20, 05:31:

D3D11 renderer is used in dgVoodoo2. DDrawCompat uses the original DDraw API. Neither of which supports overlays yet. Currently only DxWnd supports overlays on GDI+ but the D3D9-DDraw chained implementation (for games like the GodFather) is unsuitable for my Nvidia (but works fine on old Intel). Although it can run plain overlay apps like mosquito.exe in DX SDK.

Looking at the DDrawCompat source suggests that D3D11 shaders are used as the renderer, at least to some degree. I haven't read the whole source. Overlays are mentioned in the source, too, so I presumed they were supported but don't have anything that will run on Windows 11 to test that, unless I wrote an app with overlays. Speaking of which, I successfully wrote a very basic DirectDraw 1.0 app which just created a device, primary surface, backbuffer and drew a red square to the screen. Did so in just under 2.2µs (much, much faster than even the best monitors/displays can update themselves).

Using DirectDraw as the renderer would really restrict the level of compatibility it could provide, since so many DirectDraw caps are no longer supported in the driver and need to be "emulated" via another API like D3D.

Actually, I just this very moment came up with a potential way that you could implement Overlays using DirectDraw 7, on even the most recent build of Windows. I'm going to try it out this evening. In Windows, you can create a window that has no title bar, no borders and is completely transparent. In addition to that, you can make it "click through", meaning that mouse clicks only affect the window underneath/behind it. This was not possible on Windows earlier than XP or maybe 2000. By making this window the DirectDraw render target, you could simulate the look and feel of Overlays. If you rendered your content onto a DirectDraw surface that had, say, a violet background, and rendered it to the primary surface using a destination ColorKey with that violet color's RGB value, it should technically be transparent and would appear, for all intents and purposes, like an Overlay. You should also be able to do this with Direct2D/3D.

The one potential caveat of his approach is that using DirectDraw you wouldn't be able to display it on top of a DirectX window which has fullscreen-exclusive mode (most games D3D11 and earlier). The voice chat program Ventrilo did this, presumably(?) with hooks or by scoping out the target window's handle, instead of creating a physical window to draw the overlay on as per my example above.

With an increasing number of games moving across to Direct3D 12 "full-screen window", this is becoming less of an issue.

BEEN_Nath_58 wrote on 2025-04-20, 05:31:

So as much I understand, MODEX used planar memory in either a banker or linear framebuffer, but XP was limited only to the banked framebuffer.

I think no GPU manufacturer was ever interested in it: hence it was phased out and never heard of again. The only available driver I see is the VBEMP implementation for Windows NT, which probably allowed PCI? era GPUs to work on XP at some level. For example Quake 2 should have worked better in MODEX.DLL form (with the MODEX mode of the game) instead of running the system on VGA.DLL

ModeX used (and still uses, if you have all the right software and hardware) planar/unbanked memory access. Windows XP, however, although it still used the XDDM-style driver model of NT 4.0 and 2000, was forced to use banked VRAM access thanks to the additional layers of hardware abstraction and "security". (Ironic considering how weak and vulnerable XP turned out to be...). This meant true Mode X (with linear, unbanked access) was/is unattainable. DirectDraw emulates ModeX on XP but in doing so, forces you into banked memory access.

I will check out that link you posted, I'm curious. It's possibly a Windows 2000 PCI driver that (like some do) works on XP.

I never ran Quake 2 in software mode (I had 3D since the Riva128/GLQuake days), but I imagine if it supported 320x240 (which would look, um, chunky 😀), I think it would have been done using the OpenGL software renderer (ref_soft.dll).

In conclusion, I'm ashamed to admit that prior to finding this thread I'd never heard of this site before. Having a close look, I am delighted to see that this is right up my alley, although my collection of classic systems consists mainly of Commodore machines (I have a C64, a 128, Amiga 600 and 1200). Most of my emulation experience resides there, too., but I've been meaning to get an old Win9x setup happening so I can play my collection of old titles that won't run on Win11 64-bit, even with compatibility flags...

The community here appears to be exceptional, too, making a refreshing change to the sometimes toxic/elitist atmosphere found elsewhere.

Good day again

Armitage Shanks wrote on 2025-04-21, 09:28:

Reasonably so, but nothing ground-breaking 😀 I started off by porting Microsoft.DirectX.DirectDraw from 32-bit .NET Framework 1.x C# to 64-bit .NET Framework 9.0.3 C++/CLI. I legit necro'd DirectDraw 7 (for developers anyway) and was surprised, if not shocked, at how fast it is on today's systems. This is especially true when directly accessing surface memory or using many-thread blitting. Sure, you can do that on Direct3D too, but there's a lot of mucking about if that's all you're interested in doing, not to mention some abstraction. I'm working on DirectSound at the moment.

I would be interested in DirectSound as well. I remember certain apps refuse to run with the latest dsound.dll s but work fine on older ones, e.g., "Relics: The 2nd Birth". Certain DirectDraw features like W-buffer are no longer accelerated/emulated, would you have something for that? Interestingly my old Intel driver still support W-buffer along with the traditional Z-buffer.

Armitage Shanks wrote on 2025-04-21, 09:28:

Caps Viewer incorrectly reports Overlays as supported, but all of the associated variables describing the supported caps return a value of 0, at least on NVIDIA. My current GPU is a 4090M/12Gb.

Talking of the GeForce 900 series support for overlays, I had a chat here. Could be interesting for you: Hardware overlay support

Armitage Shanks wrote on 2025-04-21, 09:28:

Looking at the DDrawCompat source suggests that D3D11 shaders are used as the renderer, at least to some degree. I haven't read […]
Show full quote

Looking at the DDrawCompat source suggests that D3D11 shaders are used as the renderer, at least to some degree. I haven't read the whole source. Overlays are mentioned in the source, too, so I presumed they were supported but don't have anything that will run on Windows 11 to test that, unless I wrote an app with overlays. Speaking of which, I successfully wrote a very basic DirectDraw 1.0 app which just created a device, primary surface, backbuffer and drew a red square to the screen. Did so in just under 2.2µs (much, much faster than even the best monitors/displays can update themselves).

Using DirectDraw as the renderer would really restrict the level of compatibility it could provide, since so many DirectDraw caps are no longer supported in the driver and need to be "emulated" via another API like D3D.

Actually, I just this very moment came up with a potential way that you could implement Overlays using DirectDraw 7, on even the most recent build of Windows. I'm going to try it out this evening. In Windows, you can create a window that has no title bar, no borders and is completely transparent. In addition to that, you can make it "click through", meaning that mouse clicks only affect the window underneath/behind it. This was not possible on Windows earlier than XP or maybe 2000. By making this window the DirectDraw render target, you could simulate the look and feel of Overlays. If you rendered your content onto a DirectDraw surface that had, say, a violet background, and rendered it to the primary surface using a destination ColorKey with that violet color's RGB value, it should technically be transparent and would appear, for all intents and purposes, like an Overlay. You should also be able to do this with Direct2D/3D.

The one potential caveat of his approach is that using DirectDraw you wouldn't be able to display it on top of a DirectX window which has fullscreen-exclusive mode (most games D3D11 and earlier). The voice chat program Ventrilo did this, presumably(?) with hooks or by scoping out the target window's handle, instead of creating a physical window to draw the overlay on as per my example above.

Yes, DDrawCompat uses shaders at some level, for example, color keying. I don't know if overlays work, I tested 3 years back when it didn't. Maybe it is just in a half-baked state right now?

Would you be able to share the test "overlay"app, to see how it performs on top of DxWnd overlay emulation?

About your overlay suggestion, I think DxWnd does something similar to that: create a windowless transparent surface and blits the overlay content on top of it (it also gives an option of a non transparent background since my Voodoo2 creates a black BG in mosquito.exe demo, can't say if that's correct or wrong).

Fullscreen exclusivity can be handled, I think in most cases with a fake-fullscreen approach: modern Windows uses a pseudo-exclusive-fullscreen approach anyways which breaks in "some games". DDrawCompat has handled these cases some way even with the fake fullscreen option. DxWnd did by removing the SetCooperativeLevel::EXCLUSIVE flags from apps, we have just 1 app that fails using this (a game named "Inline Racing") but otherwise it works fine, and also putting a modal window behind it so that the BG elements don't interfere

Armitage Shanks wrote on 2025-04-21, 09:28:

DirectDraw emulates ModeX on XP but in doing so, forces you into banked memory access.

I will check out that link you posted, I'm curious. It's possibly a Windows 2000 PCI driver that (like some do) works on XP.

I never ran Quake 2 in software mode (I had 3D since the Riva128/GLQuake days), but I imagine if it supported 320x240 (which would look, um, chunky 😀), I think it would have been done using the OpenGL software renderer (ref_soft.dll).

Was there a reason it would "emulate" and not "abstract" 😀 ?

Since we are talking on Quake based games, you may be interested about DISPDIB and WinDirect. The latter allowed access to VGA and VESA Modes (X only?) and the former only allowed plain VGA mode 13h

Edit: Mistake: I was referring Quake 1 in Software rendering, not Quake 2. Quake 1 in SW Renderer, with Win95/98/ME compat modes, directly reroutes to the WinDirect method so it gets to use VGA MODE X (and probably higher?). The method however, isn't compatible with KERNEL32.DLL on newer Windows so it fails to launch the game before execution. I wonder what would have happened if WinXP was running with a banked mode MODEX.DLL as a system driver and KERNEL32.DLL could thunk the WDIR code.