Minihwc.c getRegPath() returns null on Win98

Hi, if you could help me a little.

Im trying to make it work on win98, but cant seem to figure this one out.

User env variables are not being set, because in minihwc.c, function getRegPath() return null when checked in function hwcGetenv.

if (regPath == NULL) {
regPath = getRegPath();

if (regPath == NULL){
  return NULL;
}

Works fine for winXp. Works if built with DEBUG=1 parameter in win98.
I can hardcode the return string
CM_Get_DevNode_Key( QDevNode.dwDevNode, NULL,
strval, sizeof(strval),
CM_REGISTRY_SOFTWARE );

  //strcat(strval, "\\glide");
  retVal = "SYSTEM\\CurrentControlSet\\Services\\Class\\Display\\0000\\glide";

Ofc that works, but its not really a solution :).

How do you compile glide?

Assuming that you are building with MSVC6 and building h5: If you change the #if 0 to #if 1 at
https://github.com/sezero/glide/blob/glide-devel-sezero/glide3x/h5/minihwc/minihwc.c#L770
(and possibly remove win9x.obj from objects list) and build against win9x ddk: does it work then?

Thank you for responding.
Yes h5.

I build on winxp, with winxpddk(2600) with win98sdk, vc6 headers and all other old stuff installed. I dont use win9x.obj, reverted to state on sourceforge glide dev branch.

I tried Koolsmokys built dll
(https://www.3dfxzone.it/news/reader.php?objid=5280)

Has the same behaviour. Xp fine, win98 no-go.

Works fine if built as debug, so hard for me to debug it :)

I tried Koolsmokys built dll (https://www.3dfxzone.it/news/reader.php?objid=5280)

Has the same behaviour. Xp fine, win98 no-go.

Huh. OK, will look at this as soon as possible.

Just to confirm: does this build work properly instead? h5.zip
It is built with mingw, optimized.

No this one doesnt work.

That getRegPath returns NULL for you means that ExtEspace is somehow failing, don't know how - yet.

Thanks for looking into it, I spent more time than Im willing to admit, with no resolve :)

Two more questions though:

Did you build from my own branch with DEBUG=1 and if you did, does it work too?

The error screenshot you showed above: Unreal uses glide2x, not glide3x: how are
you making it to use glide3x?

Just tested it now, from your codebase as debug=1 doesnt work, will ignore user settings(switched about 3 weeks ago, forgot).
This is the exact one Im using now:
sourceForgeDevelop.zip

Wanted as little change as posible and when everything worked, the plan was to add your changes to it.

I use a glide2 to glide3 wrapper from this guy: https://wenchy.net/old/glidexp/, so everything glide will go to glide3x.

You trying a different compiler got me thinking. What if really isnt a code problem?

So I tried a couple, and win2kddk compiles it correctly, registry path gets read.
Ofc, as always, something else broke, now asm part is broke.

I can only compile it with "make -f Makefile.win32 FX_GLIDE_HW=h5" without the USE_X86=1.

Come to think of it, could just be that it doesnt find nasm

Those line numbers don't make any sense..

Yes, mine has a bit different lines. Its just asm code, I think the way I have it now(with 2kddk istead of xp) it doesnt use nasm. I tried moving it around, not sure how to configure it to make it work.

Ok its not that, it takes nasm just well, the problem is somewhere else.

Heres the file so you can see what are the lines
minihwc.zip

Nothing to affect build in your changes as far as I can see.

Maybe instead of moving configmg.h stuff into win9x.asm
I should inline them into c code and let compiler do its thing.
Like below:

diff --git a/glide3x/h5/glide3/src/Makefile.mingw b/glide3x/h5/glide3/src/Makefile.mingw
index 3900876..2a05bbc 100644
--- a/glide3x/h5/glide3/src/Makefile.mingw
+++ b/glide3x/h5/glide3/src/Makefile.mingw
@@ -273,5 +273,2 @@ GLIDE_OBJECTS += \
 	../../minihwc/win_mode.o
-# so that we don't need win9x ddk:
-GLIDE_OBJECTS += \
-	../../minihwc/win9x.o
 
@@ -368,5 +365,2 @@ xdrawtri.o: xdrawtri.asm
 
