Fortschritt Treiberentwicklung für moderne Betriebssysteme?

Habt Ihr mehr Informationen, ob aktuell noch Leute an der Entwicklung von (modernen) Treibern für 3dfx-Karten arbeiten? Ich habe etwas Erfahrung in der Entwicklung von Treibern für ARM Systeme, habe aber noch nie mit x86 gearbeitet. Interessant wären für mich persönlich Treiber für Win10 x64, meinetwegen auch für Glide only. Einerseits hätte ich gerne wieder eine Voodo im PC, und für eine gelegentliche Runde UT wäre so eine funktionierende Voodoo2 auch ausreichend.

Ich habe die letzten Tage mal viel recherchiert und bin zu folgendem Schluss gekommen:

• Die gut funktionierenden Treiber von SFFT und Amigamerlin sind leider nicht Open-Source, eine weitere Entwicklung ist da wahrscheinlich nicht möglich.
• Die Treiber-Leaks von 3dfx, die wohl irgendwann mal 2002 aufgetaucht sind, sind für mich nahezu unbrauchbar. Die Toolchain ist sehr veraltet (MSVC6, DOS-Tools). Wahrscheinlich müsste ein großer Teil neu geschrieben werden.

Interessant sind wohl vor allem die Glide-Portierungen von Linux auf Windows. Dazu habe ich folgende gefunden:

1) https://github.com/sezero/glide -> das ist der Code der Glide API, der ursprünglich von 3dfx für Linux als OpenSource released worden ist, und später von Koolsmokey auf Windows portiert worden ist. Dieses Repo klingt für mich am vielversprechendesten, denn - kaum zu glauben - auf dem Repo gibt es hin und wieder noch Aktivität!

