Thema: Kommunikation von Programmen

[bscreator]

Hallo,

hab zwei Assembler-Programme geschrieben, die über Ports miteinander kommunizieren sollen. Leider wird der Reader niemals beendet.

Reader : liest solange von Port 9, bis 05h zurückkommt, dann wird Programm beendet

Code: [Auswählen]

ORG 0x100
port equ 9
jmp repeat

repeat:
in al, port
cmp al,05h
jne repeat

ret

Writer : schreibt einmal 05h auf Port 9

Code: [Auswählen]

ORG 0x100
port equ 9
mov al,05h
out port, al

ret
Problem: Das Programm Reader wird leider niemals beendet, was nur heißen kann, dass niemals ein 05h vom Port 9 gelesen wird. Woran kann das liegen ?

[erik.vikinger]

Hallo,

die über Ports miteinander kommunizieren sollen

Wie bist Du eigentlich auf die verrückte Idee gekommen das unterschiedliche Programme über Ports miteinander Kommunizieren können? Ports dienen dazu das die SW mit der HW sprechen kann und sonst nichts! Nimm doch einfach eine bestimmte Speicher-Stelle, in einem richtigen OS bedeutet das Shared-Memory, und dann hast Du genau das was Du mit den Ports versuchst zu tun.


Grüße
Erik


PS.:
Wenn Du das wirklich über Ports machen möchtest, so als Übungsaufgabe, dann nimm bitte das oberste Byte (Byte 7) bei den UARTs (die Basis-Port-Adressen der UARTs findest Du bestimmt selber raus und addierst dann 7 dazu), das ist bei den 16550 kompatiblen eine Art RW-Scratch-Pad-Register und steht zur freien Verfügung (falls Du den UART nicht in einen der höheren Modi 16750,16850 oder 16950 betreiben willst).
Was liegt eigentlich auf Port 9?


PPS.:
Wenn ich Dein Informatik-Lehrer wäre würde ich Dich 100 mal an die Tafel schreiben lassen "Ich missbrauche NIE wieder unschuldige Ports"!
SCNR

[bscreator]

Gut, dass ich keine Informatik-Lehrer, sondern nur Professoren hab

Nene, ich hab ein Assemblerprogramm gesehen, das über Port 9 mit einer grafischen Oberfläche, die in Visual Basic geschrieben ist, kommuniziert.
Also das Assemblerprogramm schickt bestimmte Bytes über Port 9 an die GUI, und diese wertet diese Bytes entsprechend aus.
Deshalb hab ich eben gedacht, dass ich es selber mal versuch.

Aber welche Adresse hat das Shared Memory unter Windows eigentlich, bzw. muss man das unter Windows nicht zuerst irgendwie "erstellen" ?

Später will ich ja nur ein Assembler-Programm schreiben, das mit einem anderen Programm, vielleicht in C oder ASM geschrieben, kommunizieren kann

Gruss,
bsc

[erik.vikinger]

Hallo,

Gut, dass ich keine Informatik-Lehrer, sondern nur Professoren hab

Wenn ich Dein Prof wäre würdest Du das mindestens 1000 mal an die Tafel schreiben! Während die ganze UNI zuschaut. Was lernt ihr eigentlich dort?

ich hab ein Assemblerprogramm gesehen

Und Du machst einfach so alles nach was Du im Internet findest? Das ist ja sehr interessant, da werde ich mal ein paar schöne Dinge ins Netz stellen.
Aber mal im ernst, von jemand der es immerhin an eine UNI geschafft hat sollte man erwarten können das der nicht jeden Mist aus den Medien einfach so übernimmt sondern vorher nach Sinn und Auswirkungen prüft.
War eventuell ein TCP/UDP-Port gemeint?

Aber welche Adresse hat das Shared Memory unter Windows eigentlich, bzw. muss man das unter Windows nicht zuerst irgendwie "erstellen" ?

Üblicherweise muss ein Programm einen bereits vorhandenen Speicherbereich "freigeben" und ein anderes Programm diesen dann "einbinden" (das bekommt dann eine Adresse so wie bei malloc). In einem ordentlichen OS gibt es da noch einige Sicherheitsvorkehrungen damit nicht jedes Programm einfach fremden Speicher einblenden kann oder der Speicher für den Client eventuell nur Read-Only ist, aber vom Prinzip her sollte das so oder so ähnlich ablaufen.

Später will ich ja nur ein Assembler-Programm schreiben, das mit einem anderen Programm, vielleicht in C oder ASM geschrieben, kommunizieren kann

Dann benutze die passenden Methoden die das OS zur Verfügung stellt! Egal in welcher Sprache Du programmierst.


Grüße
Erik


PS.:
Das mit dem fett rumschreien hatte ich doch schon mal erwähnt, Deine Fragen erkennt man auch ohne dem als Fragen und wenn nicht dann hast Du sie falsch formuliert.

[bscreator]

Wenn ich Dein Prof wäre würdest Du das mindestens 1000 mal an die Tafel schreiben! Während die ganze UNI zuschaut. 

Ich schreibs lieber aufm PC mit der for-Schleife

Und Du machst einfach so alles nach was Du im Internet findest?

Wer sagt denn, dass ich das im Internet gefunden hab ?

Das mit dem fett rumschreien hatte ich doch schon mal erwähnt, Deine Fragen erkennt man auch ohne dem als Fragen und wenn nicht dann hast Du sie falsch formuliert.

Naja, jedem kann mans eben nicht recht machen.

Aber ist ja ok, ich hoffe eigentlich nur auf Hilfe von Anderen, die mehr Erfahrung als ich mitbringen und evtl. vor dem selben Problem schon mal standen. Und mir somit passende Lösungsansätze geben wie z.B.

Dann benutze die passenden Methoden die das OS zur Verfügung stellt! Egal in welcher Sprache Du programmierst

Gruss,
bsc

[Svenska]

Naja, ich muss erik zustimmen.

Der Grundgedanke, über einen Port (die Verbindung zwischen Hard- & Software !!) verschiedene DOS-Prozesse unter Windows miteinander kommunizieren zu lassen, ist sowas von falsch, dass man den auch mit Gewalt nicht richtig hinkriegt. Und das fett schreiben ist auch falsch, oder zumindest nervig.

Also, ganz langsam:

- "org 100h" steht für "das Programm läuft ab Adresse 100h" ab - das klingt stark nach DOS
- alle DOS-Boxen unter Windows sind vollständig unabhängig, es wird quasi ein PC simuliert
- wenn du auf dem Rechner in Port 9 (was ist da überhaupt?!?) schreibst, wirst du auf dem Notebook definitiv keine Antwort kriegen. Genauso verhält sich das mit verschiedenen DOS-Boxen unter Windows
- DOS-Boxen untereinander können nicht kommunizieren
- Port-Zugriffe werden in DOS-Boxen entweder ignoriert oder maskiert (z.B. durch die Soundblaster-Emulation geschickt oder so) - auf reale Ports zugreifen geht nur unter ganz bestimmten Ausnahmeregelungen für ganz bestimmte Ports
- wahllos auf Ports schreiben ist doof, weil man damit die Hardware verwirrt - oder teilweise auch kaputt machen kann (CGA-Monitor mit falscher Frequenz angesteuert, CPU gewaltig übertaktet, ...). Allerdings ist heutige Hardware dagegen relativ immun oder man muss vor jedem Schreibzugriff auf einen anderen Port ein Codewort schicken
- der Gedanke mit TCP/UDP-Ports war schon recht naheliegend, allerdings ist Port 9 dort "discard", also Wegwerfport; Port 7 ist "echo"

Dazu kommt noch:
- glaubst du ernsthaft, mit einem DOS-Programm direkten Zugriff auf den Shared Memory unter Windows zu bekommen?
- welchen Shared Memory eigentlich? Jeder Hardwaretreiber hat seinen eigenen plus unendlich viele andere, die es auch noch gibt
- wenn du es schaffst, ohne Rechte unkontrolliert auf den Kernelspeicher oder den Kernel Shared Memory schreiben zu können, hast du einen wunderbaren Exploit gefunden und dazu eine Möglichkeit, jeden PC abstürzen zu lassen...

Da kann ich dir keine Ansätze mehr geben, das ist grundfalsch. Für das, was du willst, - also Kommunikation zwischen Prozessen - gibt es IPC - Inter Process Communication. Vielleicht willst du auch in fremden Prozessen etwas aufrufen, dafür gibt es RPC - Remote Procedure Call. Aber das, was du da vorhast, KANN nicht funktionieren.

Gruß,
Svenska

[erik.vikinger]

Hallo,

Ich schreibs lieber aufm PC mit der for-Schleife

Nein nein, ich meine schon mit richtiger Kreide auf einer ganz normalen Tafel. Sonst würde ja der Lerneffekt ausbleiben und das willst Du doch nicht oder?

Wer sagt denn, dass ich das im Internet gefunden hab ?

Stimmt, war mein Fehler, sorry.
Aber aus irgendeiner Quelle muss das Programm ja kommen und dieser Quelle scheinst Du sehr viel Vertrauen entgegen zu bringen (nach allem was ich bis jetzt weiß eher unbegründetes Vertrauen).

Heute früh hatte ich noch an eine Hausaufgabe/Übungsaufgabe o.ä. gedacht (deshalb habe ich Dir auch den freien Port im UART genannt damit Du diese Übung wenigsten ohne Gefahr für Deine Hardware machen kannst) aber das scheint es ja nicht zu sein.

Ist Dir eigentlich aufgefallen das man mit einem einzelnen Port-Byte höchstens Status-Infos von einem Prozess in einen anderen bekommt? Bei einem einzelnen Byte im Speicher existiert natürlich das selbe Problem. Wie sollte den bei einem Byte-Strom o.ä. der Empfänger mehrere gleiche Bytes direkt hintereinander erkennen (auseinander halten) oder wie soll der Sender erkennen das der Empfänger das Byte schon geholt hat? Bei dem Konzept fehlt jegliche Form von Handshaking!

Und mir somit passende Lösungsansätze geben wie z.B.

Dann benutze die passenden Methoden die das OS zur Verfügung stellt! Egal in welcher Sprache Du programmierst

Es freut mich das ich Dir zumindest eine zufriedenstellende Antwort geben konnte, ich hoffe sie hilft Dir wirklich weiter.


Grüße
Erik

[bscreator]

Also, ich hab so einen Assembler, den 8086 Assembler. Und bei der Software warn einige Beispiele dabei, unter anderem das mit dem Roboter (das Beispielprogramm). Die Oberfläche war, soviel ich weiss, unter Visual Basic geschrieben, und die Kommandos für den Roboter mit dem Assembler. Das Assemblerprogramm hab ich dann mal gestartet und gesehen, dass die beiden Programme (GUI und Kommandos, also ASM und Visual Basic) über Port 9 austauschen. Und ich wollts eben mal mit zwei COM-Dateien (ORG 0x100) versuchen, ob da die Kommunikation auch funktioniert.

Jetzt hab ich mir gedacht, dass ichs mal mit ner gemeinsamen Datei versuchen könnt. Die eine Applikation beschreibt, die andere liest daraus. Aber das wär dann, schäz ich mal, sehr viel Aufwand für den Festplattencontroller (öffnen, schreiben, schliessen, öffnen, lesen, schliessen). BITTE korrigiert mich, wenn ich unrecht habe.
Zumindest wärs ne relativ einfach umzusetzende Möglichkeit.

PS: Den Gedanken mit dem Shared Memory hab ich schon lang aufgegeben.

Aber wie könnt man sonst Nachrichten austauschen ? IPC hab ich bisher nur ein bisl Theorie gehört und versteh bisher noch relativ wenig davon.

- der Gedanke mit TCP/UDP-Ports war schon recht naheliegend, allerdings ist Port 9 dort "discard", also Wegwerfport; Port 7 ist "echo"

Ähm, wie kommst du auf TCP/UDP ? Da musst du mir glaub ein bisl helfen...

Gruss an euch beide,
bsc

 

[Jidder]

Unter DOS gibt es kein Multitasking, und damit auch keine direkte Kommunikation zwischen Programmen. Wenn du unter einem richtigen Multitasking-OS zwei Programme miteinander kommunizieren lassen willst, sind Sockets (TCP oder UDP) nicht die schlechteste Wahl. Unter DOS (bzw. in der DOS-Box) würde ich da aber nicht weiter experimentieren.

[Svenska]

Wenn du unter einem richtigen Betriebssystem programmierst, dann vergiss den 8086-Assembler. Der hilft dir nicht weiter. Programmiere dann in einer Hochsprache mit der API für dein Betriebssystem.

Wenn du unbedingt und mit aller Gewalt Assembler verwenden möchtest, dann informiere dich, wie unter deinem Betriebssystem die Syscalls umgesetzt werden (Aufrufkonvention, Parameterübergabe, Stacknutzung...)

Schließlich gibt es unter DOS (eingeschränkt), Windows und Linux das Konzept der Pipes. Benutze diese statt temporäre Dateien.

Du glaubst aber nicht wirklich, dass du in einer DOS-Box direkten Zugriff auf den Festplattencontroller bekommst, oder?!?

Gruß,
Svenska

[bscreator]

Nene, unter DOS hab ich das ganze mit Sicherheit nicht vor. Das mit den Ports war nur ein Testlauf.
Das "richtige" Programm wird dann unter GCC oder Visual C++ erstellt, die Kommandos möcht ich eigentlich schon in ASM programmieren, aber muss ja nicht immer ASM sein. Muss ja auch kein COM-Programm sein, kann ja auch ne EXE sein.

Hab mir überlegt, dass ich das ganze auch über eine DLL machen könnt. Denn ne DLL kann ja von mehreren  Programmen gleichzeitig benutzt werden, obwohl auch nur ein einziges "Exemplar" im Speicher liegt, wodurch es keine Inkonsistenten Daten geben kann.

Sockets (TCP oder UDP)

Das werd ich auch mal ausprobieren, allerdings immer, wenn ich TCP oder UDP höre, denk ich an mehrere Computer mit Netzwerkverbindungen. Reicht, z.B. über UDP, auch ein Rechner aus ?

Gruss,
bsc

[erik.vikinger]

Hallo,

Das "richtige" Programm wird dann unter GCC oder Visual C++ erstellt, die Kommandos möcht ich eigentlich schon in ASM programmieren, aber muss ja nicht immer ASM sein. Muss ja auch kein COM-Programm sein, kann ja auch ne EXE sein.

Ich will ja nicht unhöflich sein aber das klingt nicht so als hättest Du schon wirklich nen Plan wovon Du da schreibst.
Assembler ist zwar keine nützliche Programmiersprache (es gibt nur extrem wenige Situationen wo man wirklich Assembler benötigt) aber ich persönlich bin der Meinung das jeder ordentliche Programmierer wenigstens mal ein (kleineres) Programm (also mehr als ne simple Hausaufgabe die man an einem Nachmittag erledigt hat) komplett in Assembler programmiert haben sollte damit dieser ein Gefühl für die Arbeitsweise eines Computers und der benutzten Tools entwickelt!
Da Du wohl unter Windows arbeitest schau mal nach http://www.masm32.com/ oder http://www.codingcrew.de/masm32/, aber Vorsicht auf beiden Seiten wird ausdrücklich erklärt das Assembler nichts für Anfänger ist.

allerdings immer, wenn ich TCP oder UDP höre, denk ich an mehrere Computer mit Netzwerkverbindungen. Reicht, z.B. über UDP, auch ein Rechner aus?

Genau dafür gibt es ja 127.0.0.1 bzw. ::1 (also localhost bzw. das Local-Loop-Back-Device).
Setze Dich damit einfach mal etwas genauer auseinander und Du wirst feststellen das TCP/UDP ein sehr guter, erprobter und auch portabler Weg ist um mehreren Programmen die Kommunikation untereinander zu ermöglichen, egal ob auf dem selben Rechner oder über den ganzen Globus verteilt.
Wenn die Programme sicher immer auf dem selben Rechner laufen gibt es auf den meisten Betriebssystemen schnellere bzw. bequemere Möglichkeiten der Kommunikation, unter Windows sind da die "Named-Pipes" das Mittel der Wahl, aber damit verliert man oft die Portabilität oder muss das hinter einer Library verbergen (die dann auf exotischen OSen auf TCP/UDP zurückfällt).


Grüße
Erik