Hi OSH! This is a known issue. The solution is to use bash to run the sign_commit script, see here:

https://github.com/kjliew/qemu-3dfx/issues/14

Thanks mr. cat! I'll check this! Great to see you here!

Ok. QEMU compilation ended succesfully. But now I'm trying to compile guest wrappers and:

nemezis@nemezis:~$ cd ~/myqemu/qemu-3dfx/wrappers/3dfx
nemezis@nemezis:~/myqemu/qemu-3dfx/wrappers/3dfx$ mkdir build && cd build
nemezis@nemezis:~/myqemu/qemu-3dfx/wrappers/3dfx/build$ cp ../src/Makefile.in ./Makefile
nemezis@nemezis:~/myqemu/qemu-3dfx/wrappers/3dfx/build$ make && make clean
CC fxhook.o fxlib9x.o fxlibnt.o
../../fxlib/fxhook.c:2:10: fatal error: windows.h: Datei oder Verzeichnis nicht gefunden
2 | #include <windows.h>
| ^~~~~~~~~~~
compilation terminated.
make: *** [Makefile:63: fxlib] Fehler 1

I know, something is missing. But what?

i was coping makefile.in to all wrapper folders separately

@OSH: That sounds like you're missing some mingw-w64 bits (assuming you're doing this on Linux).
It seems windows.h is in package mingw-w64-i686-dev, but you may need something else too.
The original recipe that I used back in December (whew, time flies!) still applies.

