4. MS-DOS-Devicetreiber mit Borland C++ 3.1

MS-DOS-Devicetreiber mit Borland C++ 3.1

  • U

    Ich weiß (glaube) ja nicht, ob (daß) ich hier jemanden treffe, der schon einmal unter Borland C 3.1 einen DOS - Device - Treiber programmiert hat, aber hoffen darf man ja...

    Zum Problem: Ich kann kein Assembler und auch nur wenig C, habe aber ein bedingt funnktionsfähiges Gerüst (will ein Device programmieren, das man zum Lesen und Schreiben wie eine Datei öffnen kann) mit folgenden 2 Problemen:

    Wenn ich das Device nach fopen("device","wb"); geöffnet habe und mit
    fprintf(device,"%c",'X'); ein X in das Device schreibe, wird die Funktion 9
    (Output with Verify) nicht sofort aufgerufen, sondern erst nachdem ich mit
    fclose(device); den Treiber wieder geschlossen habe.
    Das Attributwort ist asm dw 1000000000000000b also ein zeichenorientiertes Device.
    Mit setbuf() im Anwenderprogramm könnte ich den Zeichen buffer auf 0 setzen, doch der Treiber muß universell sein und auf bereits bestehende Software bei jedem Zeichen sofort reagieren.
    Wie kann ich den Zeichenbuffer bereits im Device auf 0 setzen oder kann ich z.B. durch Veränderung des Attributwortes oder sonst irgend wie erreichen, daß "Output" (8) bzw. "Output with Verify" (9) nach jedem Schreiben eines
    Zeichens in das Device sofort aufgerufen wird?
    (Blockorientiert bekomme ich den Treiber bisher gar nicht geöffnet)

    In der Driver-Interrupt-Routine “void saveregs far interrup_rtn(void)“
    kann ich keine Funktion aufrufen ( selbst "void test(void) { return;} " nicht ),
    ohne daß der Treiber abstürzt.
    Wie müssen Funktionsaufrufe aus der Interrupt-Routine heraus deklariert sein, damit sie korrekt angesprungen und terminiert werden?
    (auch test als far zu deklarieren führt zum Ansturz)

    Ich hoffe inständig auf einen Profi, der die beiden Fragen beantworten kann...

    0
  • C

    Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Compiler-Forum verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.

    0
  • ?

    unter welchem betriebssystem entwickelst du und unter welchem soll dein treiber
    laufen?

    mfg f.-th.

    0
  • U

    Schade, daß der Beitrag verschoben wurde, denn mit Compilern hat er nun wirklich nicht viel zu tun!

    Ich dachte, daß man an dem Attributwort und den Outputfunktionen 8 und 9 sehen konnte, daß es um einen DOS - Device - Treiber geht und es hauptsächlich um die Frage geht, wie ich bei jedem einzelnen Zeichen einen "OUT"-Befehl erzeugen kann 😮 (unabhängig von der Programmiersprache).

    😮

    0
  • R

    Hast du Zugriff auf eine Ausgabe "PC intern" von Michael Tischer? Soweit ich mich erinnern kann, ist das da drinnen ganz gut erklärt. Ich kann mich jetzt gerade nicht damit beschäftigen, aber vielleicht schau ich später noch mal hier rein.

    0
  • U

    Zeitschriften hab' ich leider keine (sonst kein Programmierer). Der Treiber wird auch nicht immer von einem mit C geschriebenem Programm aufgerufen, sondern es kann auch Pascal oder Assembler sein (also irgendein Öffnen und Beschreiben der Device-Datei).
    Zum Schreiben in eine Datei über DOS finde ich da z.B.:
    Interrupt 21h Funktion 40h
    Eingabe:
    AH = 40h
    BX = Handle der Datei/des Geräts
    CX = Anzahl der zu schreibenden Bytes
    DS = Segmentadresse des Puffers
    DX = Offsetadresse des Puffers
    Ausgabe: Carry Flag = 0 --> Ok und AX = Anzahl der geschriebenen Bytes
    Carry Flag = 1 --> Fehler u. Fehlercode in AX: AX = 5 = Zugriff verweigert
    AX = 6 = Ungültiges Handle
    aber zum Schreiben muß es ja eben erst einmal kommen und das sollte sofort bei einem Zeichen erfolgen (CX=1) und nicht erst, wenn der Buffer voll ist.

    Und die mit DOS groß gewordenen Spezialisten sind sicher alle schon in Rente... 😉

    0
  • ?

    hallo user
    ringding meinte das buch, gibt's in verschiedenen auflagen. könnte vielleicht
    in einer bücherei einzusehen sein.

    mfg f.-th.

    0
  • U

    Buch? welches Buch? Habe hier ein Buch über MS-DOS-Devicetreiber von R.S.Lai in Assembler, aber das gleiche Problem scheint auch bei den Assemblerprogrammen zu bestehen, wenn man nicht weiß, wie man aus dem Devicetreiber die Dateibuffer verwalten muß...

    0
  • B

    user4711 schrieb:

    Wenn ich das Device nach fopen("device","wb"); geöffnet habe und mit
    fprintf(device,"%c",'X'); ein X in das Device schreibe, wird die Funktion 9
    (Output with Verify) nicht sofort aufgerufen, sondern erst nachdem ich mit
    fclose(device); den Treiber wieder geschlossen habe.

    Das ist kein Problem mit dem Treiber, sondern eine Eigenschaft der stdio.h-Funktionen (printf, putc, scanf usw. in allen Varianten). Diese arbeiten aus Geschwindigkeitsgründen gepuffert. Die eigentliche Ausgabe bzw. die Übergabe an den Treiber erfolgen erst dann, wenn der Puffer voll ist, wenn der Puffer mittels fflush(mein_stream) explizit geleert wird, oder, wie du schon herausgefunden hast, wenn der Stream geschlossen wird.
    Auf setbuf(NULL) bist du auch schon gekommen.

    IMHO ist das allerdings ein nicht vorhandenes Problem. Du solltest dir im klaren darüber sein, dass jeder C-Programmierer (blutige Anfänger vielleicht ausgenommen) weiß, dass das so ist.

    Wie kann ich den Zeichenbuffer bereits im Device auf 0 setzen

    Wie gesagt, der Puffer befindet sich nicht im Treiber, sondern wird vom stdio.h-Unterbau unterhalten und ist im Prinzip Teil des FILE-Objektes, das du von fopen zurückgegeben bekommst.

    (Blockorientiert bekomme ich den Treiber bisher gar nicht geöffnet)

    Blockdevices kann man auch nicht als Dateien ansprechen.

    In der Driver-Interrupt-Routine “void saveregs far interrup_rtn(void)“
    kann ich keine Funktion aufrufen ( selbst "void test(void) { return;} " nicht ),
    ohne daß der Treiber abstürzt.
    Wie müssen Funktionsaufrufe aus der Interrupt-Routine heraus deklariert sein, damit sie korrekt angesprungen und terminiert werden?
    (auch test als far zu deklarieren führt zum Ansturz)

    Ich würd zuerst mal sagen, dass der Interrupt-Handler mit dem Schlüsselwort interrupt deklariert werden sollte. Aber ob das hier das Problem ist, weiß ich nicht, dazu müsste man denke ich den Assembler-Code des Handlers mal sehen. Vielleicht was mit dem Stacksegment.

    Ach ja, das mit "PC Intern" ist ein guter Tipp.

    0
  • ?

    ISBN-Nummer? 🙂

    0
  • B

    Keine Ahnung, ich hab meins verliehen.

    0

  • Bashar schrieb:

    Keine Ahnung, ich hab meins verliehen.

    falsch. du hast es mitgenommen 🙂 ich habe doch mein eigenes pc intern gekauft, amazon, herabgesetzt.. also suchen 😉

    ps: einfach pc intern bei amazon eingeben, sofort da.

    0
  • ?

    welche ausgabe meint ihr denn? es gibt da bestimmt 5 stück...

    0
  • B

    elise schrieb:

    falsch. du hast es mitgenommen 🙂

    Ups, stimmt 😊
    dann liegt es im Keller in irgendeinem Umzugskarton.

    Zu den verschiedenen Ausgaben: Keine Ahnung, welche davon die empfehlenswerteste ist. Ich hab die 3.0, die war zur Zeit von MS-DOS 5.0 ca. 1991/92 aktuell. Da fehlt z.B. noch alles über CD-ROMs.

    0
  • ?

    hallo
    PCintern 3.0 : ISBN 3-89011-591-8
    jede vernünftige buchhandlung sollte diese info aber sowieso haben. 🙂

    mfg f.-th.

    0
  • ?

    Also PC Intern 5.0 scheint für Windows Programmierung zu sein. Ich denke mal dann sollte man PC Intern 4.0 kaufen...

    PC intern 4 | ISBN: 3815810949

    0
Anmelden zum Antworten