You'll probably need the 3D DDK (updated ICD DDK) that Microsoft released Oct 2001 to find out anything about the function (optional, implementation details etc.) - it certainly isn't mentioned in my copy of the ICD DDK from Oct 1998, which did support Win2k. Unfortuantely I've never come across a copy of the 3D DDK, and back in the day IHV's had to pay $5000 for access to it.

Decompiling the Opengl32.dll from my installation of Win2k SP4 the function is referenced, but I can't confirm if it is ever called. The logs you found are the OpenGL32.dll calling GetProcAddress for the function, but not finding it (returned NULL) so all that confirms is that the ICD on those machines didn't export it. This occurs in a function that loops trying to get the address of all the Drv* functions and populates part of the Device Context (HDC) that was passed in with the wgl function call. Interestingly it does this with every wgl call rather than just once at startup.

I wonder if supporting it was optional, and no-one ever did. In my copy of the DDK it has this to say about the Role of DirectDraw, from which you can draw your own conclusions:

In the current implementation of the DDK, we are using DirectDraw as the drawable surface manager and allocator. This is done for both front buffers (buffers that map directly to an area on the screen) and some ancillary buffers (back, depth, stencil). We used DirectDraw because it provides user-space management of video memory.
IHV’s may or may not want to use DirectDraw as their surface management implementation. If they do not, then their must provide their own way of performing surface management, most probably in their graphics driver, accessed from userspace via ExtEscape calls.

Using DirectDraw presents a particular challenge. The DirectDraw interface specifies that the user must lock the surface before accessing it. It also requests that the user must keep the lock for as short a periods of time as possible. 3D graphics API’s, however, tend to require access to a surface for relatively longer periods of time, and immediate mode interfaces like OpenGL, in particular, return control to the application for indefinite intervals between API calls. If the surface lock is not maintained between API calls there is a significant performance impact to taking the lock on a per-call basis; if it is maintained, it violates the DirectDraw requirement.

Hi hornet1990, happy to encounter you again here. %-)

hornet1990 wrote on 2025-01-31, 22:05:

The logs you found are the OpenGL32.dll calling GetProcAddress for the function, but not finding it (returned NULL) so all that confirms is that the ICD on those machines didn't export it. This occurs in a function that loops trying to get the address of all the Drv* functions and populates part of the Device Context (HDC) that was passed in with the wgl function call.

Ouch, you're right. Uhhhm.
There is one inaccuracy here, though: ICD functions are populated into the GL rendering context, not into the DC.

hornet1990 wrote on 2025-01-31, 22:05:

Interestingly it does this with every wgl call rather than just once at startup.

I guess there must be a short path in code that would return the ICD if it is already loaded for the device corresponding to the DC.

hornet1990 wrote on 2025-01-31, 22:05:

Decompiling the Opengl32.dll from my installation of Win2k SP4 the function is referenced, but I can't confirm if it is ever called.

