Rexx-System-Problem

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Antworten
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Rexx-System-Problem

Beitrag von DonLucio »

Hallo,
ich bin ziemlich am Ende mit meiner Weisheit. Ich bräuchte dringend eine Inspiration, wo die Ursache für mein Problem liegt.

Der Sachverhalt ist dieser:
Ich habe ein selbstgeschriebenes Rexx-Programm (genaugenommen: VX-Rexx). Ist ziemlich umfangreich und benutzt etliche externe DLLs, wie z.B. die bekannte RexxUtil.dll.
Das Programm dient meiner Medienverwaltung und ist praktisch täglich im Einsatz, seit nunmehr fast 10 Jahren. Zuletzt geändert am 10. April dieses Jahres. Aber, wie gesagt, wird jeden Tag aufgerufen, teilweise mehrfach. Gab nie Probleme. Auch die eingebundenen externen DLLs sind schon uralt und versehen seit x Jahren klaglos ihren Dienst. In allen eCS-Versionen seit Beginn, teilweise schon zu OS/2-Zeiten.

Nun passiert seit gestern urplötzlich folgendes:
Programm bricht in der Startphase ab mit einem Fehler beim Einbinden einer dieser externen DLLs: "Routine not found".

Die DLL, die geladen werden soll, heißt spUtils.dll. Ich weiß gar nicht mehr, wo ich die her habe. Ist vom 15.2.2004.
Mit diesen Befehlen wird sie eingebunden:

Code: Alles auswählen

rc = RxFuncAdd("spLoadFuncs", "spUtils", "spLoadFuncs") ;
rc = spLoadFuncs();
Der Abruch passiert beim spLoadFuncs(): "Routine not found". Das heißt wohl, dass der vorangegangene RxFuncAdd() nicht funktioniert hat.

Die übliche Ursache für diesen Abbruch ist ein Fehlen der DLL. Das kann ich aber mit 100%iger Sicherheit ausschließen. Die DLL befindet sich seit Jahren im Pfad, ausserdem habe ich sie jetzt mal hilfsweise zusätzlich ins Programmverzeichnis kopiert. Einen Schreibfehler (z.B. falsch geschriebener Name des DLL-Einsprungpunktes 'spLoadFuncs') schließe ich ebenfalls aus, weil das Programm 'kompiliert', d.h. als Exe vorliegt und bisher immer funktioniert hat.

Ist die DLL vielleicht physisch kaputt? Um das auszuschließen, habe ich die DLL von einer Datensicherung zurückkopiert, sicherheitshalber gleich von zwei verschiedenen Sicherungen. Datei-Größe, - Datum in allen Fällen identisch. Hilft alles nix. Er kann die DLL nicht laden.

Dummerweise liefert der vorausgehende Befehl RxFuncAdd() keinen aussagefähigen Returncode. Bei mir ist er in allen Fällen immer "1".

Insgesamt lädt mein Programm diese DLLs, alle erfolgreich, bis auf die letzte in dieser Reihe:

Code: Alles auswählen

nok = RxFuncAdd("SysLoadFuncs",  "RexxUtil", "SysLoadFuncs") ;rc = SysLoadFuncs();
nok = RxFuncAdd("FileLoadFuncs", "FILEREXX", "FileLoadFuncs");rc = FileLoadFuncs();
nok = RxFuncAdd("RxExtra",       "RxExtras", "RxExtra")      ;rc = RxExtra("LOAD");
nok = RxFuncAdd("mciRxInit",     "MCIAPI",   "mciRxInit")    ;rc = mciRxInit();
nok = RxFuncAdd("PrxLoadFuncs",  "PRXUTILS", "PRXLOADFUNCS") ;rc = PrxLoadFuncs();  /* Date-Functions   */
nok = RxFuncAdd("FtpLoadFuncs",  "rxFtp", "FtpLoadFuncs")    ;rc = FtpLoadFuncs();
nok = RxFuncAdd('RxgdLoadFuncs', 'RXGDUTIL', 'RxgdLoadFuncs');rc = RxgdLoadFuncs();
nok = RxFuncAdd("SockLoadFuncs", "RxSock",   "SockLoadFuncs");rc = SockLoadFuncs("bypass_copyright");
nok = RxFuncAdd("spLoadFuncs",   "spUtils",  "spLoadFuncs")  ;rc = spLoadFuncs();
Ich habe auch mal die fragliche Programmzeile an den Anfang dieser Codesequenz gelegt (um vielleicht Speicherermangel auszuschließen). Ohne Erfolg.

Ich habe auch keine erkennbaren RAM-Probleme. Aktuell sind 2,2 GB (von 4) unbenutzt. Alle anderen DLLs werden geladen (s. o. Codesequenz).

Im POPUPLOG.OS2 befindet sich auch kein Eintrag. Wo kann ich noch schauen?

Ich bin echt am Ende mit meiner Weisheit. Vor allem auch, weil ich an der ganzen Programmierumgebung nix geändert habe.

Wenn ich sage, dass der Fehler urplötzlich, ohne äußeren Anlass aufgetreten ist, stimmt das nicht ganz: Am Tag zuvor hatte ich Probleme mit einem USB-Stick, den mein eCS nicht erkannt hat, was zu einem Freeze mit anschliessendem Hard-Reset geführt hat. Danach ist der PC aber normal wieder gestartet und es gab auch keine Chkdsk-Leichen ("LOST FILES"). Und ja, ich habe den PC mehrfach neu gebootet. Aber offenbar hat dieser USB-Absturz irgendwas an meinem System so verändert, dass genau nur diese eine spUtils.dll nicht mehr geladen werden kann.

Sorry für diese langatmige Beschreibung. Aber ich weiß echt nicht mehr weiter und brauche mal externe Fantasie und/oder Sachkenntnis.

Danke bis hierher,
Lutz W.
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Ich unterstelle, mit "Pfad" war schon LIBPATH gemeint.
Kannst Du denn irgendetwas mit Rexxtry erkennen?
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

LotharS hat geschrieben:Ich unterstelle, mit "Pfad" war schon LIBPATH gemeint.
Ja. Und die entsprechende Directory befindet sich auch gleich am Anfang des LIBPATH-Statements. Früher gab's da wohl mal Probleme mit zu langem LIBPATH-Befehlsstring. Aber alle diese Überlegungen gehen ohnehin ins Leere, weil da nix dran geändert wurde und zuvor jahrelang alles funzte.
Kannst Du denn irgendetwas mit Rexxtry erkennen?
Rexxtry sagt dasselbe:

Code: Alles auswählen

■■■»rexxtry
  REXXTRY.CMD lets you interactively try REXX statements.
    Each string is executed when you hit Enter.
      Enter 'call tell' for a description of the features.
  Go on - try a few...             Enter 'exit' to end.
rc = RxFuncAdd("spLoadFuncs", "spUtils", "spLoadFuncs");
  rc = 1 ......................................... REXXTRY.CMD on OS/2
rc = spLoadFuncs();
  Oooops ! ... try again.     Routine not found
  rc = 43 ........................................ REXXTRY.CMD on OS/2
Hat also keine neuen Erkenntnisse gebracht.
Doch, eine schon: Ich habe mal testweise eine Nonsense-Funktion einzubinden versucht:

Code: Alles auswählen

  Go on - try a few...             Enter 'exit' to end.
rc = RxFuncAdd("schietfunktion", "schietLib", "schietfunentry");
  rc = 0 ......................................... REXXTRY.CMD on OS/2
rc = schietfunentry();
  Oooops ! ... try again.     Routine not found
  rc = 43 ........................................ REXXTRY.CMD on OS/2
Daraus erkennt man, dass RxFuncAdd nicht immer "1" zurückliefert, sondern er liefert "0" wenn die DLL nicht geladen werden konnte. Insofern sagt uns das: In meinem Fall konnte die spUtils.dll gefunden und grundsätzlich eingebunden werden, aber der Einsprungspunkt 'spLoadFuncs' wurde nicht gefunden.
Aber WIESO nicht??? Die DLL ist intakt. Auch der Einsprungspunkt 'spLoadFunc' ist in der Datei zu erkennen (im Hex-Editor).

Ich habe auch mal versucht, andere Funktionen (Einsprungspunkte) aufzurufen: Überall das gleiche: "Routine not found". Das ist doch crazy!

Trotz allem: Der Tip mit Rexxtry war gut. Hat immerhin gezeigt, dass die Ursache nicht vielleicht doch irgendwo in meinem eigenen (insgesamt recht komplexen) Programm steckt.

Fazit:
Alle möglichen DLLs lassen sich einbinden. Nur diese eine nicht, die seit zig Jahren ein unberührtes und unbemerktes Dasein in meinem PC geführt hat.

Ich hab keine Ideen mehr. Muß ich mir jetzt diese Funktionen selbst nachprogrammieren? Meine C-Erfahrungen liegen leider Jahrzehnte zurück ... :-(

Gruß,
Lutz W.
Benutzeravatar
Rexfahrer
Beiträge: 51
Registriert: Mo 12. Sep 2016, 20:53

Beitrag von Rexfahrer »

Ich habe mir die DLL mal runter geladen (http://www.os2site.com/sw/dev/rexx/libs/sputils01.zip). Ich nehme mal an, das ist die gleiche:

Code: Alles auswählen

[C:\OS2\DLL]bldlevel sputils.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#mecking.net:0.1#@##1## 15 Feb 2004 13:21:38     tp600x::::1::
@@spUtils - spTims Rexx Utility Package
Vendor:          mecking.net
Revision:        0.01.1
Date/Time:       15 Feb 2004 13:21:38
Build Machine:   tp600x
File Version:    0.1.1
Description:     spUtils - spTims Rexx Utility Package
Nach C:\OS2\DLL kopiert und sie scheint zu funktionieren, zumindest gibt spGetBootdrive() korrekt C: zurück:

Code: Alles auswählen

[C:\]rexxtry
  REXXTRY.CMD lets you interactively try REXX statements.
    Each string is executed when you hit Enter.
      Enter 'call tell' for a description of the features.
  Go on - try a few...             Enter 'exit' to end.
rc = RxFuncAdd("spLoadFuncs", "spUtils", "spLoadFuncs");
  rc = 0 ......................................... REXXTRY.CMD on OS/2
rc = spLoadFuncs();
  rc = └±                                                             
                                                                      
                                                                      
                       
say spGetBootdrive()
C:
  ................................................ REXXTRY.CMD on OS/2
rc = RxFuncAdd("spLoadFuncs", "spUtils", "spLoadFuncs");
  rc = 1 ......................................... REXXTRY.CMD on OS/2
Seltsam nur, das RxFuncAdd("spLoadFuncs", "spUtils", "spLoadFuncs") beim ersten Aufruf 0 und beim zweiten 1 zurückgibt.
Soviel von mir REXX-Anfänger, vielleicht probierst du mal die DLL von os2site.com.

Gruß, Laurenz
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

nur als eine Art dumme Idee gedacht (mir fällt ja auch nix echtes ein...) :oops:
Probeweise mit 'switchrx' auf Kommandozeile und Reboot zu Object Rexx wechseln und dort Rexxtry zugucken (geht genauso wieder zurück).
Zuletzt geändert von LotharS am Di 30. Mai 2017, 16:48, insgesamt 1-mal geändert.
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

Rexfahrer hat geschrieben:Ich habe mir die DLL mal runter geladen (http://www.os2site.com/sw/dev/rexx/libs/sputils01.zip). Ich nehme mal an, das ist die gleiche:
Exakt, die ist es.
Rexfahrer hat geschrieben:Seltsam nur, das RxFuncAdd("spLoadFuncs", "spUtils", "spLoadFuncs") beim ersten Aufruf 0 und beim zweiten 1 zurückgibt.
Ja, das hat mich auch irrtiert. Ich hab jetzt mal in der Literatur nachgeschaut: Der Returncode liefert "0", wenn die DLL tatsächlich geladen (registriert) worden ist. Die Wirkung ist ja eCS-systemweit. Einen Returncode von "1" gibt es, wenn die DLL im System bereits registriert war (von wem auch immer). Ist also ansonsten wenig aussagefähig.

Rexfahrer hat geschrieben:Soviel von mir REXX-Anfänger, vielleicht probierst du mal die DLL von os2site.com.
Hab ich. Derselbe Fehler. Was keine Überraschung ist, denn ich hatte ja schon aus meinen Datensicherungen zwei verschiedene Kopien dieser DLL zurückgeholt.

Es muß sich in meinem System irgendein vertrackter Defekt eingeschlichen haben. Ich werde wohl eCS neu installieren müssen. Kommt ja gerade ganz gut zupass, da kann ich gleich die neue ArcaOS installieren.

Gruß,
Lutz W.
Benutzeravatar
Rexfahrer
Beiträge: 51
Registriert: Mo 12. Sep 2016, 20:53

Beitrag von Rexfahrer »

Ich habe mal aus Neugier etwas weiter experimentiert:
Zuerst habe ich REXX.INF nach C:\OS2\DLL copiert und in sputil.dll umbenannt. Die "DLL" lässt sich problemlos mit rexxtry laden :lol: , wenn man aber eine Funktion aus ihr aufrufen will schlägt dies natürlich mit

Code: Alles auswählen

  Oooops ! ... try again.     Routine not found
  rc = 43 ........................................ REXXTRY.CMD on OS/2
fehl.
Dann habe ich die echte sputil.dll mit HexEdit so bearbeitet, dass sie statt registry.dll keinedll.dll lädt, die es natürlich nicht gibt. Die DLL lässt sich wieder problemlos laden, das Aufrufen einer Funktion aus ihr gibt aber auch wieder rc = 43.
Offenbar wird also beim Laden einer DLL mit RxFuncAdd() nicht überprüft, ob die DLL überhaupt wirklich eine DLL ist, geschweige den, ob sie auch lauffähig ist.
Ich glaube das durch den von dir beschriebenen Systemabsturz eine der DLLs die von sputil.dll benötigt werden entweder beschädigt oder gelöscht wurde. Vielleicht findest du also den Fehler indem du sputil.dll mit PMDLL öffnest. Dann könntest du auch noch alle DLLs aus deiner Sicherungskopie wiederherstellen, aber das wird wohl, wenn du sowieso ArcaOS installierst, nur zum Probieren etwas umständlich.

Gruß, Laurenz
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Rexfahrer hat geschrieben:Offenbar wird also beim Laden einer DLL mit RxFuncAdd() nicht überprüft, ...
Genau, nach meiner Literatur registriert rxFuncAdd nur die Funktionen der DLL. Ein RC=0 werde (anfangs) selbst dann zurückgegeben, wenn die DLL nicht existiert oder eine Funktion daraus nicht aufrufbar ist. Beim 2. Aufruf erscheint RC=1. Somit decken sich hier Theorie und Praxis ;)
Ich habe das hier ebenfalls kurz nachgestellt mit dem wahrscheinlich gleichen Paket aus Hobbes: gleiches Resultat. Ich vermute das Problem also eher in der sputils.dll.
Man kann ja statt xxLoadFuncs der Reihe nach mit rxFuncAdd auch einzelne Funktionen registrieren und dann einzeln aufrufen; irgendwann trifft man vielleicht den Übeltäter? Doch für Kenner stehen ja auch die Sourcen zur Verfügung...
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

Rexfahrer hat geschrieben:Vielleicht findest du also den Fehler indem du sputil.dll mit PMDLL öffnest.
Die Idee mit PMDLL ist gut. Kannte ich noch nicht, habe ich mir aus hobbes erstmal runtergeladen (wieso gehört sowas nicht zum eCS-Standardlieferumfang!?)

Überrascht war ich, wieviele weitere DLLs so eine DLL ihrerseits aufruft. Ok, dank der Datei-Ausgabe von PMDLL und einem Rexx-Dreizeiler konnte ich verifizieren, dass alle von spUtils.dll verwendeten DLLs zumindest vorhanden (also nicht versehentlich gelöscht) sind. Festzustellen, ob sie auch unbeschädigt sind, erfordert allerdings mehr als drei Zeilen Rexx. Mal sehen, vielleicht am Wochenende...

Rexx-Frage am Rande dieses Themas:
Trifft es zu zu, dass die Funktion SysSearchPath() nicht mit "LIBPATH" funktioniert? Oder bin ich nur zu blöd zu programmieren?

Danke bisher an alle,
Lutz W.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

DonLucio hat geschrieben: Rexx-Frage am Rande dieses Themas:
Trifft es zu zu, dass die Funktion SysSearchPath() nicht mit "LIBPATH" funktioniert? Oder bin ich nur zu blöd zu programmieren?
SysSearchPath aus RexxUtil sollte mit jedem gültigen Bezeichner für Umgebungsvariablen funktionieren. Eventuell ist in deiner Ausführungsumgebung keine Umgebungsvariable mit dem Namen LIBPATH existent. Der CONFIG.SYS-Befehl LIBPATH macht dies nicht.
Zuletzt geändert von ak120 am Mi 31. Mai 2017, 15:00, insgesamt 1-mal geändert.
Benutzeravatar
Rexfahrer
Beiträge: 51
Registriert: Mo 12. Sep 2016, 20:53

Beitrag von Rexfahrer »

DonLucio hat geschrieben:Ok, dank der Datei-Ausgabe von PMDLL und einem Rexx-Dreizeiler konnte ich verifizieren, dass alle von spUtils.dll verwendeten DLLs zumindest vorhanden (also nicht versehentlich gelöscht) sind.
Das macht PMDLL doch schon, wenn eine DLL nicht vorhanden ist, wird sie rot dargestellt.
DonLucio hat geschrieben:Trifft es zu zu, dass die Funktion SysSearchPath() nicht mit "LIBPATH" funktioniert?
Ja, denn LIBPATH ist ja keine Umgebungsvariable (in der config.sys steht kein SET davor). /PS: da war ak120 schneller

Gruß, Laurenz
Zuletzt geändert von Rexfahrer am Mi 31. Mai 2017, 15:09, insgesamt 1-mal geändert.
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

ak120 hat geschrieben:SysSearchPath aus RexxUtil sollte mit jedem gültigen Bezeichner für Umgebungsvariablen funktionieren.
Genau so hab ich das auch verstanden. Tut's aber bei mir nicht.

Mit Rexxtry ausprobiert:

Code: Alles auswählen

■■■»rexxtry
  REXXTRY.CMD lets you interactively try REXX statements.
    Each string is executed when you hit Enter.
      Enter 'call tell' for a description of the features.
  Go on - try a few...             Enter 'exit' to end.
RC = SysSearchPath("PATH","AE.EXE");say RC;
E:\common\AE.EXE

RC = SysSearchPath("LIBPATH","DOSCALL1.DLL"); say RC;
  rc =  .......................................... REXXTRY.CMD on OS/2
Führt das auf deinem System zu einem anderen Ergebnis?
ak120 hat geschrieben:Eventuell ist in deiner Ausführungsumgebung keine Umgebungsvariable mit dem Namen LIBPATH existent.
Das kann ich ausschließen. Ich denke, es gibt kein OS/2-System ohne eine LIBPATH-Eintragung in config.sys. Es würde wohl kaum ein Programm richtig funktionieren.

LIBPATH wird ja auch nicht mit SET= angegeben, von daher ist das Verhalten von SysSearchPath() sogar verständlich.

Gruß,
Lutz W.
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

Rexfahrer hat geschrieben:Das macht PMDLL doch schon, wenn eine DLL nicht vorhanden ist, wird sie rot dargestellt.
Wissen ist Macht. Und ich bin so machtlos ... :-)
Danke für den Hinweis. Ich wußte das nicht. (Und readme.txt lesen ist doch nur was für Phantasielose :lol: )

Und tatsächlich: Einer der Einträge, nämlich REGISTRY.DLL, wird rot angezeigt (hatte mich schon gefragt, was das soll).
Aber das bringt kaum Klarheit in die Angelegenheit: Mein Rexx-Dreizeiler hat nämlich festgestellt, dass die Datei existiert (und einfache Sichtkontrolle hat's bestätigt).
Wieso markiert PMDLL diese registry.dll als fehlend, wenn sie aber doch da ist??

Weiteres Herumprobieren hat jetzt folgendes ergeben:
"rot" bedeutet wohl "fehlend" oder "fehlerhaft". Und letzteres war offenbar der Fall. Ich habe jetzt diese Datei REGISTRY.DLL aus einem Archiv zurückkopiert und siehe da:

DER SPUK IST WEG!

Bleiben zwei Frage offen:
(1) was genau war an der Datei kaputt (Dateigröße und -Datum waren identisch mit meiner Archiv-Version).
(2) Wieso kann ein USB-bedingter Systemabsturz eine solche lebenswichtige Datei derart beschädigen?

Wir werden es wohl nie erfahren.

Vielleicht noch eine dritte Frage: Woher kommt registry.dll??? Ich war immer der Meinung, dass das, was bei Windows die registry.dat ist, bei uns durch os2.ini und os2sys.ini realisiert wird. Das scheint dann wohl altes, überholtes Wissen zu sein?

Egal. Der Spuk ist weg, mein Programm läuft wieder und ich danke allen hier für ihre rege Teilnahme und Lösungshinweise.

Gruß,
Don Lucio.
Benutzeravatar
Rexfahrer
Beiträge: 51
Registriert: Mo 12. Sep 2016, 20:53

Beitrag von Rexfahrer »

Prima!
DonLucio hat geschrieben:Wissen ist Macht. Und ich bin so machtlos ... :-)
Macht nix (Achtung, Wortspiel :roll: )
DonLucio hat geschrieben:Wieso markiert PMDLL diese registry.dll als fehlend, wenn sie aber doch da ist??
Wenn man in PMDLL die rot angezeigte DLL anklickt wird unten angezeigt warum die DLL nicht geladen werden kann.
DonLucio hat geschrieben:(2) Wieso kann ein USB-bedingter Systemabsturz eine solche lebenswichtige Datei derart beschädigen?
Selbst wenn die DLL gerade von einem Programm geladen wurde sollte sie ja eigentlich nur zum lesen geöffnet sein und deshalb nicht beschädigt werden :?
DonLucio hat geschrieben:Vielleicht noch eine dritte Frage: Woher kommt registry.dll??? Ich war immer der Meinung, dass das, was bei Windows die registry.dat ist, bei uns durch os2.ini und os2sys.ini realisiert wird. Das scheint dann wohl altes, überholtes Wissen zu sein?
Die ist Teil von Open32, was die Portierung von Windows-Anwendungen nach OS/2 erleichtern soll und z.B. von Odin verwendet wird. Damit haben die Windows-Programme dann unter anderem eine Registry, die sie schön zumüllen können :) .
http://www.edm2.com/index.php/Open32

Gruß, Laurenz
Benutzeravatar
DonLucio
Beiträge: 950
Registriert: So 29. Dez 2013, 01:14
Wohnort: Hamburg
Kontaktdaten:

Beitrag von DonLucio »

Rexfahrer hat geschrieben:(registry.dll) Die ist Teil von Open32, was die Portierung von Windows-Anwendungen nach OS/2 erleichtern soll und z.B. von Odin verwendet wird.
Danke für die Aufklärung.

Gruß,
Lutz W.
Antworten