OPENGL for HXDOS

[RUSSTARUS]

Hello Andreas Grech!

I moved this topic to the HX section from VSBHDA Baron-von-Riedesel/VSBHDA#40

Yes I checked OPENGL32.DLL c QUAKE2 today. Yes it works under HXDOS, but of course it is very slow.
It does not always start on the first try under HXDOS.

It is not possible to play even in pure Windows, as it is still without acceleration.
It was important to check only the launch.
I have already said that this is only a software implementation of OPENGL, without hardware acceleration.

I also tested OPENGL on my simple examples (test.exe) using GLUT32.DLL
It doesn't always run the first time under HXDOS.

I found that these tests don't work correctly in HXDOS compared to pure Windows. The GLUT32.DLL library provides
a mouse and keyboard interface and other screen preparation functions. However, it doesn't correctly intercept keyboard and mouse handlers
from the HXDOS kernel. In pure Windows, everything works fine.
QUAKE2 does not use GLUT32.DLL, but it also has problems with keyboard and mouse handlers in OPENGL mode in HXDOS.

It's as if something is slowing down the event handler threads. Even loading map files stops until you move the mouse
and press keys (this can be seen in the interface lines). The algorithm seems to pause until you press a key or move the mouse.

I have prepared the necessary files for you, and you can test and compare the behavior of OPENGL programs yourself. If you wish.

A bit about the OPENGL32.DLL file. It is compiled from the ReactOS project and simplified to avoid unnecessary OS registry checks. It tries to
open the IGLICD32.DLL (standart ICD driver for INTEL video card), and if without success, then OPENGL
software processing based on the MESA project is started. Works as a stub if there is no hardware acceleration. From the IGLICD32.DLL file, it tries to import functions:

DrvCopyContext;
DrvCreateContext;
DrvCreateLayerContext;
DrvDeleteContext;
DrvDescribeLayerPlane;
DrvDescribePixelFormat;
DrvGetLayerPaletteEntries;
DrvGetProcAddress;
DrvReleaseContext;
DrvRealizeLayerPalette;
DrvSetContext;
DrvSetLayerPaletteEntries;
DrvSetPixelFormat;
DrvShareLists;
DrvSwapBuffers;
DrvSwapLayerBuffers;

These are the functions that I will try to implement in the future to communicate with the DRM (Direct Rendering Manager) kernel (which I have already written).
It will work on the HXDOS kernel side. (DGDI32.DLL)

For now, this is just a software implementation of OPENGL32, which works to check the overall picture.

I would like to know from you if it is possible to solve this problem in HXDOS with keyboard and mouse event handlers for OPENGL.
Is this fundamental or not? Is there a way to fix it? What's the matter here?

Ruslan

FILES.zip

[RUSSTARUS]

Hello Andreas Grech!

Do you have any ideas about the reason for this behavior of HXDOS ?

It seems to me that the problem is that HXDOS does not pass the keyboard and mouse handlers to the new window (context window), which creates any OPENGL application after the creation of the main process (main window).

I have attached a new application, and it is clearly visible that the system process is not given to the OPENGL application window.
The process is slowed down until the keyboard or mouse handler of the main window is triggered.

Please see the behavior of HXDOS in OPENGL applications

FILES2.zip

[Baron-von-Riedesel]

Do you have any ideas about the reason for this behavior of HXDOS ?

Sorry, but the last time I dealt with OpenGL or HX's implementation of DirectDraw/GDI is more than 10 years ago, so I cannot answer your questions from memory.

Will have to try your files first...

edit: trying to run binary my7new.exe gives error:

DPMILD32: import not found: joySetThreshold
DPMILD32: file WINMM.dll

So you must use a modified winmm.dll...

[RUSSTARUS]

Yes, I added some stubs and modified WINMM.DLL a little when I was working on DPCI.DLL for your HXDOS (2.17+)
There's just a stub for this function and that's it. Since then, this WINMM.DLL has been working for the following versions of HXDOS (2.22).
I think you can easily add the required functions to WINMM.DLL (these are just stubs for gaming programs).
If necessary, I can send you my modified WINMM.DLL

[RUSSTARUS]

Hello.

For the joySetThreshold function, I just added a stub to the joy.asm file for the WINMM.DLL library.

joySetThreshold proc public uJoyID:DWORD, Threshold:DWORD
mov eax, MMSYSERR_NODRIVER
@strace <"joySetThreshold(", uJoyID, ")=", eax, " *** unsupp ***">
ret
align 4
joySetThreshold endp

This is basically what you did for the other joystick functions. For some reason, you didn't add this function yourself initially.
I followed your examples. I don't use a joystick, and I believe this is causing GLUT32.DLL during initial initialization.

Are there any other problems with running the test program?

The test program can also be compiled on WATCOM C: (wcl386 -3s test.c)

test.zip

[Baron-von-Riedesel]

Thanks for the info! Sorry for my delayed responses, but I was busy with various other things to fix (jwasm, jwlink, vsbhda, jemm).

[Baron-von-Riedesel]

Are there any other problems with running the test program?

It's causing a GPF in dkrnl32.dll, in LeaveCriticalSection:

LeaveCriticalSection proc public uses ebx pCS:ptr CRITICAL_SECTION

	mov ebx,pCS
	cmp [ebx].CRITICAL_SECTION.LockCount,0
	jz exit
