Hi!
Für ein altes Programm benötige ich die OpenGL.dll (NICHT diese komische HFX Engine die man mit Google nur findet).
Der Download von ftp://ftp.microsoft.com/Softlib/MSLFILES/Opengl95.exe schlägt immer fehl (!?)... hat jemand noch diese alte Version von OpenGL? Die Datei heisst opengl.dll und müsste in %windir%/system32 rumfliegen...
Danke!

Hmmm? Normalerweise sollte ein Grafikkartentreiber auch eine opengl.dll mitliefern, die alte Versionen unterstützt. Hast du denn einen aktuellen Grafikkartentreiber für deine Karte installiert? Oder es mal mit einem älteren probiert?

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Könntest du genau erklären was dein Problem ist.
OpenGL ist bis Version 2.x abwärtskompatibel, d.h. neuere Treiber unterstützen auch die alten Funktionen.

Was ein Problem sein könnte, ist wenn das besagte Programm alte Extensions (ARB, ATI, NVIDIA etc) benutzt. Da weiß ich nicht, ob die in späteren Versionen noch vorhanden sind, wenn die Funktionalität in den Kern aufgenommen wurde.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Diese OpenGL95.exe ist OpenGL für Windows 95. Das gab es früher als extra Download um OpenGL für Windows 95 nachträglich einzurichten. Ab Windows 98 war OpenGL standardmäßig mit an Bord. Und dort heißt die DLL OpenGL32.dll. In der OpenGL32.dll ist per default auch bereits OpenGL 1.1 implementiert. Halt alles per Software und nur sofern kein echter Treiber gefunden wurde. Ansonsten wird auf den zugegriffen. Die OpenGL.dll arbeitet dort glaube ich nur so, dass sie alle Funktionen per Software implementiert.

Sofern du das Programm beeinflussen kannst, dann solltest du das auch tun und auf die OpenGL32.dll umsteigen. Falls du auf das Programm keinen Einfluss nehmen kannst könnte es auch ausreichen, wenn du die OpenGL32.dll kopierst und sie OpenGL.dll benennst. Würde ich dann aber lokal im Verzeichniss dieser Anwendung (wo sich die exe befindet) machen. Das könnte funktionieren.

Das Programm kann ich nicht beeinflussen.
Ich habe eine opengl.dll, die liegt aber nur als 64-Bit-Binary vor. Wenn ich die 32-Bit-Opengl32.dll kopiere und entsprechend umbennene, dann kann der PE-Loader die Funktion ChoosePixelFormat nicht finden, denn die heisst ja in den neueren openGL Versionen auch wglChoosePixelFormat.
Daher das Problem

Vielleicht Windows 95 oder 98 in einer VM installieren und dort probieren? Performance sollte bei einem derart alten Programm ja weniger das Problem sein.

_________________
Yeah!

VM geht nicht, weil das Programm weitergegeben werden soll. Und da wirds schwierig, weil nicht jeder hier ne VM einrichten kann. Eigentlich nur ich
Und da heisst es immer, dass das Internet nichts vergisst. Und da kriegt man nach 10 Jahren nicht mal mehr OGL 1.2

Wenn du eine Installation von Win98 hast, dann sollte es doch reichen, wenn du die dortige DLL kopierst und mitlieferst, oder?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Es ist gut möglich das die DLL unter aktuellen Betriebssystemen nicht mehr läuft, insbesondere wenn es ein 64bit System. 64bit dürfte langsam auch in der Windows-Welt zum Standard werden. Deswegen ja der Vorschlag mit der VM. Windows7 hat nicht ohne Grund eine VM mit WinXP eingebaut...

_________________
Yeah!

Ja aber VM fällt weg, weil das Programm weiter gegeben werden soll. Eine VM wäre da äußerst unpraktisch.

Ich würde sagen. csderats du stehst da auf verlohrenem Posten. Das Einzige was mir dort noch einfallen würde, wäre eine wrapper DLL. Das ist aber nicht wenig arbeit. Entsprechend muss es das Programm auch wert sein.

Wie genau mein Vorschlag aussehen würde. Du erstellst eine DLL die opengl.dll heißt und genau die erwarteten Methoden exportiert. Diese Methoden rufen dann das entsprechende Gegestück aus der OpenGL32.dll auf. Welche Methoden du benötigst musst du entweder Ausprobieren oder du schaust dir deine Anwendung mal mit dem "Dependency Walker" an. Der sollte in der Lage sein die benutzten DLLs und die benutzten Methoden anzuzeigen. Dann musst du nicht alle Importieren sondern nur die die deine Anwendung benutzt. Solch eine DLL kannst du dann zu der Anwendung mit dazu packen und es sollte von diesem Punkt, dann aktuell keine Probleme mehr geben.

Mit DW hatte ich es schon recht früh probiert. Eigentlich müsste man nur die Namen der Exportierten Funktionen (wgl* in *) ändern, allerdings scheint es dafür kein Programm zu geben, obwohl das ja nur eine recht kleine Änderung in der PE-Exports-Tabelle ist.
Denn die paar, die ich inzwischen ausprobiert habe, konnten der Funktionen höchstens einen Alias Namen geben, der aber vom PE-Loader nicht beachtet wird.

/EDIT:
Mit dem CFF Explorer (warum bin ich nicht gleich drauf gekommen, schliesslich gammelt der schon seit ein paar Monaten im Kontextmenü rum) kann man die Exporttable editieren. Aber irgendwie widerspricht sich der PE-Loader selbst, kann es sein, dass DLLs intern gecacht werden?

Also ich habe nicht davon geredet, dass du in der Anwendung rumschreiben sollst. Wer weiß genau was so etwas für spätfolgen haben kann. Meine Idee war eine DLL zu schreiben die als Bindegleid dazwischen fungieren soll.

Naja offenbar hat sich die API ja nicht geändert, sondern nur die Funktionsnamen in der OpenGL[32].dll. Da waren offenbar vor OpenGL 1.5 oder 2.0 die jetzigen WGL-Funktionen noch ohne Präfix...

Na ja. Die wgl Funktionen sind eigentlich Bestandteil von Windows. In diesem Falle sogar grundlegend zum Erstellen eines Kontextes. Falls das funktioniert die zu ändern mag das okay sein. Wobei mir bei so etwas ein kalter Schauer über den Rücken läuft.

Die Funktionen, die für andere Programme sichtbar sind werden in einer Tabelle gespeichert, die eben aus Name, Ordinal (Ordnungsnummer) und Offset besteht. Wenn man den Namen ändert, hat das sonst keine Auswirkungen, denn das merkt die Bibliothek nichtmal selber, da die eigenen Funktionen übers Offset angesprochen werden.