Fortschritt Treiberentwicklung für moderne Betriebssysteme?

Und hier ist jetzt auch der Miniport Treiber (3dfxvsm.dll).

Ich habe jetzt verstanden, was der Unterschied zwischen dem Display-Treiber und dem Miniport-Treiber ist:

- Der Display-Treiber macht alles generische, z.B. Dreiecke zeichnen, Windows GDI usw.

- Der Miniport-Treiber macht alles hardwarespezifische, also die Speicherkonfiguration erkennen, erkennen, ob das Board FSAA kann.

Wenn man den Miniport Treiber neu kompilieren kann, macht das den Weg frei für eigene Hardware-Konfiguration. Eventuell könnte man den Treiber sogar für die Aalchemy-Boards portieren.

Ich habe die Treiber mal mit einer Voodoo3 auf Windows XP ausprobiert, sie funktionieren natürlich nicht (war aber auch zu erwarten). Hat jemand Erfahrungen, ob man Windows irgendwie beibringen kann, Logs von der Treiberinitialisierung zu speichern?
Das Thema wird ziemlich schnell sehr komplex. Ich werde mich vermutlich eher auf die Glide APIs beschränken, die sollten etwas einfacher zu debuggen sein.

Hallo allerseits! Eine lange Zeit habe ich mich nicht mehr mit dem 3dfx Treibern beschäftigt - ich habe Job und Wohnort gewechselt, und das hat viel Zeit verschlungen. Vor einigen Wochen habe ich mir allerdings ein Thinkpad 240 gekauft, und nachdem ich das BIOS-Passwort entfernt und Windows 98 installiert habe, habe ich mich mal wieder mit der Treiberentwicklung beschäftigt.

Auf einem Win9X mit den ganzen Tools von damals ist das Kompilieren erstaunlich einfach, die alten Compiler sind etwas toleranter was schlechten Programmierstil angeht, und die 16-bit Teile lassen sich auch relativ problemlos kompilieren.

Jedenfalls konte ich jetzt den 3dfx Treiber für die V4/v5 für Win9x kompilieren, allerdings habe ich kein 3dfx-System zum Testen. Würde sich jemand anbieten, diesen Treiber auszuprobieren?

Man müsste einen orginalen 3dfx-Treiber nehmen, die DLL and VXD durch meine Variante ersetzten, und den Treiber installieren.

Das ganze ist ohne Gewährleistung, es besteht ein Risiko, dass das System nicht mehr booted (man könnte die DLLs aber über DOS vermtlich wieder durch die original-Versionen ersetzen).

Unterstützt Windows Me noch die Vxd-Treiber? Dann müsste das gehen. Zur Installation den letzten offiziellen 3dfx Treiber installieren, aber vorher die DLLs durch meine austauschen. Neustarten und hoffen dass alles funktioniert!

Ich schreibe ab jetzt in Englisch - die 3dfx Treiberentwicklung-Community ist so klein, dass ich die Sprachbarrieren abbauen moechte. Sorry!

----
Some more updates on the driver development. So far, I used a Win9x system to compile the drivers, which sucks because most modern development tools are not available.

I therefore tried to see if it possible to make compilation of the driver on a modern system possible (WinNT 10.0 64x).

The latest (Microsoft) toolchain that can still target Windows 98/Win2k is Visual Studio 2005, so I worked on porting the Win2k driver to VS2005. This was surprisingly easy, with only a few minor changes. Since the 2K driver does not have any 16 bit components, it can be easily compiled on Windows 10. All you need to do is to install Visual Studio 2005, set the envvars correctly, and build it.

For the 9x driver, it is a bit more tricky: the 9x driver contains some 16bit components (the DD16 directory). Originally, Microsoft intended users to compile the 16bit part with Visual Studio 152 (released in 1996). Unfortunately, VS152 cannot run properly on Windows 10 (at least I was not successful in getting it to run. It threw some "out of memory" or "file not found" errors).

The current de-facto standard for cross-compiling DOS/16bit applications from a modern OS seems to be the OpenWatcom 2 compiler, which runs on Win 64, but can cross-compile to DOS/Win9X/Win3.x. This is great!

Unfortunately, this requires rewriting some of the assembly code. OpenWatcom does not support mixing C code with assembler very well, and parts of the assembler routines need to be adapted for OpenWatcom.

I am currently trying to use the OpenWatcom compiler, but the linker from Visual Studio 152. Not sure if this will work.

Why am I doing this?

I am still hoping to establish modern driver development with a community, i.e. having the driver on some GitHub/GitLab, and everyone who is interested in working with it can just do a Pull Request introduce code changes.

To make sure this works, the driver should be automatically built in the cloud: perhaps with using Windows docker containers, that run as a part of a GitHub action, install all dependencies, build the driver, and upload the compiled driver as artifacts to GitHub, from where you can download & test it. This is what I have in mind. Of course, there are no Win9x docker containers available, so everything must be compile-able from a modern OS.

I would like to make this a full open source, community-driven project. It is a shame that so many new/improved drivers were developed, but since they are all closed source, all the progress that has been made on the sources is basically lost. SFFT has built a new D3D implementation, some folks have worked on Widescreen support, countless bugfixes,etc, but none of the sources are available.

The main issues I see here are:

- Porting the driver so that it can be build on a modern platform (ongoing).

- Find a possibility to put the copyrighted source code under version control and public access. I am thinking of using a private Github repo, where only 3dfx community members get access to.

- Automatically testing the driver for each build (that would be a bit difficult to realize).

- Documentation: we need information how to build/install/test/debug the driver. Ideally, these documentation should also be hosted on Git., together with the source.