Definitely yes. You can examine the wglCreateContext() function from opengl32.dll in a debugger with Microsoft symbols loaded, and you will see that the incoming DC is checked for being a DirectDraw surface by calling IDirectDraw::GetSurfaceFromDC(). If it succeeds, then InitDdSurface() is called (where `Dd` obviously means DirectDraw), otherwise it will be InitDeviceSurface() (implying a DC's active BITMAP).

hornet1990 wrote on 2025-01-31, 22:05:

I wonder if supporting it was optional, and no-one ever did. In my copy of the DDK it has this to say about the Role of DirectDr […]
Show full quote

I wonder if supporting it was optional, and no-one ever did. In my copy of the DDK it has this to say about the Role of DirectDraw, from which you can draw your own conclusions:

In the current implementation of the DDK, we are using DirectDraw as the drawable surface manager and allocator. This is done for both front buffers (buffers that map directly to an area on the screen) and some ancillary buffers (back, depth, stencil). We used DirectDraw because it provides user-space management of video memory.
IHV’s may or may not want to use DirectDraw as their surface management implementation. If they do not, then their must provide their own way of performing surface management, most probably in their graphics driver, accessed from userspace via ExtEscape calls.

Using DirectDraw presents a particular challenge. The DirectDraw interface specifies that the user must lock the surface before accessing it. It also requests that the user must keep the lock for as short a periods of time as possible. 3D graphics API’s, however, tend to require access to a surface for relatively longer periods of time, and immediate mode interfaces like OpenGL, in particular, return control to the application for indefinite intervals between API calls. If the surface lock is not maintained between API calls there is a significant performance impact to taking the lock on a per-call basis; if it is maintained, it violates the DirectDraw requirement.

Yup, I've already saw this text in my copy of opengl-icd.doc, version 1.101 for NT 4.0, NT 5.0 (sic!), Win95 and Win98, that I found somewhere (it's from 1998 or 2001; alas, not a full ICD DDK). It also doesn't mention DrvCreateDirectDrawContext(), unfortunately.

Sorry about the delay responding, had a bit on...

BlackDoomer wrote on 2025-02-01, 07:08:

Ouch, you're right. Uhhhm.
There is one inaccuracy here, though: ICD functions are populated into the GL rendering context, not into the DC.

You are correct, I was going off the Ghidra decompile which was telling me that but obviously wasn't correct - decompilation isn't an exact science, and no offense but I wasn't going to spend hours pouring over it checking every line of generated code! I have now located the code I wanted though.

BlackDoomer wrote on 2025-02-01, 07:08:

I guess there must be a short path in code that would return the ICD if it is already loaded for the device corresponding to the DC.

There is, I found it.

BlackDoomer wrote on 2025-02-01, 07:08:

Definitely yes. You can examine the wglCreateContext() function from opengl32.dll in a debugger with Microsoft symbols loaded, and you will see that the incoming DC is checked for being a DirectDraw surface by calling IDirectDraw::GetSurfaceFromDC(). If it succeeds, then InitDdSurface() is called (where `Dd` obviously means DirectDraw), otherwise it will be InitDeviceSurface() (implying a DC's active BITMAP).

Yep, that's all correct. The next step after the above is it checks for flags that were populated in InitDdSurface() and if DirectDraw surfaces are available (flags & 0x00000002) then it calls DrvCreateDirectDrawContext(). If that entry point isn't defined, or the call fails for whatever reason then it errors out, failing to create the GL Rendering Context.

You might also be interested to know that wglCreateContext() literally just calls wglCreateLayerContext(hdc, 0) i.e. layer zero, which then does all the above.

Given the above it all comes down to the HDC that was obtained from the window handle (i.e. what GDI is supplying to the app), if that represents a DirectDraw surface then obviously all the above is valid. Given that you've not found a public driver that exports DrvCreateDirectDrawContext() leads me to think that Microsoft was developing this as part of changes to GDI or its replacement, and presumably had engineering drivers from at least one IHV that did export the function for testing purposes, but ultimately didn't end up deploying it. Certainly feels like it could have been an optimisation path to avoid any GDI emulation layer over DirectDraw.

Without a more up to date ICD DDK I don't think you're going to get any definitive answers though I'm afraid.

BlackDoomer wrote on 2025-02-01, 07:08:

Yup, I've already saw this text in my copy of opengl-icd.doc, version 1.101 for NT 4.0, NT 5.0 (sic!), Win95 and Win98, that I found somewhere (it's from 1998 or 2001; alas, not a full ICD DDK). It also doesn't mention DrvCreateDirectDrawContext(), unfortunately.