One thing to note is that the makefiles make some MSYS2-centric assumptions that don't necessarily hold true in other systems such as Linux.
For example, in my system (LM20) if CC is defined as gcc that will simply point to the native gcc (and not the mingw-w64 version).
If you see error messages about windres or dlltool, you need to find where they reside on your system and edit the paths in the Makefile.
(Or if they're missing altogether, install them).

@robertmo: You're using this on Win10, right? It compiles there without any editing?

@mr.cat, after applying your instruction about modification makefile I got an error about windres… so I will try edit the paths…

mr.cat wrote on 2021-04-14, 18:35:

@robertmo: You're using this on Win10, right? It compiles there without any editing?

8.1 but not remember (i think some minor path correction somewhere) (i see folders were arranged a bit differently in the source when i did it)
there was also no fxhook.c in the source back then 😉

Ok, compiling Glide was successful. But now I'm trying compile MESA GL and:

CC fxlib9x.o fxlibnt.o
#@if [ "$MSYSTEM" != "MINGW32" ]; then echo "Error: MSYSTEM == $MSYSTEM"; exit 1; fi
CC szdata.o
#@if [ "$MSYSTEM" != "MINGW32" ]; then echo "Error: MSYSTEM == $MSYSTEM"; exit 1; fi
CC wrapgl32.o
REV stamp
CFLAGS -I../../../qemu-1/hw/mesa -I../../fxlib -Wall -Werror -msse2 -O3 -flto -fomit-frame-pointer
LDFLAGS -static-libgcc -Wl,--disable-auto-image-base -Wl,--dynamicbase -Wl,--nxcompat
LD opengl32.dll
/usr/bin/i686-w64-mingw32-ld: /tmp/opengl32.dll.eHGlFc.ltrans0.ltrans.o:<artificial>:(.text+0x5e40): undefined reference to `HookEntryHook'
/usr/bin/i686-w64-mingw32-ld: /tmp/opengl32.dll.eHGlFc.ltrans0.ltrans.o:<artificial>:(.text+0x5e5c): undefined reference to `HookEntryHook'
/usr/bin/i686-w64-mingw32-ld: /tmp/opengl32.dll.eHGlFc.ltrans0.ltrans.o:<artificial>:(.text+0x5e82): undefined reference to `HookEntryHook'
/usr/bin/i686-w64-mingw32-ld: /tmp/opengl32.dll.eHGlFc.ltrans0.ltrans.o:<artificial>:(.text+0xa726): undefined reference to `HookEntryHook'
/usr/bin/i686-w64-mingw32-ld: /tmp/opengl32.dll.eHGlFc.ltrans0.ltrans.o:<artificial>:(.text+0xb52a): undefined reference to `HookParseRange'
/usr/bin/i686-w64-mingw32-ld: /tmp/opengl32.dll.eHGlFc.ltrans0.ltrans.o:<artificial>:(.text+0xb59b): undefined reference to `HookTimeGetTime'
collect2: error: ld returned 1 exit status
make: *** [Makefile:24: opengl32.dll] Fehler 1

What is wrong this time? I modified Makefile.in like earlier. Then did the trick - now didn't...
System: Ubuntu 20.04

OK so the error message is clear enough: The linker can't find where these Hook* thingies reside. That usually means that some dev library is missing, or paths need to be added/fixed.
But in this case I couldn't find such things referenced in the source files. If you do some grepping (e.g. in the mesa directory) that might reveal their origin.
What does opengl32.def look like? That one's generated by pexport and subsequently linked with the rest of the files.

Actually, kjliew made some updates a couple of minutes ago, maybe that fixes it 😁

Oh, that's good, I'll check it evening!

Yeah, MESA compiled! Now it's time for installing Win98SE and games!!!

@mr. cat, I would to thank you for your help! This thread remains opened, because I want a discussion about development this brilliant thing!

OK, good to hear. And yes, you're welcome 😁
For w98 installation there is now this Wiki page, so you don't have to hunt down this information from past threads.

Yes, I discovered it earlier. 😀 Thanks anyway!

After start of QEMU I see:

nemezis@nemezis:~/myqemu/qemu-3dfx/build$ ./qemu-system-i386 -L pc-bios -rtc base=localtime -no-hpet -no-reboot -drive file=../vmimgs/w98.qcw -device VGA -M pc, -device ac97
audio: Failed to create voice `ac97.pi'
audio: Failed to create voice `ac97.mc'
audio: Failed to create voice `ac97.pi'
audio: Failed to create voice `ac97.mc'

So I need a SigmaTel C-Major Audio AC97 WDM driver. for Win98 I searched all Internet, but I can't download any! If someone has the right version, please give me an information!

meanwhile you can use (adapt to linux if needed)
-audiodev sdl,id=sdl,driver=sdl -machine pcspk-audiodev=sdl -device sb16,audiodev=sdl -device adlib,audiodev=sdl

http://www.vogonsdrivers.com/getfile.php?file … &menustate=38,0
http://www.vogonsdrivers.com/getfile.php?file … &menustate=38,0
http://www.vogonsdrivers.com/getfile.php?file … &menustate=38,0
http://www.vogonsdrivers.com/getfile.php?file … &menustate=38,0

SigmaTel C-Major Audio AC97 WDM driver 5.10.3696 for Win98/2000/ME/XP.

- INF patched for QEMU AC97
- SBPro emulation from Win98/ME DOS prompt.
- Daemon Tool 3.47 CD audio playback from CUE/BIN.

Hi kjliew, big thanks! But now I have another problem:

nemezis@nemezis:~/myqemu/qemu-3dfx/build$ ./qemu-system-i386 -L pc-bios \
> -rtc base=localtime -no-hpet -no-reboot \
> -drive file=../vmimgs/w98.qcw \
> -device VGA \
> -M pc -device ac97 \
> -netdev user,id=net0 -device rtl8139,netdev=net0
qemu-system-i386: Parameter 'type' expects a netdev backend type

if I delete the line: -netdev user,id=net0 -device rtl8139,netdev=net0
QEMU starts, but I think, this line is important?

Check your QEMU configure status page and look for "slirp" networking.
The slirp user networking is very useful for sharing files with the host, or join a network game 😉. This is the simplest and no-fuss networking setup for QEMU.

If you don't have "slirp" networking, then you need to install the dev package for libslirp.
Perhaps, you should do a "sudo apt-get build-dep qemu" before running configure. I am a bit rusty on ubuntu apt-get though ever since I moved to ArchLinux.

Ah, yes, now I understand. libslirp is installed, but I don't need a network under 98SE, so I can live without it. But anyway, I'll check this, thanks!

OSH wrote on 2021-04-17, 23:13:

... I don't need a network under 98SE, so I can live without it ...

You would think twice ... 😜

Even if you aren't gonna join network games, the accessibility of network between host and guest is very useful for other purposes, such as file transfer. You can also store all your ripped games CUE/BIN/ISO in the cloud and Daemon Tools just mounts the CD images from within VM on network shared drive. Life would be so much easier while laughing off "the other PC emulator" cumbersome ways of getting files in and out of emulated machine ... 🤣

In this day and age, it is just lame for any emulated/virtual machines without link between host and guest.

We'll see kjliew. I'm not very familiar with QEMU, I'm still learning. Now my goal is to play X-Wing with emulated 3D acceleration under QEMU. And I want make a donation for development support.