if ?GBLCURRENT
	mov eax, [g_hCurThread]
else
	invoke _GetCurrentThread
endif
	cmp eax,[ebx].CRITICAL_SECTION.OwningThread
	jnz exit
	dec [ebx].CRITICAL_SECTION.LockCount
	jnz exit
	mov [ebx].CRITICAL_SECTION.OwningThread,0
	invoke SetEvent, [ebx].CRITICAL_SECTION.LockSemaphore
if ?EVENTOPT	;isn't this done in SetEvent already?
	mov ecx, [ebx].CRITICAL_SECTION.LockSemaphore
	mov eax, [ecx].EVENT.hThread                                          ;<<<<---- GPF here because ECX == 0
	.if (eax)				;was another thread blocked?
		xor ecx,ecx			;flag TF_WAITING cleared
		call [g_dwIdleProc]
	.endif
endif
exit:
;	@strace	<"LeaveCriticalSection(", pCS, ")=void">
	ret
	align 4

LeaveCriticalSection endp

The GPF happens because I set DPMILDR=2056 in AUTOEXEC.BAT. This makes DPMILD32 setup the flat data descriptor for Win32 to EXPAND DOWN - a simple method to protect NULL pointer accesses.

[RUSSTARUS]

About the critical section, I don't know what to say, as I'm not very good at it.
(This is already the core! But I would really like to learn how to understand it!)

I can only confirm what I told you earlier. The program didn't always start on the first try. It required a
computer reboot!

Then, for some reason, it would miraculously start. It was incredible. That's how I found out that it still
works on HX DOS.

But I'll remind you that HX DOS does not pass control handlers (mouse and keyboard, as well as the worker thread) to the running OPENGL application.

Any OPENGL application, in addition to the main window, also creates a context window in which
the image is rendered and passed to the handler. I think that HX DOS does not take this into account.

I will provide you with the necessary file for outputting to GDI windows for the OPENGL application.

Take a look at it, it might give you some ideas.

graw_gdi.zip

[Baron-von-Riedesel]

Take a look at it, it might give you some ideas.

No, I don't have the slightest idea what this is supposed to tell me. Btw, so long as there are such low-level GPFs, these should be fixed FIRST.

[RUSSTARUS]

I just wanted to show you how windows and basic processes are created on the OPENGL application side. The kernel must handle this correctly for OPENGL applications. It is clear that the problem lies somewhere in the kernel (dkrnl32.dll) and in the correct handling of access streams to created windows. I believe that only you can fix this issue, as you are the one who knows it best.

In fact, I have been looking at the kernel files, and I am amazed by your work! How can you write so much yourself? It is truly remarkable.
Own operating system! (MS WINDOWS compatible). This is great and I like HXDOS!

As for me, I learn programming by examples of others. It's interesting to look at the code and understand how people
write it and what they know about it.

[Baron-von-Riedesel]

In fact, I have been looking at the kernel files, and I am amazed by your work! How can you write so much yourself? It is truly remarkable.

There were 2 phases when I worked very intensively at the Win32 emulation: first around 1995, to allow "dual-mode" console programs, and then around 2005-2006 (for GDI/DirectX emulation).

[RUSSTARUS]

Hello Andreas Grech!

I found on the Internet compiled library OPENGL32.DLL based on the new software drivers MESA. (driver LLVMpipe)
This library is also without hardware acceleration, but supports all modern extensions OPENGL. Shaders and other.
Its size is quite large - 72 Mbytes! It works on Windows XP, but in HXDOS it needs the function GetHandleInformation in kernel

https://learn.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-gethandleinformation

I wanted to ask you if it is possible to add something similar to the HXDOS kernel?

Have you achieved any progress in making HXDOS compatible with OPENGL applications? Have you made any conclusions?

opengl32.zip

[Baron-von-Riedesel]

I wanted to ask you if it is possible to add something similar to the HXDOS kernel?

I'm afraid you'll have to do such things on your own - I'm not too eager to make hx compatible with a 72 MB XP dll - that's almost certainly a sisyphos job.

Have you achieved any progress in making HXDOS compatible with OPENGL applications? Have you made any conclusions?

Not really. I run your program in Win98SE to see how it is supposed to work. I understand the problem now, but don't know how to fix it.

[RUSSTARUS]

This library (OpenGL32.dll - 72 MBytes) was compiled by the author specifically for use in win95/98/Me

https://github.com/JHRobotics/mesa9x

I have not tested it under Win98, but it should work correctly there!
Working with Win95 requires fixing support for SSE processor instructions. There is a patch for this, SIMD95.COM

I wanted to ask: does the HXDOS kernel support SSE processor instructions? Should I use SIMD95.COM ?

I also wanted to know from you what you found out about the reason why OPENGL applications don't work in your HXDOS.
I'm interested in the technical aspects that you've discovered. I'm just curious.

simd95-1.1.zip

[Baron-von-Riedesel]

I wanted to ask: does the HXDOS kernel support SSE processor instructions?

As long as there is just one thread that's using SSE, it should be fine. But when a HX thread switch occurs, SSE registers are not saved/restored.

I also wanted to know from you what you found out about the reason why OPENGL applications don't work in your HXDOS.

I don't know anything new.