2) Der Source-Code von GlideXP (hier zu finden: http://wenchy.net/old/glidexp/). An dem wurde weniger modifiziert als am Koolsmokey Treiber Code, aber er scheint auch mit einer einigermaßen modernen Toolchain ausgerüstet zu sein.

Hat da schonmal jemand versucht durchzusteigen?

Welche Probleme sehe ich?

1. Einige Sektionen des Treibercodes sind in assembler geschrieben, der leider für die x86 Plattform entwickelt wurde. Für x64 Entwicklungen würde ich vorschlagen, diese Sektionen in C neuzuschreiben, und sich auf den Compiler zu verlassen.
2. Der 2D-Kern der Voodoos arbeitet mit GDI und DirectDraw, beides Sachen, die in modernen Betriebssystemen veraltet sind. Eventuell macht es gar keinen Sinn, den 2D Treiber zu portieren - falls es überhaupt geht?
3. Die Glide API sind die Treiberkomponenten im Userspace. Damit das alles funktioniert, braucht man einen Kernel-Treiber (dafür suche ich noch eine passende Implementierung).
4. Am einfachsten ist wohl die Entwicklung der Treiber für die Voodoo2, und nur für Glide.
5. Treiberentwicklung ist schwierig reinzukommen. Die Toolchain braucht lange zum Installieren, und die Tools sind veraltet. Die Entwicklungs-Infrastruktur müsste modernisiert werden (CMake, CI, eventuell sogar Docker?).
6. Der Code muss für moderne Compiler kompatibel gemacht werden.
7. Für mich persönlich ist ein großes Problem, Treiber zu debuggen und zu testen. Ich habe darin keinerlei Erfahrung drin. Ich kann den Treiber bauen, aber ob er funktioniert, ist eine andere Sache

Ich habe die letzten 15 Stunden den Code von dem Koolsmokey Treiber angeschaut, und habe es zumindest mal geschafft, die Glide API 3 für x64 zu bauen (Glide3x.dll, gebaut mit Visual Studio)! Yay! Den GlideXP Treiber habe ich auch mal kurz versucht, aber der Koolsmokey klang von der Codebasis vielversprechender.

Aktuell schaue ich mir vor allem Punkt 5 und 6 an, da ich dort die meiste Erfahrung habe. Falls jemand Lust hat mitzumachen, würde ich die modernisierten Build-Scripts und Cmake-Umgebung auf Github veröffentlichen. Wie gesagt ist Treiberentwicklung für Windows ein eher unbekanntes Thema für mich.

Please, let's not discuss which OS or platform is the most suitable for 3dfx cards. I am interested in this topic of Windows driver development, first, to get a better understanding on how Windows drivers are written, and second, to see if it is possible to move the driver code to a state of the art development environment. So let's stay on topic on how this driver works in detail, and if we can get it to compile, at at some point maybe even working.

Using a modern development environment does not necessarily mean that the newly generated drivers don't work on older OS. I am quite curious how the newly built drivers built with a modern GCC version compete with the original drivers, that were probably compiled with MSVC6.

For now, my goal is to modernize the environment, and get things compiling. The first thing I did I removed the makefiles (I don't like them), and replace it by one single cmake file. I also added a CI job to build the drivers automatically. The idea is that developers who wish to try out driver development don't have to bother about having all the correct tools installed, and don't have to build themselves. If you want to change the driver, you just add your new code, and the cloud takes care of building the driver. You add your code changes, and a few minutes later you can download the completed driver, and test it.

At least for the glide3x.dll for the Voodoo2, I completed this step by now. This CI job here https://github.com/Danaozhong/glide/actions/runs/1203009582 will automatically build the library for Wndows and Linux in both x86 and x64 variants. You can see the download link in the github page, where the generated libraries are located. They probably don't work, but now it should be a bit easier to introduce new code changes and testing them.

Even though I can build some of the libraries now, doesn't mean I understand how they are working. I would be more than happy to get some insights from someone who has some experience with 3dfx driver development!

Does anyone know where to get the kernel part of the 3dfx drivers? To explain this technically, a modern driver usually has two parts: the part in userspace runs with restrictions (e.g. no direct hardware access). this is the part the application using the driver talks to. In case of the 3dfx driver, this are the glide2x and glide3x.dlls.

To get a fully working driver, you also need to have the kernel part of the driver: this runs without restrictions in kernel space, and has direct access to hardware and memory mappings. The user space driver communicates to the kernel space part of the driver, which then does the actual work.

It seems to me that most drivers on the web only publish the user space part, not the kernel part. I would therefore be very interested in seeing an example of a kernel space driver for a Voodoo2, or perhaps others, for an NT based operating system.

For Win9x the things work differently, but I am not so much interested in building drivers for Win9x.

----

Well, for the glide user space drivers, I made some little progress and can compile both glide2 and glide3 now! Do you want to try it out yourself? It's quite fun to be able to build your own Glide libraries (even if they most likely don't work)!

I'll provide some basic instructions for the glide2x DLL for Voodoo2 below.

You basically need git, CMake, a C compiler (I tried both GCC and Visual Studio 2019), and, for 32bit builds, the assembler "NASM" installed.

Start by cloning https://github.com/Danaozhong/glide.

Next, you'll need to build a tool called "fxgasm". This fxgasm.exe is used to generate header files with memory locations, required by the actual driver compilation step later. Navigate to folder "glide2x\cvg\glide\src\fxgasm_tool", open a command prompt (e.g. CMD).

mkdir bin
cd bin
cmake ..

This creates a directory to store the compiled libraries ("bin"). This is called an out-of-source build, because the generated binaries are not stored together with the code, but in a separate folder.

The cmake call will tell cmake to use the CMakeList.txt in the folder above, and generate a visual studio solution out of it. If you would run this from e.g. Ubuntu, it would generate a makefile.

If everything worked well, CMAKE should find the compiler, and you can build the fxgasm tool by

cmake --build .

If that worked well, you have successfully built your first 3dfx software! search the directory for an executable called fxgasm.exe.

Generate the header files using FXgasm:

fxgasm_tool/bin/Debug/fxgasm.exe -inline > fxinline.h
fxgasm_tool/bin/Debug/fxgasm.exe -hex > fxgasm.h

The resulting fxinline.h and fxgasm.h should be located/copied in glide2x\cvg\glide\src directory.

Now, we can actually build the glide driver! Let's open a command promt in "glide2x\cvg". Same as before, let's start by generating an out of source directory, and invoke cmake:

mkdir bin
cd bin
cmake -G "Visual Studio 16 2019" -A Win32 -DBUILD_32BIT=ON ..

This calls cmake and specifies that you want to build with Visual Studio 2019, want a 32bit application ("-A Win32"), and specify some driver-internal switches for 32bit (BUILD_32BIT). This CMake step will now also search for you NASM assembler, so make sure it is available in the PATH envvar.

If cmake was successful, start the compile process by

cmake --build .

And after a few seconds you should receive your glide2x.dll, which is a 32bit DLL and should technically be useable on any 32bit NT-based OS. Since I have no idea how the kernel part of the driver looks like and many people have modified things in the glide libraries, the chances of them working are very, very slim.

The next step would now be to use e.g. an XP OS, put a Voodoo2 in it, try these libraries out, find out when / why they crash with a debugger, understand the problem, solve the problems in the code, and repeat.

Nachdem die Glide APIs sich jetzt kompilieren lassen, wollte ich mal den V4/V5 Display-Treiber neu kompilieren. Dafür braucht man das DirectX 8 SDK, Dateiname "dx8sdk.exe", oder "dxsdk_aug08.exe". Leider habe ich das im Internet nicht mehr finden können. Hat das vielleicht jemand auf seinem PC?

Cool! Genau das habe ich gesucht! Danke!

So.... nach mehreren Stunden Arbeit ist der Windows XP Treiber jetzt durchkompiliert. Theoretisch sollte der Treiber unter Windows XP mit DirectX8 Support und auf V3/V4/V5 laufen.

Praktisch ist der Code irgendwie mit Klebeband zusammengewickelt, und wird zu 99% nicht funktionieren. Außerdem habe ich gerade kein XP Voodoo-System parat. Will ihn jemand mal ausprobieren? Ich würde im abgesicherten Modus starten, die alte 3dfvs.dll sichern, und durch meine Variante ersetzen. Am besten nicht auf einem besonders wichtigen System ausprobieren, falls der Treiber komplett Amok laufen sollte.

Ich habe den originalen 3dfx-Win2000-Treiber genommen, auf Cmake portiert, und mit den Windows XP Libs aus dem Windows Driver Kit kompiliert. Das ging zu 99% auch gut. Meine Toolchain ist Windows 10, MSVC2019, DX81SDK, Windows DDK für Windows Server 2003 Service Pack 1 (SP1)

Wie funktioniert der Treiber im Detail?

- 3dfxvs.dll ist der 2D / Direct3D / DirectDraw Teil. Dieser macht alles was irgendwie mit Windows zu tun hat.

- 3dfxvsm.dll ist irgendein Miniport Treiber - ich habe keine Ahnung was der macht.

- glide2x.dll, glide3x.dll sind die Glide Treiber. Diese sind ziemlich unabhängig von dem Hauptteil des Treibers. Ich vermute, das liegt daran, dass 3dfx anfänglich hauptsächlich Glide entwickelt hat.

- 3dfxogl.dll ist (vermutlich) der OpenGL auf Glide Wrapper.

Ich möchte meine Änderungen gerne open-source machen, falls jemand Interesse an dem Projekt hat, und eigene Treiber bauen will. Allerdings sind die 3dfx-Treiber offiziell nach wie vor closed-source, und jeder Dateiheader fängt in etwa so an:

/*
** Copyright (c) 1995-1999, 3Dfx Interactive, Inc.
** All Rights Reserved.
**
** This is UNPUBLISHED PROPRIETARY SOURCE CODE of 3Dfx Interactive, Inc.;
** the contents of this file may not be disclosed to third parties, copied or
** duplicated in any form, in whole or in part, without the prior written
** permission of 3Dfx Interactive, Inc.
**
** RESTRICTED RIGHTS LEGEND:
** Use, duplication or disclosure by the Government is subject to restrictions
** as set forth in subdivision (c)(1)(ii) of the Rights in Technical Data
** and Computer Software clause at DFARS 252.227-7013, and/or in similar or
** successor clauses in the FAR, DOD or NASA FAR Supplement. Unpublished  -
** rights reserved under the Copyright Laws of the United States.
**/

Ich glaube nicht, dass ich den Treiber einfach auf Github hochladen kann.

Eine Idee wäre, nur meine Änderungen auf Github zu laden, und den Treibercode mittels Script aus den Weiten des Internets zu laden, die Änderungen anzuwenden, und dann den Bauprozess zu starten.
Es wäre halt schon cool wenn man irgendwo in der Cloud eine Buildumgebung hat, sodass jede Codeänderung automatisch diese Umgebung antriggert, und am Ende ein fertiger Treiber herauspurzelt.

Normalerweise machst Du die detaillierte Doku über Git - jeder Git Commit enthält einen Satz Änderungen (die z.T. mehrere Dateien umfassen), und kannst das schön dokumentieren, was wo passiert. Daher auch meine Vorliebe für Github.

Die 9x Treiber sind nochmal stark anders, kann man aber auch auf die Zielliste aufnehmen.