Version 1.101 is from the 1998 ICD DDK release (same version I've got).

hornet1990 wrote on 2025-02-09, 20:13:

Without a more up to date ICD DDK I don't think you're going to get any definitive answers though I'm afraid.

It's very unfortunate that OpenGL driver databases like gpuinfo.org never seem to register the functions exported by ICD in their reports. :(

hornet1990 wrote on 2025-02-09, 20:13:

Given that you've not found a public driver that exports DrvCreateDirectDrawContext() leads me to think that Microsoft was developing this as part of changes to GDI or its replacement, and presumably had engineering drivers from at least one IHV that did export the function for testing purposes, but ultimately didn't end up deploying it. Certainly feels like it could have been an optimisation path to avoid any GDI emulation layer over DirectDraw.

In my opinion, this is too much of a speculation. What would stop a vendor from implementing this code path in their release drivers if it is available in the header from the official DDK, and its support in the operating system is complete and functioning?

hornet1990 wrote on 2025-02-09, 20:13:

Given the above it all comes down to the HDC that was obtained from the window handle (i.e. what GDI is supplying to the app), if that represents a DirectDraw surface then obviously all the above is valid.

A context can also be created using a DC obtained from CreateDC(). The important fact here is that for the Windows implementation of OpenGL this could have been an ideal way to both select a rendering device (see the parameters of this function) and switch to exclusive fullscreen and back (the context is not tied to a specific DC, so for a windowed mode it would be enough to replace DC with a window one). But alas, DescribePixelFormat() enumerates only standard, non-ICD pixelformats for such "direct DCs", as far as I can see, thus implying GDI software rendering.

Although if you create such a context, it will indeed be fullscreen! The device selection, though, does not work at least on laptops with NVIDIA Optimus - an attempt to get a DC for a discrete chip ends with an error. Know why? Vendors simply never supported both mechanisms, even with them being available. The reason? Yes, it may be an obvious flaw in opengl32.dll itself, which can be noticed by looking at the wglMakeCurrent() function in the debugger: compatibility with the pixelformat of specified DC is determined there not through some proper comparison of formats, but simply by matching with the index of the initial pixelformat from the DescribePixelFormat() enumeration! Which essentially makes it impossible, say, to create a context on one device, but draw with it on a DC from another.

However, personally I believe that the real motive was ordinary self-interest. Check it yourself: NVIDIA literally monkeypatches (sic!) the process-level copy of opengl32.dll when an application is started on their chip, which conceptually breaks the dispatching of GL contexts into ICDs, allowing the program to work only with the NVIDIA device. How did this pass the WHQL certification and is there any concern for antitrust violation here - don't ask me, cause I don't know. But I’m almost sure that once upon a time they justified the refusal to support DirectDraw in WGL in much the same way.

BlackDoomer wrote on 2025-01-30, 13:21:

Many people know that OpenGL in Windows has always used DirectDraw (and previously DCI) to manage video memory.

Opengl never used any directx related features to manage anything.
In fact, initialization on windows is tied to GDI and not to directx.

BlackDoomer wrote on 2025-02-12, 17:26:

In my opinion, this is too much of a speculation. What would stop a vendor from implementing this code path in their release drivers if it is available in the header from the official DDK, and its support in the operating system is complete and functioning?

You're assuming that the support for it is "complete and functioning" in the operating system. The code for opengl32.dll is very clear that the call to GetSurfaceFromDC must succeed for the code path leading to DrvCreateDirectDrawContext to be called. Logically since no public drivers expose the entry point, and the fact that if GetSurfaceFromDC succeeded then the entry point has to exist otherwise the context will fail to be created, means we can fairly safely assume that GetSurfaceFromDC never succeeds in the public releases of windows. That's not to say it didn't in internal test builds of windows, like I say with specifically built drivers from one or more IHV's (which I'd call informed speculation).

BlackDoomer wrote on 2025-02-12, 17:26:

However, personally I believe that the real motive was ordinary self-interest. Check it yourself: NVIDIA literally monkeypatches (sic!) the process-level copy of opengl32.dll when an application is started on their chip, which conceptually breaks the dispatching of GL contexts into ICDs, allowing the program to work only with the NVIDIA device. How did this pass the WHQL certification and is there any concern for antitrust violation here - don't ask me, cause I don't know. But I’m almost sure that once upon a time they justified the refusal to support DirectDraw in WGL in much the same way.

Thats fine if Nvidia is the only player in town... but it wasn't. We know this was introduced around 2001, so there were still a good number of other IHV's around then and for a few years afterwards. None of them apparently implemented this entry point in public drivers either. Certainly Matrox didn't with the G550, PowerVR didn't with the tail end Kyro support. Then there's ATI, Intel, 3dLabs, Via (S3)... did they all choose not to implement it out of self interest?

Lord knows I'm no fan of Nvidia and their shady practices (both business and in their software), but it's more of a stretch to think that Nvidia alone had complete influence over this IMHO.

hornet1990 wrote on 2025-02-12, 22:19:

The code for opengl32.dll is very clear that the call to GetSurfaceFromDC must succeed for the code path leading to DrvCreateDirectDrawContext to be called. Logically since no public drivers expose the entry point, and the fact that if GetSurfaceFromDC succeeded then the entry point has to exist otherwise the context will fail to be created, means we can fairly safely assume that GetSurfaceFromDC never succeeds in the public releases of windows.

GetSurfaceFromDC() is a DirectDraw function that is called only to check whether the provided DC is a DirectDraw one. Of course, it will never succeed on DCs neither from the USER subsystem (GetDC() and GetWindowDC(), which is what is usually used), nor from the GDI (CreateDC(), CreateCompatibleDC(), and their *IC counterparts).

hornet1990 wrote on 2025-02-12, 22:19:

Thats fine if Nvidia is the only player in town... but it wasn't. We know this was introduced around 2001, so there were still a good number of other IHV's around then and for a few years afterwards.

But the NVIDIA shark has been the biggest since it swallowed 3dfx in 2001. It was the trendsetter back then, and still is.

hornet1990 wrote on 2025-02-12, 22:19:

None of them apparently implemented this entry point in public drivers either. Certainly Matrox didn't with the G550, PowerVR didn't with the tail end Kyro support. Then there's ATI, Intel, 3dLabs, Via (S3)... did they all choose not to implement it out of self interest?

Where did the mentions that it was possible come from then? I myself brought two of these in the OP.
One could check Google Search or Google Groups for "opengl on directdraw" and see what I mean.

hornet1990 wrote on 2025-02-12, 22:19:

Lord knows I'm no fan of Nvidia and their shady practices (both business and in their software), but it's more of a stretch to think that Nvidia alone had complete influence over this IMHO.

It's just a funny touch to the portrait of NVIDIA and their "We love OpenGL" mottos. They definitely do... when it's NVIDIA GL. Alex St. John was right, after all - either there are common rules that coerce everyone, or there is a fierce competition of vendors pursuing their own goals.
Another interesting fact in the same direction is that the NVIDIA driver in Windows, starting with Vista and up to 8.1 or one of the early releases of 10, added its ICD entry to the registry not along with the standard MSOGL fallback wrapper above Direct3D, but instead of it.

Geri wrote on 2025-02-12, 18:50:

Opengl never used any directx related features to manage anything.
In fact, initialization on windows is tied to GDI and not to directx.

Have you bothered to read the thread and notice the literal quotes from the official SGI spec, huh? Go look the import directory of opengl32.dll and ask yourself why it depends on DDRAW.dll since Windows 2000, and why DCIMAN32.dll used to be there before. Let's see where that will lead you.
The only version that really relied solely on GDI was the original one in NT 3.5x. But even its subsequent port to Windows 95 had been already enabled with DCI.

BlackDoomer wrote on 2025-02-13, 05:07:

Have you bothered to read the thread and notice the literal quotes from the official SGI spec, huh?

Where?

BlackDoomer wrote on 2025-02-13, 05:07:

Go look the import directory of opengl32.dll and ask yourself why it depends on DDRAW.dll since Windows 2000, and why DCIMAN32.dll used to be there before. Let's see where that will lead you.

microsofts opengl32.dll is not an implementation of the opengl api
opengl32.dll is a component made by microsoft which sole purpose is to detect the opengl driver of your video card based on registry keys.
then it loads the file, passes the required gdi window handle, returns a list of pointers in an array which it directly retrieved from the actual opengl implementation of your video card driver.
if there are no such drivers present, then the file returns the handles of one of microsofts opengl wrappers
if everything is succesful, then the opengl based software uses the functions directly from the video cards opengl icd. microsofts opengl32.dll doesnt alters the behavior or interferes with how the opengl mcd is implemented.

the functions and findings you are referring to have nothing to do how opengl works, its old dead code created for internal operation and easy testing and debugging, its not something which actually has connection with opengl

Geri wrote on 2025-02-13, 09:15:

Where?

Ctrl+F "In the current implementation of the DDK".

Geri wrote on 2025-02-13, 09:15:

microsofts opengl32.dll is not an implementation of the opengl api opengl32.dll is a component made by microsoft which sole purp […]
Show full quote

microsofts opengl32.dll is not an implementation of the opengl api
opengl32.dll is a component made by microsoft which sole purpose is to detect the opengl driver of your video card based on registry keys.
then it loads the file, passes the required gdi window handle, returns a list of pointers in an array which it directly retrieved from the actual opengl implementation of your video card driver.
if there are no such drivers present, then the file returns the handles of one of microsofts opengl wrappers
if everything is succesful, then the opengl based software uses the functions directly from the video cards opengl icd.

I'm sorry to say that, but you are wrong: opengl32.dll also implements the default OpenGL software renderer in Windows, known as "GDI Generic".
See this, for example: https://news.ycombinator.com/item?id=42990208

Geri wrote on 2025-02-13, 09:15:

microsofts opengl32.dll doesnt alters the behavior or interferes with how the opengl mcd is implemented.

MCD is a different beast than ICD. I have no clue why you remembered it here.

Geri wrote on 2025-02-13, 09:15:

the functions and findings you are referring to have nothing to do how opengl works, its old dead code created for internal operation and easy testing and debugging, its not something which actually has connection with opengl

Please put the casuistry back where it was. I thought it was obvious that in this thread by "OpenGL" I mean its official implementation in Windows, not the specification itself.

BlackDoomer wrote on 2025-02-13, 09:37:

Ctrl+F "In the current implementation of the DDK".

Illustrational materials from microsoft are not a part of the opengl api (or how opengl works).

BlackDoomer wrote on 2025-02-13, 09:37:

I'm sorry to say that, but you are wrong: opengl32.dll also implements the default OpenGL software renderer in Windows, known as "GDI Generic".

Opengl32.dll contains whatever microsoft puts there, that doesn't makes it part of the opengl api, and it doesnt alters how opengl operates.

BlackDoomer wrote on 2025-02-13, 09:15:

MCD is a different beast than ICD. I have no clue why you remembered it here.

The ICD, supplied by the graphics card manufacturer, are being called by opengl32.dll, which is basically a generic mcd. Its returning the function pointers of the icd to the caller application, it doesn't do anything on its own with how an opengl driver is implemented.

BlackDoomer wrote on 2025-02-13, 09:15:

Please put the casuistry back where it was. I thought it was obvious that in this thread by "OpenGL" I mean its official implementation in Windows, not the specification itself.

The official implementation of opengl in windows is the opengl 1.1 software renderer and the opengl 1.1 direct3d wrapper which microsoft is supplying, and lLikely thats the cause why opengl32.dll also does some handshakes with directdraw. Opengl drivers are made by manufacturers. Microsofts opengl32.dll has nothing to do how they work, except for redirecting the pointers from the icd.

In short, your findings are telling a story about how microsoft is writing and structuring their operating systems, they are not relevant to actual implementation of opengl drivers.

Geri wrote on 2025-02-13, 10:05:

The ICD, supplied by the graphics card manufacturer, are being called by opengl32.dll, which is basically a generic mcd.

This is simply terminologically flawed. MCD (Mini Client Driver) is just another driver model for OpenGL implementation on Windows. Which was easier to forge than ICD, but less powerful and in fact just accelerating the default GDI Generic renderer. This is why PFD_GENERIC_ACCELERATED flag of pixel format descriptor has the word “generic” in its name.
Perhaps you wanted to say "generic MiniGL", but then that's also incorrect, because MiniGLs didn't even reach OpenGL 1.0 in terms of feature set.

Geri wrote on 2025-02-13, 10:05:

The official implementation of opengl in windows is the opengl 1.1 software renderer and the opengl 1.1 direct3d wrapper which microsoft is supplying, and lLikely thats the cause why opengl32.dll also does some handshakes with directdraw.

No, that's not. These libraries, opengl32.dll and AcXtrnal.dll, are completely unrelated to each other. Please take the trouble to verify your assertions before posting them.

Geri wrote on 2025-02-13, 10:05:

In short, your findings are telling a story about how microsoft is writing and structuring their operating systems, they are not relevant to actual implementation of opengl drivers.

I can't care less. And it’s a pity: I once liked your blog article about Orbán!

BlackDoomer wrote on 2025-02-13, 10:48:

Which was easier to implement

....which is literally the same thing except the name of the initialization functions.

BlackDoomer wrote on 2025-02-13, 10:48:

No, that's not. These libraries, opengl32.dll and AcXtrnal.dll, are completely unrelated to each other. Please take the trouble to verify your assertions before posting them.

I understand your problem.
You are trying to figure this out by disassembling and reverse engineering microsofts binaries, literally trying to read every functions in implementations and everything by letter to letter in excamples.
You should actually use a different approach to this problem, and actually understand how it perpsecitivally and logicallyworks to understand whats going on, instead of being stuck with function names and chasing magic bits.

BlackDoomer wrote on 2025-02-13, 10:48:

Orbán

Lets not mix party politics with opengl icd-s.

Geri wrote on 2025-02-13, 10:57:

I understand your problem.
You are trying to figure this out by disassembling and reverse engineering microsofts binaries, literally trying to read every functions in implementations and everything by letter to letter in excamples.
You should actually use a different approach to this problem, and actually understand how it perpsecitivally and logicallyworks to understand whats going on, instead of being stuck with function names and chasing magic bits.

Currently I have no problem other than you flaming in this topic. With all due respect to your expertise and work on TitaniumGL (even though it fails to run Doom2D Forever, but nevermind).

BlackDoomer wrote on 2025-02-13, 11:06:

Currently I have no problem other than you flaming in this topic.

I am sorry if you felt that way, but i wasnt flaming anywhere, maybe its only you who felt that way.

BlackDoomer wrote on 2025-02-13, 11:06:

With all due respect to your expertise and work on TitaniumGL

Next time you should be careful when summoning dark wizzards, because they might actually appear 😁
https://www.newyorker.com/humor/daily-shouts/ … eet-your-heroes

BlackDoomer wrote on 2025-02-13, 11:06:

even though it fails to run Doom2D Forever

Never heard of that game, no one previously reported any issues with it. I only check on something if someone reports a problem.

BlackDoomer wrote on 2025-02-13, 11:06:

even though it fails to run Doom2D Forever, but nevermind

Are you pulling my nose? I tested doom2d and it ran with it without issues.

Geri wrote on 2025-02-14, 21:16:

Are you pulling my nose? I tested doom2d and it ran with it without issues.

I'll send you PM with glitches screenshots so as not to go off-topic here.