-../../minihwc/win9x.o: ../../minihwc/win9x.asm
-	$(AS) -o $@ -O2 -fwin32 $<
-
 $(GLIDE_OBJECTS): fxinline.h fxgasm.h fxbldno.h
diff --git a/glide3x/h5/glide3/src/Makefile.win32 b/glide3x/h5/glide3/src/Makefile.win32
index 8241ac0..6702b90 100644
--- a/glide3x/h5/glide3/src/Makefile.win32
+++ b/glide3x/h5/glide3/src/Makefile.win32
@@ -222,5 +222,2 @@ GLIDE_OBJECTS += \
 	../../minihwc/win_mode.obj
-# so that we don't need win9x ddk:
-GLIDE_OBJECTS += \
-	../../minihwc/win9x.obj
 
@@ -304,5 +301,2 @@ xtexdl_sse2.obj: xtexdl.asm
 
-../../minihwc/win9x.obj: ../../minihwc/win9x.asm
-	$(AS) -o $@ -O2 -fwin32 $<
-
 $(GLIDE_OBJECTS): fxinline.h fxgasm.h fxbldno.h
diff --git a/glide3x/h5/minihwc/minihwc.c b/glide3x/h5/minihwc/minihwc.c
index ed46249..b51cf93 100644
--- a/glide3x/h5/minihwc/minihwc.c
+++ b/glide3x/h5/minihwc/minihwc.c
@@ -767,19 +767,68 @@
 
 #include <ddraw.h>
 #include "qmodes.h"
-#if 0 /* moved to asm so we don't need w9x ddk headers. */
+#if 0 /* inlined here so we don't need w9x ddk headers. */
 #define IS_32
 #define Not_VxD
 #include <minivdd.h>
 #include <vmm.h>
 #include <configmg.h>
 #else
-extern DWORD __cdecl CM_Get_DevNode_Key(DWORD,PCHAR,PVOID,ULONG,ULONG);
 #define CM_REGISTRY_HARDWARE 0
 #define CM_REGISTRY_SOFTWARE 1
+#define CR_FAILURE 0x00000013
+#define ___CONFIGMG_Get_DevNode_Key 0x0033003d
+struct _CMIOCTLPACKET {
+ DWORD dwStack;
+ DWORD dwServiceNumber;
+};
+static DWORD WINAPI CMIOCTLHandler(struct _CMIOCTLPACKET *pkt)
+{
+  HANDLE hCONFIGMG;
+  DWORD crReturnValue = CR_FAILURE;
+  DWORD dwReturnSize = 0;
+
+  hCONFIGMG = CreateFileA(
+    "\\\\.\\CONFIGMG",
+    GENERIC_READ|GENERIC_WRITE,
+    FILE_SHARE_READ|FILE_SHARE_WRITE,
+    NULL, OPEN_EXISTING, 0, NULL);
+
+  if (hCONFIGMG == INVALID_HANDLE_VALUE) {
+      return CR_FAILURE;
+  }
+  if (!DeviceIoControl(
+        hCONFIGMG, pkt->dwServiceNumber,
+        &(pkt->dwStack), sizeof(pkt->dwStack),
+        &crReturnValue, sizeof(crReturnValue),
+        &dwReturnSize, NULL)) {
+    crReturnValue = CR_FAILURE;
+  }
+  CloseHandle(hCONFIGMG);
+  if (dwReturnSize != sizeof(crReturnValue)) {
+      crReturnValue = CR_FAILURE;
+  }
+  return crReturnValue;
+}
+static DWORD __cdecl CM_Get_DevNode_Key (DWORD devnode, char *subkey, void *buffer, ULONG bufferlen, ULONG flags)
+{
+    struct _CMIOCTLPACKET packet;
+    DWORD dwStack;
+    #if defined(_MSC_VER)
+    _asm {mov dwStack, ebp};
+    #elif defined(__GNUC__)
+    dwStack = (DWORD) __builtin_frame_address(0);
+    #else
+    #error Add support for your compiler here.
+    #endif
+    dwStack += 8;
+    packet.dwStack = dwStack;
+    packet.dwServiceNumber = 0x80000000 + (___CONFIGMG_Get_DevNode_Key & 0xFFFF);
+    return CMIOCTLHandler(&packet);
+}
 #endif
 
