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

    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.

    We are using it to make a difference.

  • Hört sich interessant an. Ich hab nur kein Windows 10 System mit einer Voodoo. Hab eine Voodoo3 pci und ago rumliegen. Wo hast du koolsmokeys Code her? Dachte der ist nicht open?

  • Es macht in meinen Augen wenig Sinn eine Voodoo 3 in einem Ryzen-System zubetreiben. Welchen Grund soll es dafür geben?

    Die Eierlegendewollmilchsau ist nicht immer die ideale Konfiguration. Voodoo‘s gehören auf entsprechende Hardware ihrer Zeit! :adsh::topmodel:

    Permanent aufgebaut:
    A7V133, Athlon 1,4GHz, 512MB, GeForce3 Ti200 128MB, SB Live! X-Gamer
    Für die LAN:
    TUSL2-C, PIII-S 1,4GHz, 512MB, GeForce2 GTS 32MB, 2x Monster II 12M, SB Live!
    TUSL2-C, PIII-S 1,4GHz, 512MB, GeForce2 GTS 32MB, 2x Monster II 12M, SB Live!
    CUSL2-C, PIII 933MHz, 512MB, G400 Max 32MB AGP, 2x 3D Blaster Voodoo² 12MB, SB Live!
    CUSL2-C, PIII 933MHz, 512MB, G400 Max 32MB AGP, 2x Monster II 8MB, SB Live!

  • Also nen Threadripper und ne Voodoo 3 hätte schon etwas.

    Obwohl... Die Hardware ist so alt, die CPU könnte wahrscheinlich das ganze schneller emulieren, als die Voodoo es in Hardware rendern könnte.

    "Du bist und bleibst a Mensch und du kannst eben net deine menschlichkeit überwinden."

    Dennis_50300

  • Win2K pro & Win XP Pro are for me the best was Win98SE & WinMe are pure drama imo, Most of all I prefer Win2K Pro + SP4 the most, less strain on the CPU the Unofficial Service packs tend to break 98SE big time even tho I was never fond of that garage OS.

    From all the 3dfx prototypes I worked with Win2K Pro + SP4 USA gave me the best stable results.
    Everyone will always have their so called better experiences as I have mine.

    Even though it would differ per user a lot, also depending what games or programs you'd be running as well.

    Einmal editiert, zuletzt von Gold Leader (5. September 2021 um 00:59)

  • Bei Windows 10 stellt sich auch die Frage nach kompatibler Hardware, denn es setzt zwingend SSE2 und andere moderne Technologien voraus. Auf 20 Jahre alten Kisten ist das auch nicht angenehm.

    "Du bist und bleibst a Mensch und du kannst eben net deine menschlichkeit überwinden."

    Dennis_50300

  • 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!

    We are using it to make a difference.

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

    Code
    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

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

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

    Code
    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

    Code
    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.

    We are using it to make a difference.

  • Da gabs früher nen richtiges Softwarepaket von M$ für Treiberentwicklung (hieß afair Windows DDK).

    "Du bist und bleibst a Mensch und du kannst eben net deine menschlichkeit überwinden."

    Dennis_50300

  • 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?

    We are using it to make a difference.

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

    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.

  • Ich finde das ist ein echt klasse Projekt. Ich werde gerne deine Treiber testen. Bzw könnte dir sogar evlt Zugriff zu einem System mit V5 5500 und XP einrichten (hab momentan viel um die Ohren daher eher irgendwann)

    Kannst du die Treiber auch mit ziel 9x bauen?

    Ich weiss jetzt nicht wie gut die Treiber durchkommentiert sind. Evlt wäre das der nächste step damit man genau weiß was wo passiert.

  • 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.

    We are using it to make a difference.

  • 3dfxogl ist der OpenGL-ICD.

    Genau genommen ists nen Wrapper, wie du schon schriebst.

    Du hast das olle DDK noch gefunden? Cool.

    Wenn du den Treiber nachbaust, also quasi einen neuen mit dem alten Treiber als Vorbild schreibst, dan kannste den quelloffen machen.

    "Du bist und bleibst a Mensch und du kannst eben net deine menschlichkeit überwinden."

    Dennis_50300