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.

    We are using it to make a difference.

  • Ich denke dafür wird der Windows Debugger (Windbg) benutzt, der beherrscht auch Kernel-mode Debugging. Ich weiß nur nicht wo man eine alte Version für XP herbekommt. War das beim WDK dabei? Oder bei einer SDK? Das weiß ich leider nicht.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

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

  • Oh interessant - ich mache eine Datensicherung meines Testrigs und probiere es gerne mal aus.

    Muss ich da auf was bestimmtes achten?

    Richtige Installation mit Installer oder -

    einfach nur die Dateien auswechseln und den Treiber über den Gerätemanager manuell "aktualisieren"?

    Ich habe allerdings WinME darauf laufen - geht das?

    - Backfire -

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

    We are using it to make a difference.

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

    Ja! VxD gehen bis Windows ME. Ist ja zum Glück noch 9x Technologie.

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

    We are using it to make a difference.

  • They are available, Im just lazy and havent gotten around to uploading it, its on the to-do list :P. Also planed to document how I build stuff, but same problem, just havent done it so far. Ill do one newer mesa version, then get to this, at least the bare minimum.

    The "problem" is also testing if everyone pitches in a bit (no that theres a line of people willing to do so). Glide3 part of the driver is the one that got the most love and even that broke lots of things on win98 that are most likely just compiler related.

    Also everyone has its own idea whats needs doing, that part will get tested, with a high chance it break smthing else.

    If you read the history of commits, just for glide, some wanted to fix linux, some added 64bit support, lots of focus on winXp(makes sense at that time), some did general fixes, some did code cleanup, that effected the performance a bit. Whatever Koolsmoky pitched-in was amazing(not even kidding)... Its hard to maintain a project like that and guarantee everything will work.

    Look your workflow. You jumped in, did some playing around, life got in the way, now you wanna do some more. Thats probably how most (again not that big of a line of people waiting), including me, will approach it.

    Yea it all sounds great, have everything in a central repository, well documented and updated build procedures. But you have to be realistic here, the time investment required to do that. And someone dedicated to keep an eye what gets merged.