empfohlen, den KE5FX-Toolkit zu benutzen, um einen HP-GL-Plotter zu emulieren. Im Prinzip läuft der Toolkit unter Wine, aber ich komme mit der Konfiguration des COM-Ports dort nicht klar.
Ich habe Wine so konfiguriert, dass es das CDC-Device des AR488 als COM5 mappt (da es nicht gleich klappte, sowohl per Eintrag HKLM\Sofware\Wine\Ports über winereg als auch per Symlink in ~/.wine/dosdevices).
Wenn ich PuTTY darauf loslasse, kann ich mich mit COM5 verbinden und ++ver zeigt mir den Versionsstring des AR488 an.
Der KE5FX-Toolkit findet aber nichts. Wenn ich prologix.exe aufrufe, sehe ich keine Geräte zur Auswahl. Ich editiere da drin das connect.ini und trage ein
The GPIB Toolkit is provided with full C++ source code for public-
and private-sector, educational and Amateur Radio / hobbyist use.
(Aus irgendeinem Grund aber hinter so einem beknackten Exe-Installer versteckt)
... Oh. Ach Du Scheiße. Der packt den Sourcecode nach "c:\program files"
Das ist derb.
Oh, und der Sourcecode ist ... hässlich. Ich hab' ja schon wirklich hässliches Windows-Gefrickel gesehen, aber das hier ist schon sehr speziell.
Fängt schon mit den benutzerdefinierten Typen an, und dann wird auf die "ini-Datei" nicht mit den dafür vorgesehenen Funktionen (GetPrivateProfile-Etcetera) zugegriffen, sondern mit einem irgendwie selbstgefrickelten Parser.
Und die serielle Schnittstelle .. wird mit BuildCommDCB angesteuert. Daß jemand diese Funktion verwendet, habe ich zuletzt irgendwann in den frühen 90ern gesehen, als ich noch mit 16-Bit-Windows unterwegs war.
Der String in der sogenannten "Ini-Datei" wird direkt dieser Funktion übergeben:
Hmm. Ganz dumme Frage: Hast Du beim Bearbeiten der Datei daran gedacht, daß unter Windows CRLF als Zeilentrenner verwendet wird, und manche Software da sehr penibel ist? Ich nehme an, daß Du einfach irgendeinen Texteditor verwendet hast, und vermutlich nutzt der einen anderen Zeilentrenner ...
Hast du mal versucht einen simplen seriell-USB Adapter mit dem Tool zu öffnen? Oder evtl. hast du einen native seriellen Port den du in wine mappen kannst. Nur um zu sehen ob es grundsätzlich geht.
Aber wenn die SW schon so gruselig ist, vielleicht nimmt sie auch einen speziellen Weg um serielle Schnittstellen zu nutzen. Und der klappt mit wine nicht.
Ob das auch das Problem unter Wine ist kann ich nicht sagen, ich habe den Adpater aus der Sammelbestellung noch nicht mit dem KE5FX-Toolkit ausprobiert.
Aber wenn die SW schon so gruselig ist, vielleicht nimmt sie auch einen
speziellen Weg um serielle Schnittstellen zu nutzen. Und der klappt mit
wine nicht.
Ich könnte die Soße morgen mal nebenbei meinem Compiler vorwerfen und sehen, was das Zeug so macht, vielleicht ist ja die Fehlerbehandlung ähnlich, ähm, "ausführlich" wie der Sourcecode lesbar.
Das aber würde ich nur tun, um Jörg einen Gefallen zu machen.
Falls sich jemand das ansehen will, ich hab' den Sourcecode (bis auf die diversen Ressourcen-Dateien) mal extrahiert und hier angehängt.
Allerdings hab' ich keinen GPIB-Adapter, kann das also funktional nicht testen.
Und die serielle Schnittstelle .. wird mit BuildCommDCB angesteuert. Daß
jemand diese Funktion verwendet, habe ich zuletzt irgendwann in den
frühen 90ern gesehen, als ich noch mit 16-Bit-Windows unterwegs war.
Nur zur Klarstellung: Der kostenlose KE5FX GPIB Toolkit, den man mit Source Code bekommt, arbeitet unter Windows problemlos mit sehr vielen unterschiedlichen GPIB Adaptern und macht einige Dinge, die man sonst nirgends oder nur gegen sehr gute Bezahlung bekommt.
Aber es gibt halt auch ganz schlaue Schwätzer die nur eines gut können: schlau daher reden.
Ach ja, mit dem Source Code kommt man ebenfalls gut klar, zumindest wenn man mehr kann als nur schlau daher reden.
The GPIB Toolkit is provided with full C++ source code for public-
and private-sector, educational and Amateur Radio / hobbyist use.
(Aus irgendeinem Grund aber hinter so einem beknackten Exe-Installer
versteckt)
yup
Aber zumindest hat der erstmal funktioniert.
... Oh. Ach Du Scheiße. Der packt den Sourcecode nach "c:\program files"
Ja, gleich neben die Executables.
Fängt schon mit den benutzerdefinierten Typen an, und dann wird auf die
"ini-Datei" nicht mit den dafür vorgesehenen Funktionen
(GetPrivateProfile-Etcetera) zugegriffen, sondern mit einem irgendwie
selbstgefrickelten Parser.
Scheint mir alles sehr, naja, "historisch gewachsen".
Und die serielle Schnittstelle .. wird mit BuildCommDCB angesteuert.
An welcher Stelle eigentlich? Die habe ich noch nicht gefunden.
Daß
jemand diese Funktion verwendet, habe ich zuletzt irgendwann in den
frühen 90ern gesehen, als ich noch mit 16-Bit-Windows unterwegs war.
Wenn man sieht, dass noch irgendwelche Workarounds für Win98SE drin sind, aus der Zeit wird der Code stammen.
enumerate_ports() in prologix.cpp geht irgendwie über SetupDiClassGuidsFromNameA(). Ich würde mir ja mal ausgeben lassen, was dort unter Wine alles so gefunden wird, aber ich habe keinen Windows-Cross-Compiler zur Hand. Der FreeBSD-Port für mingw32-gcc wurde vor einiger Zeit eingestampft, weil das MinGW32-Projekt tot ist, einen anderen habe ich aber auch nicht.
Hmm. Ganz dumme Frage: Hast Du beim Bearbeiten der Datei daran gedacht,
daß unter Windows CRLF als Zeilentrenner verwendet wird, und manche
Software da sehr penibel ist?
Da ich gar nicht gewusst hätte, wo die Datei zu finden ist, habe ich die dort eingebaute Funktion zum Editieren der Datei aufgerufen. Diese wiederum startet ein notepad.exe. Daran sollte es also nicht liegen …
Es gibt wohl Probleme weil sich zumindest der original AR488 nicht
vollkommen identisch wie der Prologix verhält,
Hans' AR488 nutzt ja eine CDC, die sowieso die Signale nur emuliert. Es sieht so aus, als würde die CDC tatsächlich kein CTS (virtuell) anlegen. Wenn ich auf dem Host mit Kermit drauf gehe und mir den Status anzeigen lasse, bekomme ich:
Der kostenlose KE5FX GPIB Toolkit, den man mit Source Code bekommt,
arbeitet unter Windows problemlos mit sehr vielen unterschiedlichen GPIB
Adaptern und macht einige Dinge, die man sonst nirgends oder nur gegen
sehr gute Bezahlung bekommt.
Das mag ja sein, aber im vorliegenden Fall funktioniert er erstmal schlicht nicht, und es ist noch nicht völlig klar, woran das liegt. (Es gibt ja auch noch niemanden, der besagten AR488 native unter Windows damit zum Laufen bekommen hat.)
"kostenlos" als Qualitätskriterium zu deklarieren, ist ohnehin nicht sinnvoll, und dass man den Sourcecode direkt neben die Executables legt ist, naja, nennen wir es mal "unorthodox".
Das könnte auf das oben genannte Problem mit CTS deuten. Vielleicht
müsst man das Ganze nur mal recompilieren mit
Es muss nichts neu kompiliert werden, es reicht wenn man mit "++id verstr" den AR488 Version String setzt. Da prologix.cpp "Version x.x" erwartet (das V zählt nicht), der Adapter aber "ver. x.x" schickt klappt es nicht. Mit der Versionsnummer muss man eventuell experimentieren weil diese die Features festlegt. Zumindest funktioniert dann die Erkennung des Adapters unter Windows.
Übrigens, Deine Einstellung auch noch Erwartungen an kostenlose Software, die mit Source Code kommt, zu stellen finde ich schon sehr seltsam. "Früher" hieß es mal "nimm den Source Code und mach es selber wenn Dir was nicht passt" aber so ändern sich die Zeiten...
Kurzer Nachtrag zu weiter oben: Es ist die Datei "gpiblib\gpiblib.cpp", die den Versionsstring auswertet, nicht prologix.cpp.
"++id verstr Version 4.0" ist die Einstellung für einen möglichen Versionsstring der funktioniert, aber wie schon geschrieben, anhand der Versionsnummer werden die Features des Adapters festgelegt, das müßte man sich eventuell noch genauer ansehen.
... Oh. Ach Du Scheiße. Der packt den Sourcecode nach "c:\program files"
Das ist derb.
Oh, und der Sourcecode ist ... hässlich.
Ich fand dazu in den FAQ von KE5FX diesen Kommentar:
It's important to note that each of these tools was written -- usually in a hurry -- in response to a need I've encountered in my own work. They're not meant to be polished commercial-quality applications, and they often play fast and loose with current best practices in professional Windows development.
"Früher" hieß es mal "nimm den Source Code und mach es selber wenn Dir
was nicht passt"
Würde ich ja tun, wenn es denn so einfach wäre.
Da ich kein Windows habe, muss ich leider erstmal gucken, wie ich einen Crosscompiler dafür zum Laufen bekomme. Hatte jetzt den Tipp bekommen, MinGW64 unter Wine zu installieren, mal gucken.
Das mit der Versionsnummer werde ich mal probieren, ich habe nur den Eindruck, dass die KE5FX-Tools bislang noch gar nicht mit der Schnittstelle überhaupt reden. Da kann ich mich natürlich auch täuschen.
Das mit der Versionsnummer werde ich mal probieren, ich habe nur den
Eindruck, dass die KE5FX-Tools bislang noch gar nicht mit der
Schnittstelle überhaupt reden. Da kann ich mich natürlich auch täuschen.
Zwei Screenshots von prologix.exe unter Windows, einmal ohne Anpassung der Version (AR488_original_Version.PNG) das andere mal mit Anpassung (AR488_Version_4_0.PNG). Wenn die Kommunikation passt wird immer etwas angezeigt, auch wenn der Adapter nicht erkannt wird.
"GPIB0" im Screenshot ist eine GPIB Karte, "COM1" die serielle Schnittstelle des PC, die werden also bei Dir nicht zu sehen sein und COM215 mit dem AR488 heißt sicher anders.
Bei mir ist da schlicht gar nichts zu sehen, auch keine Standard-COM1 (die per Default auf die serielle Hardware-Schnittstelle des PCs gezeigt hatte).
Ob das nun an Wine liegt oder an den KE5FX-Tools, wird man wohl nur durch weitere Tests finden können. Erstmal brauche ich dafür einen Crosscompiler. Wie oben geschrieben, PuTTY kann unter Wine drauf zugreifen, also ist nicht so, dass es grundsätzlich gar nicht geht.
Unter wine könntest du putty nutzen und den Adapter testen. Hab ich gerade gemacht. Ich habe den GPIB-Adapter angeschlossen, dass device ttyACM0 wurde automatisch auf com35 gemappt.
Bei putty hab ich nur die Baudrate von 9600 auf 115200 gesetzt was wahrscheinlich nicht nötig ist. Und ich habe com35 als serial line eingetragen und auf Open geklickt. Dann konnte ich mit dem Adapter reden.
Also ich habe die Adresse mit ++addr abgefragt, dann geändert und wieder abgefragt. Hat funktioniert.
++ver ergab: "AR488 GPIB controller, ver. 0.49.4, 02/03/2021".
putty version ist 0.74.
Damit wäre dann erstmal sichergestellt das der Port mit dem Adapter unter wine grundsätzlich funktioniert.
Oder du weißt das schon, was ich aber nicht rauslesen konnte ;)
Bei mir ist da schlicht gar nichts zu sehen, auch keine Standard-COM1
(die per Default auf die serielle Hardware-Schnittstelle des PCs gezeigt
hatte).
Eventuell liegt es nur daran wie prologix.exe die verfügbaren COM Ports ermittelt. Aber man kommt auch ohne prologix.exe aus, man kann ja connect.ini auch per Hand editieren.
Wenn in connect.ini der richtige COM Port eingetragen ist, also z.B. so passend zu den Screenshots weiter oben:
Menü "Acquire" - "Wait for device-initiated plot" auswählen
geht das schief weil die Schnittstelle nicht erkannt wird kommt eine Fehlermeldung:
1
---------------------------
2
CreateFile error: Port unavailable or in use
3
---------------------------
4
Das System kann die angegebene Datei nicht finden.
geht das schief weil die Kommunikation über die Schnittstelle mit dem Adapter nicht funktioniert kommt eine Fehlermeldung:
1
---------------------------
2
GPIB Error
3
---------------------------
4
Read error: 0x2
5
(Communications error)
ist der COM Port verfügbar und die Kommunikation funktioniert halbwegs sieht es so wie im Screenshot aus.
Das ist erstmal nur ein Test ob der GPIB Toolkit die serielle Schnittstelle sieht und der Adapter irgendwas bei "++ver" zurückschickt, die Version ist hier egal.
Eventuell liegt es nur daran wie prologix.exe die verfügbaren COM Ports
ermittelt. Aber man kommt auch ohne prologix.exe aus, man kann ja
connect.ini auch per Hand editieren.
connect.ini lässt sich ja über prologix.exe (und dessen Aufruf von notepad) editieren, das ist bereits erfolgt.
7470.exe starten
Menü "Acquire" - "Wait for device-initiated plot" auswählen
An der Stelle passiert schlicht nichts. Kein Fehler, gar nichts.
An der Stelle passiert schlicht nichts. Kein Fehler, gar nichts.
Mach doch mal den Vergleich was passiert wenn ein nicht vorhandener COM Port eingestellt ist und, falls das möglich ist, ein COM Port auf dem nichts zurück kommt wenn man etwas schickt. Das Ganze nur um sicher zu sein dass diese Zustände erkannt werden.
Alternativ, kannst Du unter Wine sehen was auf der seriellen Schnittstelle passiert? Es müßten folgende Kommandos zu sehen sein:
Alternativ, kannst Du unter Wine sehen was auf der seriellen
Schnittstelle passiert?
So richtig nicht bzw. ich weiß nicht wie.
Ein syscall tracer zeigt mir erstmal nichts in Richtung meiner Schnittstelle. Allerdings ist mir die Architektur von Wine auch nicht komplett klar. Es könnte sein, dass das über den wineserver läuft und ich den noch nicht getracet habe.
Eventuell zwei "USB auf Seriell" (RS232 oder UART) Adapter, beide verbinden (Nullmodem), einen nach Wine durchreichen, den zweiten unter Linux mit einem Terminalprogramm beobachten. Da es fast nur lesbare Texte bei den Kommandos sind sollte das eigentlich ausreichen.
Da Hans' AR488-Nachbau ein CDC benutzt, helfen die dortigen Workarounds nicht. Wenn, dann müsste man die Steuersignale auf CDC-Ebene anders emulieren. Diskussion dazu gibt's im AR488-Thread. Aber ich bin noch nicht völlig davon überzeugt, dass es das bringt. Ich denke immer noch, das KE5FX irgendwas mit den seriellen Schnittstellen drastisch anders macht als andere (wie beispielsweise PuTTY), und dass es deshalb unter Wine nicht richtig geht.
Aber erstmal brauch ich dafür einen Compiler, um auch mal Debugausgaben in den Code einbauen zu können.
Ich habe mir die KE5FX Tools auch eben unter wine installiert.
Ist hier auch so, es werden keine seriellen ports aufgelistet während putty funktioniert.
Ich denke immer noch, das KE5FX irgendwas mit den seriellen Schnittstellen
drastisch anders macht als andere (wie beispielsweise PuTTY), und dass es
deshalb unter Wine nicht richtig geht.
Ich gehe stark davon aus dass lediglich das Enumerieren der COM Ports in prologix.cpp ungewöhnlich ist und dieses Tool ist nur für das einfache Konfigurieren zuständig. Daher auch der Vorschlag weiter oben mit 7470.exe ohne das Enumerieren der COM Ports.
Die Kommunikation in comport.cpp ist eigentlich Standard und dieser Teil wird für die restlichen Tools verwendet (wenn per COM Port kommuniziert wird).
Aber erstmal brauch ich dafür einen Compiler, um auch mal Debugausgaben
in den Code einbauen zu können.
Geht unter Windows problemlos mit der Microsoft Visual Studio IDE, selbst mit ziemlich alten Versionen.
"Früher" hieß es mal "nimm den Source Code und mach es selber wenn Dir
was nicht passt"
Würde ich ja tun, wenn es denn so einfach wäre.
OK, dank eines Tipps aus den FreeBSD-Foren habe ich jetzt mingw64 unter Wine installiert. Damit lässt sich zumindest prologix.cpp compilieren, wenngleich auch mit 151 Warnungen (insbesondere darüber, dass man eine String-Konstante nicht zu C8* wandeln darf).
Das sollte erstmal als Basis genügen, um da ein paar Debug-Zeilen einbauen zu können.
Welches "make" würde man nehmen, das mit dem mitgelieferten makefile zurecht kommnt?
Ich glaube, die will ich mir unter Wine nicht auch noch antun, wenn sie
denn überhaupt installieren würde.
Eventuell mit ein wenig Anpassung am Makefile würde es relativ sicher auch mit den uralt Windows DDKs funktionieren. Das waren "damals" nur die Commandline Tools ohne die IDE mit überschaubarer Größe und obwohl es "Driver Development Kit" heißt kann man damit auch andere Windows Komponenten entwickeln (den Windows SDK gab es ja ebenfalls).
würde es relativ sicher
auch mit den uralt Windows DDKs funktionieren.
Äh, nein. Das DDK ist das "Driver Development Kit", das benutzt(e) man, um Devicetreiber zu erzeugen. Falsche Baustelle, Du meinst das SDK, aber das enthält schon lange keinen Kommandozeilencompiler mehr.
Äh, nein. Das DDK ist das "Driver Development Kit", das benutzt(e) man,
um Devicetreiber zu erzeugen. Falsche Baustelle, Du meinst das SDK, aber
das enthält schon lange keinen Kommandozeilencompiler mehr.
Du bist so schlau, schrieb ich ja schon weiter oben.
Ich habe mich auf "uralt Windows DDKs" bezogen, dazu Zitat aus "relnote.htm" zu "Windows Server 2003 Service Pack 1 (SP1) - Driver Development Kit (DDK)":
"The Microsoft® Windows® DDK ships a complete set of tools for building drivers. These tools have been upgraded from those released with the Windows XP DDK. As in the Windows XP DDK, Microsoft Visual C++® is no longer required to be installed.
Use the included tools for all Windows Server™ 2003, Windows XP, and Windows 2000, drivers. This version of the DDK does not support building drivers using a version of Visual C++ other than the one supplied with the DDK."
"The Microsoft® Windows® DDK ships a complete set of tools for building
drivers.
Hier geht es aber darum eine Anwendug zu debuggen das ist etwas ganz anderes. Hast du schon mal einen Treiber geschrieben und mit diesen Tools gearbeitet ?
Habe jetzt die virtuelle Disk in meiner Windows-VM vergrößert, um den Studio-Kram da mal reinzupopeln. Eigentlich bräuchte ich ja nur mal ein nmake.exe, aber das gibt's nicht mehr einfach so, ohne dass man viele Gigabyte and Rundherum mit installiert.
Habe jetzt die virtuelle Disk in meiner Windows-VM vergrößert, um den
Studio-Kram da mal reinzupopeln.
Grummel, geht nicht.
"Bevor wir loslegen
Sie sind nicht mit dem Internet verbunden."
Quark, natürlich kann die VM ins Netz, alle anderen Anwendungen außer diesem *** Installer haben kein Problem damit. (Der Installer hatte ja zuvor auch schon Kram runter geladen, nur dann musste ich die VM nochmal runterfahren, um die virtuelle Disk zu vergrößern.)
Da werde ich wohl auf nmake.exe verzichten und das Makefile für ein anderes make umbauen.
Damit lässt sich zumindest prologix.cpp compilieren,
wenngleich auch mit 151 Warnungen (insbesondere darüber, dass man eine
String-Konstante nicht zu C8* wandeln darf).
Sind halt nicht nur Warnungen, sondern auch errors:
1
prologix.cpp: In function 'void show_last_error(C8*, ...)':
2
prologix.cpp:645:22: error: invalid conversion from 'const void*' to 'LPVOID' {aka 'void*'} [-fpermissive]
3
645 | LPVOID lpMsgBuf = "Hosed"; // Default message for Win9x (FormatMessage() is NT-only)
Vielleicht gibt Dir die Anlage Inspiration - ist alt, aber ich finde z.B. die Aussage zu "Leerzeichen in Pfadnamen" (wenn ich Deine Pfadnamen mit Punkten so betrachte) ganz interessant.
Hier geht es aber darum eine Anwendug zu debuggen das ist etwas ganz
anderes. Hast du schon mal einen Treiber geschrieben und mit diesen
Tools gearbeitet ?
Schon wieder ein ganz Schlauer. Es wurde eine Build-Umgebung gesucht, um den Source Code des KE5FX GPIB Toolkit zu übersetzen. Ich habe die alten Windows DDKs deshalb empfohlen weil da alles nötige enthalten ist (und nur das, ohne den Ballast einer IDE), diese eine noch relativ überschaubare Größe haben und zur Not auch ohne Installation funktionieren.
Und ja, ich habe damit schon einige Treiber geschrieben, auch wenn das nichts zur Sache tut.
Die haben allerdings nichts mit Leerzeichen gemein. Die kommen nur von der Toolchain, weil sie auf diese Weise self-contained ist und mit relativen Pfadnamen ihre Komponenten suchen kann.
Zumindest habe ich jetzt auch ein nmake.exe (für das das originale makefile geschrieben wurde). Außerdem habe ich alles mal in ein lokales git Repo gepackt. Leider finde ich keine richtige Lizenz da drin, die es gestatten würde, das bspw. auf github allen in dieser Form verfügbar zu machen.
Ah OK, dann hätte er #include "gpiblib/ni488.h" schreiben sollen oder
einen Kommandozeilenschalter für das Verzeichnis im Makefile haben
müssen.
Dieser Teil wird ja nur für 64-Bit verwendet, da der Toolkit wohl bisher nur als 32-Bit Build ausgeliefert wird könnte das bisher nicht aufgefallen sein.
BTW, der Adapter und 7470.exe funktionieren mit einem HP8569B, der sollte sich wie Dein Advantest verhalten. Allerdings ging das bei mir nur nach einer kleinen Modifikation am Adapter, die Details werde ich später im Thread zur Sammelbestellung schreiben.
Nachtrag: Zumindest beim HP8569B kann man das Ganze auch nur per Terminalprogramm erledigen, die Kommandos an den Plotter sind nur Text. Wenn man das dann in Grafik umgewandelt bekommt (7470.exe sollte das können) hätte man das selbe Ergebnis, nur nicht ganz so komfortabel. Damit reicht es wenn die serielle Kommunikation per Terminalprogramm funktioniert.
Nachtrag: Zumindest beim HP8569B kann man das Ganze auch nur per
Terminalprogramm erledigen, die Kommandos an den Plotter sind nur Text.
Stimmt natürlich, ich muss den Adapter ja nur auf einer bestimmten Adresse hören lassen, das geht per ++ Kommandos. Gute Idee!
Mehr als HP-GL brauche ich an sich nicht, damit komme ich dann schon klar.
Dieser Teil wird ja nur für 64-Bit verwendet, da der Toolkit wohl bisher
nur als 32-Bit Build ausgeliefert wird könnte das bisher nicht
aufgefallen sein.
Das würde es natürlich erklären. Ich muss dann wohl den Compiler einfach mal im 32-Bit-Modus starten.
Stimmt natürlich, ich muss den Adapter ja nur auf einer bestimmten
Adresse hören lassen, das geht per ++ Kommandos. Gute Idee!
Eine Adresse wird nicht benötigt, der Advantest sollte sich eigentlich wie mein HP8569B verhalten, das wären dann nur die folgenden Kommandos (Device Mode, Listen Only):
1
++mode 0
2
++lon 1
Eventuell muss man noch EOI und EOS richtig konfigurieren.
Ob es aber auch ohne die bei mir nötige Hardware Modifikation geht kann ich nicht sagen, ich habe nur einen dieser Adapter zum Testen.
Falls Du keine findest, prinzipiell kann man sich die auch selbst stricken. Das ist nämlich nur eine Importlibrary für die gleichnamige DLL. Und es gibt Werkzeuge, mit denen man eine solche Importlibrary automatisch erzeugen kann.
Das müssten "dlltool" und "gendef" sein.
1
gendef ws2_32.dll
Das Sollte eine Datei namens ws2_32.def erzeugen, die für den nächsten Schritt benötigt wird.
Dabei musst Du darauf achten, die richtige Version der dll zu verwenden; wenn Du 32-Bit-Code erzeugen willst, liegt die auf einem normalen Windows-System unter c:\windows\syswow64, während die 64-Bit-Version unter c:\windows\system32 liegt.
Scheint erstmal nicht zu klappen. Ich werde mir deine
Hardwaremodifikation mal ansehen.
Ich kann deine Hardwaremodifikation nachvollziehen. Nur mit dem Pullup an REN/DC funktioniert es bei mir nicht: sowie der Spekki was senden will, entsteht da eine Art Schwingung von reichlich 10 MHz, weil der Spekki offenbar auch REN immer wieder herunter zieht, was natürlich DC beeinflusst.
Erst wenn ich (wie du) DC hart per Pullup auf high setze (und dann erst nach ++mode 1 den AR488 an den Bus stecke), funktioniert das Plotten. Anbei das Spektrum der Rundfunksender.
Aber alles in allem klingt das nach Fortschritt. 7470.exe brauch ich dann auch nicht unbedingt, HP-GL-Daten kann ich auch mit anderen Mitteln weiter verarbeiten (habe ich früher schon bei einem HP54512B gemacht).
