Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
NejcDolicanin opened this issue Jun 7, 2022 · 23 comments
Open

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

NejcDolicanin opened this issue Jun 7, 2022 · 23 comments

Comments

@NejcDolicanin
Copy link

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 :).

@sezero
Copy link
Owner

sezero commented Jun 7, 2022

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?

@NejcDolicanin
Copy link
Author

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 :)

@sezero
Copy link
Owner

sezero commented Jun 7, 2022

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.

@sezero
Copy link
Owner

sezero commented Jun 7, 2022

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

@NejcDolicanin
Copy link
Author

No this one doesnt work.

glideTest1

@sezero
Copy link
Owner

sezero commented Jun 7, 2022

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

@NejcDolicanin
Copy link
Author

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

@sezero
Copy link
Owner

sezero commented Jun 7, 2022

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?

@NejcDolicanin
Copy link
Author

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.

@NejcDolicanin
Copy link
Author

NejcDolicanin commented Jun 10, 2022

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.

compile1

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

@sezero
Copy link
Owner

sezero commented Jun 10, 2022

Those line numbers don't make any sense..

@NejcDolicanin
Copy link
Author

NejcDolicanin commented Jun 10, 2022

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

@sezero
Copy link
Owner

sezero commented Jun 10, 2022

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

@sezero
Copy link
Owner

sezero commented Jun 10, 2022

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.

@sezero
Copy link
Owner

sezero commented Jun 10, 2022

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.

@NejcDolicanin
Copy link
Author

NejcDolicanin commented Jun 10, 2022

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.

@sezero
Copy link
Owner

sezero commented Jun 10, 2022

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?

@NejcDolicanin
Copy link
Author

NejcDolicanin commented Jun 10, 2022

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.

compile2

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

@NejcDolicanin
Copy link
Author

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?

@sezero
Copy link
Owner

sezero commented Jun 10, 2022

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

Which part of the code?

@NejcDolicanin
Copy link
Author

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

@sezero
Copy link
Owner

sezero commented Jul 23, 2022

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?

@NejcDolicanin
Copy link
Author

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants