Com-Port Anfrage

[[ CONVEX ]]

Wie kann man mit Pascal aus einer Dosbox heraus feststellen, ob ein bestimmter Com-Port "nicht" vorhanden ist?

Das Problem:
Ich habe ein Programm geschrieben, mit dem ich Befehle an die 4 Standard Com-Ports versenden und empfangen kann. Wenn ich jetzt z.B. Daten an Com-Port zwei sende, das physisch nicht existiert, dann blendet ärgerlicherweise Win XP die Fehlermeldung 'Das System kann den Anschluss "COM2" nicht öffnen' auf dem Desktop ein und die Dosbox wird weggeklappt.

Gibt es Bios oder Dos-Funktionen mit dem ich im vorhinein feststellen kann, ob das Com-Port existiert? (In Win 9X Versionen funktioniert das ohne Probleme)

[Xpyder]

Die einfachste Methode ist, die 4 COM-Adressen der Ports
einfach aus dem Speicher auszulesen.
Ab Speicherstelle [0:$400] stehen die COM-Adressen als
Words. Normal sind das sowas wie $03F8, $02F8, $03E8,
$02E8.
(Kann man natürlich auch [$40:0] schreiben.)
Enthält eine der 4 Speicherstellen (bzw
Doppel-Speicherstellen, weil ja Word), statt einer
Portadresse eine 0, so ist der COM nicht vorhanden.

comnr:=1;
if memW[$40:comnr*2-2]=0 then write('com',comnr,' nicht vorhanden.');

Es gibt noch "narrensicherere" Tests - aber dies sollte
imo funktionieren und genügen. Klar können so
Speicherstellen verändert werden. Das machen das BIOS oder
Windows aber nicht "einfach so".

Man kann natürlich auch ne Variable anlegen:

var comaddress:array[1..4]of word absolute $40:0;


Oder wenn man nur wissen will, ob vorhanden oder nicht,
dann halt:

var comexists:array[1..4]of wordbool absolute $40:0;

Dann kann man nämlich einfach schreiben:

if comexists[1] then write('com1 vorhanden') else write('com1 fehlt');

und so weiter...
Man kann natürlich, wenn eine Adresse drinsteht, auch noch
weiter prüfen, ob das a) WIRKLICH ein COM ist und b)
welche Art COM.
(Halt UART 8250, 8550, 16459, 16550, 16550A, 16570, usw.)
Und wieviel FIFO der hat und auf welchen Werten er steht
usw. Problem: Wenn da eine Adresse drinsteht und es KEIN
COM ist, wird man wieder eine Fehlermeldung kriegen - weil
man auf einen nicht vorhandenen Port nunmal nicht
zugreifen kann (und Windows das moniert).

[[ CONVEX ]]

Okay, erstmal danke für die ausführlichen Hinweise. Dennoch tut mir das nicht weiterhelfen.

Ich kann mit meinem Programm alle UART-Register lesen und beschreiben (unter Windows mit Einschränkungen). Ebenfalls ist das Ein- und Ausschalten des FIFO, wie auch das Setzen des Triggerlevels kein Problem.

Was ich gerne möchte ist unter Windows XP eine zuverlässige Lösung zu finden, die den nutzlosen Aufruf von nicht existierenden COM-Ports umgeht. Unter Windows 98 beispielsweise ist dies kein Problem, durch das Lesen von $0040:$0000, wie Du auch schon beschrieben hast. Unter Win XP werden alle 4 Com-Ports mit den Werten $03f8, $02f8, $03e8 und $02e8 rückgeliefert, obwohl z.B. nur ein Com-Port physisch existiert! Aktuell passiert das, sobald ich das LCR-Register lese (zur Ermittlung der Com-Parameter notwendig), reagiert Win XP mit der genannten Fehlermeldung.

Du hast in Deiner Ausführung noch von narrensicheren Tests geredet, welche wären das?

Im vorhinein vielen Dank.

[Xpyder]

Nach dem Einschalten des PCs wird das BIOS aktiv. Es
scannt die Hardware und trägt für jeden COM-Port, den es
findet, eine neue Hardware-Adresse ein, unter der dieser
Port dann angesprochen werden kann. Das ist ein guter
Service - da kann eigentlich kein Mensch was dagegen haben.

Dann startet WindowsXP, überschreibt diese gültige Tabelle
mit falschen Informationen, die bei deren Benutzung
Fehlermeldungen erzeugen. Was sagt uns das über Microsoft?
(und Windows XP?)

War mir eigentlich schon zu 95% vorher klar, daß das
wieder ein Fehler ist, den MS verbockt hat - aber egal.

Meines Wissens gibts aber einen weiteren Service. Nämlich
den, daß per Definition keine COM-Ports "ausgelassen"
werden - d.h. COMs werden nacheinander angeordnet. Es ist
z.B. NICHT möglich, daß es einem COM1 und COM3 gibt, aber
keinen COM2. Und das kann man wohl nutzen. Weil nämlich
irgendwo - kann sein, BIOS-Segment (also $0040:x) - glaub
aber eher es war irgendwo in den CMOS-Registern (!!) die
ANZAHL der belegten COMs eingetragen wird - so daß man
also sehen kann, welche der Adressen gültig sind und
welche nicht (die Reihenfolge der Adressen stimmt schonmal
und ist immer dieselbe. D.h. Sie wäre korrekt, wenn alle 4
COMs aktiv wären.)

BISHER hab ich mich immer auf die "Adresse <>0" Methode
verlassen, weil ich dachte, es kann ja gar keiner so blöde
sein, die korrekten BIOS-Daten einfach durch irgendeinen
Mist zu überschreiben, und sich dann zu wundern, daß es
nicht funzt. - Aber so blöde wie Microsoft kann man als
normaler Mensch vermutlich gar nicht denken...

(Anmerkung für alle, die es intereessiert: Auch die LPTs
werden mit so einer "Anzahl" Eintragung im CMOS
eingetragen. Und im BIOS-Segment ist eigentlich Speicher
für VIER LPTs. Nur wird der vierte nie benutzt. Denn zur
Eintragung der Anzahl LPTs sind nur 2 Bits vorgesehen, die
ja nur 4 Zustände annehmen können. Und einer der Zustände
ist ja 0 - falls KEINE LPTs vorhanden. Das ist ein Fehler,
der aber zu XT Zeiten irgendwann passierte und für den es
nie einen "Workaround" oder "Update" gab - und so haben
bis zum heutigen Tag PCs maximal 3 LPTs... [LPT = "paralleler
Port" aka "Druckerport"] - Allerdings: bei seriellen Ports
(also COM) hat man das NICHT verbockt - hier sind also 4
möglich.)

Noch ne Anmerkung: Nach allem, was ich weiß, soll es
möglich sein, PCs mit bis zu 8 (!) COMs zu betreiben (es gibt
ja auch COM-Steckkarten) - wo allerdings die Adressen für
com5 bis com8 eingetragen werden - keine Ahnung.

Kommen wir also zur Lösung Deines Problems:
1.) Ich könnte nochmal alles bei mir durchwühlen,
vielleicht finde ich ja die entsprechende "Anzahl" Adresse
irgendwo.
2.) Es kann allerdings sein, daß Microsoft die ebenfalls
versaut hat.
3.) Windows-Versionen VOR XP hatten diesen ätzenden Fehler
NICHT. (Welchen Vorteil bietet XP eigentlich? Außer bunt
und so...)
4.) Möglicherweise kann man die "nicht benutzten COMs"
irgendwo deaktivieren in Windows - aber Problem ist ja,
daß Du eine "Selbsterkennung" bauen willst, damit
benutzerfreundlich.
5.) Und jetzt noch ein Vorschlag, der etwas
unkonventionell ist - aber wie ich Microsoft kenne, funzt
der wahrscheinlich besser als die "direkte Hardware"
Methode.

Nämlich, indem Du einfach die Dateien "com1", "com2", "com3"
und "com4" nacheinander öffnest (und schließt) - nur um zu
sehen, bei welcher Datei Pascal einen Dateifehler erzeugt.
Denn schließlich kann man ja so COMs wie "Files" behandeln
(imo ne Erfindung von Microsoft - benutzt auch eigentlich
keiner, den ich kenne - da abartig zu handlen, grad wenn
sich COM-Parameter ändern usw.)
Aber auf die Art könnte man möglicherweise eben
rauskriegen, welche "Files"vorhanden sind und welche nicht.
Habe grade probiert, es mit Pascal zu lösen, aber dort
werden auch "com3" und "com4" gefunden - er findet alles
von com1 bis com9... - aber vielleicht bringt hier die
Verwendung der DIREKTEN DOS-Routinen (INTs aus "Ralph
Brown's Interrupt List") ja Abhilfe.
Denn wenn man in DOS sowas macht wie copy com3 dummy.txt
(und hat keinen com3) wird ja schließlich ne Fehlermeldung
erzeugt. Was bei com1 nicht passiert (wenn man einen hat).
Was bedeuten muß, daß es ja irgendwie ermittelbar sein muß.
(Will sagen: Ziel ist, irgendeinen "Datei nicht gefunden"
Fehler zu erzeugen, weil sowas ja bekanntlich in Pascal/DOS
abgefangen werden kann und keine Win-Fehlerfenster öffnet.)

Wäre halt eine mögliche Lösung - aber wie gesagt, kann
auch mal bei Gelegenheit diese ominöse Speicherstelle/CMOS
Register suchen. Oder jemand anders hier erinnert sich
(jetzt, wo er das liest) an dieses Register und postet das
mal fix.

Noch ein WICHTIGER HINWEIS: Früher habe ich in diesem
Com-Test auch immer (weil so gelernt und mein erster
Beispielsource das so machte) für die COM-Ports einen
sogenannten "Loopback-Test" gemacht. Dazu wird ein BIT in
einem UART-Register gesetzt und man kann Daten quasi auf
den COM selbst zurückwerfen, um seine Funktion zu testen.
Wie Tests allerdings ergeben haben, funktioniert dies
unter Windows NICHT! - Will sagen: Loopback-Test ist
auszubauen, wenn es unter Windows laufen soll! (In manchen
Win-Versionen stürzt sogar das Programm ab!)

Zum Thema "narrensichere Tests":
Was ich mit "narrensichere Tests" meinte, war eigentlich
eher: Wenn schon die Adresse eines COMs bekannt ist, daß
man mit Hilfe einiger Dinge testen könnte, ob das, was an
diesem Port hängt, wirklich ein COM (also ein UART-Chip)
ist oder nicht. Geht natürlich nicht, wenn Windows diese
"unerlaubten Port-Zugriffe" gleich moniert.

ICH würde ja NICH so'n Schrott coden, wo ich in eine
"Liste gültiger Ports" Portadressen eintrage, die ich dann
nachher beabsichtige, bei Zugriff als "ungültig" abzuweisen.
Aber OK - ich bin ja bloß ein Hobby-Coder und nicht das
größte Softwareunternehmen der Welt.
(Jetzt mal ehrlich - selbst an den größen Windows-Fan: Ist
Unfug wie z.B. dieser jetzt grade wieder durch IRGENDWAS
zu rechtfertigen? Ich an Bin Ladens Stelle hätt mir
wahrscheinlich nicht das World Trade Center als Primärziel
ausgesucht - aber lassen wir das...)

Anmerkung zum Schluß:
So langsam hab ich es satt mit diesem motherfucking Windows.
Mit jeder neuen Version dieses $#%!#&! muß man einen neuen
Workaround coden für Dinge, die früher immer tadellos
funktioniert haben - und für deren plötzliche Dysfunktion
es keine vernünftige Erklärung/Entschuldigung gibt.
Weißte, ich hab eigentlich nix dagegen, mich an gültige
Standards zu halten. Aber nur, solange sich der "Standard"
nicht jedesmal automatisch ändert, sobald Microsoft mal
wieder Scheiße gebaut hat.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
An dieser Stelle fällt mir - passend zum Thema - dieser
klasse Witz ein, der - genau betrachtet - eigentlich schon
gar keiner mehr ist:

F: Wieviele Microsoft-Mitarbeiter braucht man, um eine
kaputte Glühlampe zu wechseln? -

A: Gar keinen. Wenn die Glühlampe kaputtgeht, erklärt
Microsoft einfach Dunkelheit zum neuen Industriestandard.

[[ CONVEX ]]

Hi Xpyder,

da bin ich wieder. Habe meine letzte Prüfung erfolgreich hinter mich bringen können und jetzt endlich wieder Zeit fürs coden.

Erst mal vielen Dank für deine Anmerkungen zu Windows und zu meinem Problem.

Deine Kritik an Windows und speziell an Windows XP kann ich nur voll unterstützen. Weitere Kritikpunkte lassen sich ohne Schwierigkeiten anfügen. Ein Betriebssystem sollte idealerweise die Brücke zwischen den Wunschprogrammen des Anwenders und der Rechner-Hardware sein, nicht mehr, aber auch nicht weniger. Wenn ich z.B. MP3-Dateien runter lade, will ich selbst als Kunde entscheiden, ob ich dafür bezahle oder vielleicht auch nicht. Dann will ich nicht durch dieses unsinnige, von Microsoft mit seiner scheinheiliegen Moral gebaute Windows XP und sein DRM gegängelt werden. Um es ganz klar zu sagen: DRM und andere gegen Kundeninteressen gerichtete Funktionen haben in einem Betriebssystem, das der Kunde für teues Geld kaufen muss, nichts zu suchen!

Deine Hinweise zu meinem COM-Problem:
1. Die korrekt (!) eingetragene Anzahl der COM-Ports im CMOS werden durch Windows überschrieben, bzw. ist nicht zugänglich (Was hat sich Microsoft dabei gedacht?).
2. Die Methode, über COMBasePort<>0 die Existenz der COM-Ports zu ermitteln, funktioniert unter Windows XP nicht (Ich wiederhole mich: Was hat sich Microsoft dabei gedacht?)!
3. Die Existenz der COM-Ports über die Ansprache als logische Einheit/Datei und Fehlerauswertung festzustellen, funktioniert unter Turbo Pascal in keiner Windows-Version, allerdings auch nicht unter DOS.

Deine gemachte "Anmerkung zum Schluss": Ich schliesse mich an, Scheiss motherfucking Windows.
Könnte man nicht die viele nutzlos vertane Zeit Microsoft in Rechnung stellen?

[Diogenes]

']...
Deine Kritik an Windows ....
...


(Gilt auch für Xpyder)

Das ist off-topic und gehört daher ins Off-Topic.

[Xpyder]

Bezog sich teilweise aufs Thema und so hätt man den Bezug
nicht herstellen können.

Hab mal im Off-Topic geantwortet, Titel: "Wieso darf man
alles kritisieren..."