-#endif
+#endif /* __WIN32__ */
 
 #ifdef macintosh
 #include <GraphicsPrivHwc.h>

Does the inlined functionality look correct to you? (Sorry, that I still
can't run-test stuff, yet.)

Here is a build using mingw gcc with such a change: h5-2.zip

Please try that build, and also yours if you can e.g. with MSVC etc.

Nothing to affect build in your changes as far as I can see.

It always seems to choke on MovQ mm3, mmword ptr [edx]

I remember to have tried building with MSVC6 with success in the past.
Will try again soon.

I dont think that win9x.asm is the problem in any way, since I also use sourceforge last build and that one doesnt use it.

So right now, I can either build with xpddk + all the old sdks.
make -f Makefile.win32 FX_GLIDE_HW=h5 USE_X86=1 USE_3DNOW=1 USE_MMX=1 USE_SSE=1 USE_SSE2=1 USE_TEXUS=1
This will return no issue, but regPath will be null. On win98, xp is fine.

Or I can build with 2kddk + all the old sdk, this one will work fine, but then I cant use use_x86, since this will fail.
make -f Makefile.win32 FX_GLIDE_HW=h5

I tried combining what cc, asm, link it uses, by changing the paths in makefile. Doesnt really matter, as long as c compiler is from xpddk, it will work(but with getReg problem), everything else will fail if used with asm.

Ill try the h5 build now - Nope, same problem as before, dies on init.

Ill try the h5 build now - Nope, same problem as before, dies on init.

What happens if you build it (my branch + the change above) yourself with msvc without ddk?

Removed all ddk(s) from path, should be only vc6.

As "make -f Makefile.win32 FX_GLIDE_HW=h5", dll comes out, not gonna test it, but should work.
As "make -f Makefile.win32 FX_GLIDE_HW=h5 USE_X86=1", same problem as before.

Crap I missed a few, only did minihwc, just a sec... Yea same.

How about we do the oposite? Move the problematic code to seperate file, compile with nasm and have just calls to obj?
Im not really an assembler(or C for that matter) guy, would that come with any perf penalty?

How about we do the oposite? Move the problematic code to seperate file,

Which part of the code?

In minihwc.c every(complete) part thats in the error lines 62xx... 6350.... 685x#if GL_X86 and so on...

@dborca

I still haven't been able to rig up my old boxes for this.

However windows code had been touched a lot by KoolSmoky (and possibly
by Daniel Borca). Don't know how to contact KoolSmoky, but maybe dborca has
something to say about your issues: @dborca?

@dborca

Hey, thanks for keeping it open.
This is what Im doing with it.

But I used Koolsmokys source as base, since it works a bit better for win98 and Im slowly porting this changes into it.
So no hurry, keep it open and if I ever get around to it to catch it, Il write it here.

If @dborca sees this, I know its been like 15y, but if you happen to still have the source from mesafx6.3, would love to have it. I started converting 6.4.2, but its gonna take its time :)

Navigation Menu

Repository navigation

Minihwc.c getRegPath() returns null on Win98 #2

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Minihwc.c getRegPath() returns null on Win98 #2

Description

Activity

sezero commented on Jun 7, 2022

NejcDolicanin commented on Jun 7, 2022

sezero commented on Jun 7, 2022

sezero commented on Jun 7, 2022

NejcDolicanin commented on Jun 7, 2022

sezero commented on Jun 7, 2022

NejcDolicanin commented on Jun 7, 2022

sezero commented on Jun 7, 2022

NejcDolicanin commented on Jun 7, 2022

NejcDolicanin commented on Jun 10, 2022

sezero commented on Jun 10, 2022

NejcDolicanin commented on Jun 10, 2022

sezero commented on Jun 10, 2022

sezero commented on Jun 10, 2022

sezero commented on Jun 10, 2022

NejcDolicanin commented on Jun 10, 2022

sezero commented on Jun 10, 2022

NejcDolicanin commented on Jun 10, 2022

NejcDolicanin commented on Jun 10, 2022

sezero commented on Jun 10, 2022

NejcDolicanin commented on Jun 10, 2022

sezero commented on Jul 23, 2022

NejcDolicanin commented on Jul 23, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions