DOS-Forum

malloc, calloc, realloc und free sind die einzigen funktionen die man braucht und deren Verwendung ist in 2min zu erlernen.
Eine untersuchung von malloc.exe (was sollte da überhaupt rein?) kann ich nicht durchführen, da ich mit debug nur schwer klarkomme. Außerdem wird der quellcode durch die Optimierung von Turbo C wahrscheinlich so entstellt, dass man nur schwer aufbröseln kann.

oDOSseus hat geschrieben:malloc, calloc, realloc und free sind die einzigen funktionen die man braucht und deren Verwendung ist in 2min zu erlernen.

Das denke ich auch. Doch ich habe keinerlei Erfahrung mit C und zum Anfang brauche ich wohl ein Rohlisting mit allem was man mindestens zum compilieren braucht.
Auch habe ich keine Erfahrung wie man C installiert und einrichtet, Pfade setzt usw.

Eine untersuchung von malloc.exe (was sollte da überhaupt rein?) kann ich nicht durchführen, da ich mit debug nur schwer klarkomme.

In so eine malloc.exe soll natürlich nur malloc rein, so das die Compilierung damit gelingt, damit wir schauen können welcher IRQ in der malloc.exe dann enthalten ist.
Debug selber hat nur wenige Befehle und damit kann man nur sehr wenig machen. Viel schwerer ist es die Funktionsweise der CPU zu lernen. Also die Verwendung von Register und die verschiedenen Adressierungsarten und natürlich die verschiedenen Opcodes.

Außerdem wird der quellcode durch die Optimierung von Turbo C wahrscheinlich so entstellt, dass man nur schwer aufbröseln kann.

Am einfachsten wird es wohl sein für einen 80286er zu compilieren, denn dann ist es mit debug einfachen den Opcode der malloc.exe ohne dort enthaltene 32Bit-Register durchzuschauen, denn debug kennt nur 80286er.
Wir suchen also nur den DOS-Interrupt(int 21h) und davor müsste sich dann im AH-Register eine 48h befinden.
Debug übergeben wir als Parameter die malloc.exe die dann in debug gleich eingeladen wird.
Beispiel: "debug malloc.exe". Danach befinden wir uns in debug und an der nächsten freien Speicherstelle die debug von DOS zugewiesen bekam befindet sich unsere malloc.exe in den Speicher geladen, aber nicht gestartet.
Der Prompt von debug ist ein Minus-Zeichen und dahinter schreiben wir die Debug-Befehle.
Je nachdem wie groß der Program Segment Prefix(PSP) der malloc.exe ist befindet sich der erste Opcode entweder in CS:0100, in CS:0200, oder CS:0300 usw.
Egal wo der erste Opcode sich befindet zeigt debug zum Anfang immer auf CS:0100, also wenn unsere malloc.exe einen kleinen PSP enthält, dann beginnt dort der Opcode.

Wenn wir nun ein "u" hinter dem Prompt eintippen und Return drücken, dann werden uns die ersten Opcodes angezeigt.
Das sieht dann ungefähr so aus wenn wir debug ohne Parameter starten:

Code: Alles auswählen

152F:0100    0000      ADD  [BX+SI], AL
152F:0102    0000      ADD  [BX+SI], AL
152F:0104    0000      ADD  [BX+SI], AL
152F:0106    0000      ADD  [BX+SI], AL
152F:0108    0000      ADD  [BX+SI], AL

Segment:0100 ByteByte Mnemonic
Segment:0102 ByteByte Mnemonic
Wie man hier sehr schnell erkennen kann macht so eine Befehlsfolge wenig Sinn.

Wir suchen also nach etwa das ungefähr so aussieht:

Code: Alles auswählen

xxxx:yyyy    B448     MOV  AH,48
xxxx:yyyy    CD21     INT  21

Eine Anleitung für Debug findet man hier:
http://www.armory.com/~rstevew/Public/T ... anual.html

Dirk

Ich glaube das ist mir ein bisschen zu viel arbeit, nur um rauszufinden, ob Turbo C das DOS-Interrupt dazu benutzt. Denn da ich alles in C programmiert habe braucht es mich selbst wenig interessieren, welchen ASM code es erzeugt. Ich habe mich über das interrupt informiert und die verwendungszwecke sind die selben, demnach muss ich davon ausgehen, dass ein C-Compiler für DOS genau das benutzt.

oDOSseus hat geschrieben:Ich glaube das ist mir ein bisschen zu viel arbeit, nur um rauszufinden, ob Turbo C das DOS-Interrupt dazu benutzt.
Denn da ich alles in C programmiert habe braucht es mich selbst wenig interessieren, welchen ASM code es erzeugt.

Ok, damit könntest du recht haben.

Ich habe mich über das interrupt informiert und die verwendungszwecke sind die selben, demnach muss ich davon ausgehen, dass ein C-Compiler für DOS genau das benutzt.

Das vermute ich auch. Ich gehe den Sachen nur gerne auf den Grund. So wüsste ich gerne ob in den Librarys von C die verwendeten Interrupts für die verschiedenen C-Funktionen irgendwo lesbar deklariert sind.

Dirk

Die mitgelieferten Libraries samt Header enthalten meist nur minimale Anmerkungen. Das hat zwei gründe:
- Die Header sind universell für alle Betriebssysteme
- Die Libraries sind geschützt, da Borland und CO da hart dran gearbeitet haben.

Ich glaub da wird es schwer, da Listnings und co zu finden

oDOSseus hat geschrieben:Die mitgelieferten Libraries samt Header enthalten meist nur minimale Anmerkungen. Das hat zwei gründe:
- Die Header sind universell für alle Betriebssysteme
- Die Libraries sind geschützt, da Borland und CO da hart dran gearbeitet haben.

Ich glaub da wird es schwer, da Listnings und co zu finden

Aha, na dann brauche ich nicht weiter suchen. Danke für die Info.

Dirk

Kurzer Zwischenstand:
Auch wenn meine Lehrer mich anscheinend mit Hausaufgaben davon abhalten wollen, weiterzuarbeiten, habe ich erstmal die Grundstruktur geändert.
D.h. dass ich keine Zeiger auf Zeiger mehr benutze um alle Elemente zu sichern, sondern deren inhalt komplett in eine große Array speichert. Das hat den Vorteil, dass der Nutzer dieser Library nicht darauf achten muss, wann die Gültigkeit seiner Variablen abläuft.

So jetzt werde ich noch sowas wie Checkboxen erstellen und sowas. Sollte dann so aussehen:

Code: Alles auswählen

(X) 1 Auto
( ) 2 Autos
( ) 3 Autos

Hat hier jemand eine Idee, wie man den Mouse-button status abfragt, ohne dass der buffer geleert wird?
Bin jetzt 6 tage weg, also könnt ihr euch mit der antwort zeit lassen.

oDOSseus hat geschrieben:Hat hier jemand eine Idee, wie man den Mouse-button status abfragt, ohne dass der buffer geleert wird?
Bin jetzt 6 tage weg, also könnt ihr euch mit der antwort zeit lassen.

Nach einer Abfrage empfielt es sich die Werte z.B. im Datenbereich zu retten, so das man jederzeit darauf zugreifen kann.
Aber was genau fragst du ab, es gibt ja verschiedene Abfragen?

[RBIL->inter61c.zip->INTERRUP.N]
--------M-330003-----------------------------
INT 33 - MS MOUSE v1.0+ - RETURN POSITION AND BUTTON STATUS
AX = 0003h
Return: BX = button status (see #03168)
CX = column
DX = row
Note: in text modes, all coordinates are specified as multiples of the cell
size, typically 8x8 pixels
SeeAlso: AX=0004h,AX=000Bh,INT 2F/AX=D000h"ZWmous"

Table 03168
Bitfields for mouse button status:
Bit(s) Description
0 left button pressed if 1
1 right button pressed if 1
2 middle button pressed if 1 (Mouse Systems/Logitech/Genius)

--------M-330005-----------------------------
INT 33 - MS MOUSE v1.0+ - RETURN BUTTON PRESS DATA
AX = 0005h
BX = button number (see #03169)
Return: AX = button states (see #03168)
BX = number of times specified button has been pressed since last call
CX = column at time specified button was last pressed
DX = row at time specified button was last pressed
Note: at least for the Genius mouse driver, the number of button presses
returned is limited to 7FFFh
SeeAlso: AX=0006h,INT 62/AX=007Ch

Table 03169
Values for mouse button number:
0000h left
0001h right
0002h middle (Mouse Systems/Logitech/Genius mouse)

--------M-330006-----------------------------
INT 33 - MS MOUSE v1.0+ - RETURN BUTTON RELEASE DATA
AX = 0006h
BX = button number (see #03169)
Return: AX = button states (see #03168)
BX = number of times specified button has been released since last call
CX = column at time specified button was last released
DX = row at time specified button was last released
Note: at least for the Genius mouse driver, the number of button releases
returned is limited to 7FFFh
SeeAlso: AX=0005h,INT 62/AX=007Ch

Dirk

Was ich abfrage? Ich frage ab, welche Mouse-buttons gedrückt wurden. Das Problem ist, dass ich es in meinem mouse-listener das über das Interrupt 33h mache. Aber ab und zu muss ich auch zwischendurch abfragen, ob ein Mouse-Button gedrückt wurde. An der Stelle verarbeite ich aber nicht den Klick (also, wo geklickt wurde und was dann geschehen soll). Den Klick verarbeiter NUR der listener. Aber ich kann ja jeden klick nur einmal abfragen. Jetzt wäre es mir am liebsten, ich könnte dem Treiber sagen, er solle den Klick-Buffer nicht entleeren, wenn ich abfrage. Aber es scheint so, als ginge das nicht....

Da mein Monitor und die Netzkabel von dem Rechner auf dem ich programmiere nun von meiner Mutter in Benutzung sind, kann ich in nächster Zeit sowieso nicht weiter arbeiten. In der DOS-BOX zu coden ist mir zu doof.

oDOSseus hat geschrieben:Was ich abfrage? Ich frage ab, welche Mouse-buttons gedrückt wurden.

Das du Mouse-buttons abfragst war mir schon klar, ich habe drei verschieden Abfragemöglichkeiten dafür aufgelistet und wollte nun erfahren welche du davon benutzt.
Also entweder mit AX=3, oder mit AX=5, oder mit AX=6 jeweils zusammen mit INT 33h. Aber egal, ich glaube das ist für dein Problem auch nicht so wichtig.

Das Problem ist, dass ich es in meinem mouse-listener das über das Interrupt 33h mache. Aber ab und zu muss ich auch zwischendurch abfragen, ob ein Mouse-Button gedrückt wurde. An der Stelle verarbeite ich aber nicht den Klick (also, wo geklickt wurde und was dann geschehen soll). Den Klick verarbeiter NUR der listener. Aber ich kann ja jeden klick nur einmal abfragen. Jetzt wäre es mir am liebsten, ich könnte dem Treiber sagen, er solle den Klick-Buffer nicht entleeren, wenn ich abfrage. Aber es scheint so, als ginge das nicht....

Dein Problem verstehe ich nicht wirklich. Was hindert dich daran in der Routine die die Mouseabfrage vornimmt den Wert für die Buttons ggf. in eine Variable abzuspeichern, damit du diesen Wert jederzeit erneut abfragen kannst?

In Assembler würde ich dafür eine bestimmte Speicherstelle im Datenbereich reservieren/deklarieren, so das ich darauf zugreifen kann so oft ich möchte. Wie man einen Wert aus einem Register in eine Variblen in C überträgt weiss ich allerdings nicht.
Also wenn du die Abfrage mit AX=3 + int 33h machst, dann bekommst du im BX-Register den Wert der gedrückten Mousebuttons den man dann in eine Variable speichern kann. Wo ist das Problem?

Da mein Monitor und die Netzkabel von dem Rechner auf dem ich programmiere nun von meiner Mutter in Benutzung sind, kann ich in nächster Zeit sowieso nicht weiter arbeiten. In der DOS-BOX zu coden ist mir zu doof.

Hast du noch einen anderen Monitor den du unter Windows nutzt, kann man diesen Monitor denn nicht zum Programmieren zeitweise umstecken?

Du brauchst zwei weitere Netzkabel?

Funktioniert dein Programm in der DOS-BOX?

Ich selber habe schon lange keinen reinen DOS-Rechner mehr und boote DOS über einen 2GB-USB-Stick, oder eine DOS-Boot-CD auf meinem "Windowsrechner" ein Intel-Quadcore mit 2.8 ghz.
Hat der Rechner mit du Windows betreibst denn kein Diskettenlaufwerk, oder ein USB-Anschluss, so das du dort DOS über Diskette oder USB-Stick booten kannst?

Dirk

Habe den Monitor wieder, da meine wir zuhause ne andere Lösung gefunden haben. =)

ich benutze AX=0003h.

Naja ich dachte, es gäbe eine andere Möglichkeit, als die Werte in Variablen zu speichern. Aber wenn es die nicht gibt, werde ich das wohl tun müssen. Ich hätte es halt eleganter gefunden, wenn ich die werte über ein interrupt abfragen könnte OHNE, dass sie aus dem buffer gelöscht werden.

oDOSseus hat geschrieben:Habe den Monitor wieder, da meine wir zuhause ne andere Lösung gefunden haben. =)

Prima.

ich benutze AX=0003h.

Gut.

Naja ich dachte, es gäbe eine andere Möglichkeit, als die Werte in Variablen zu speichern. Aber wenn es die nicht gibt, werde ich das wohl tun müssen. Ich hätte es halt eleganter gefunden, wenn ich die werte über ein interrupt abfragen könnte OHNE, dass sie aus dem buffer gelöscht werden.

Interruptabfragen kosten mehr Zeit als alle andern Lösungen und selbst wenn dort der Buffer für die Bottons noch erhalten wäre, würde ich den Interrupt nicht dafür erneut abfagen und lieber eine Speicherstelle oder eine Variable benutzen.
Auch finde ich diese Variante eleganter und sie ist insgesamt mit weniger Opcodes realisierbar als der Interrerupt mit seinen dort enthaltenen Opcodes. Siehe dazu den Quellcode der Cutemouse.

Dirk

Jetzt klappts
klappt sogar sehr gut =)

Habe schon etwas wie ein "Charfield" gebaut, was eigendlich nur ein Textfeld ist, dass nur einen char enthalten kann. Habe dabei sogar auf Maus und Tastatur gleichermaßen gehört/gelauscht =). Nun baue ich noch ein, dass man Fenster verschieben und erstelle sowas wie checkboxen. Danach widme ich mich Textfeldern und Textareas. Wenn ich das alles habe, werde ich den Header veröffentlichen =)

-------------------------------------------------------------------------------------------------------------------
PS:Schon 1500 Zeilen im header.

oDOSseus hat geschrieben:Jetzt klappts
klappt sogar sehr gut =)

Habe schon etwas wie ein "Charfield" gebaut, was eigendlich nur ein Textfeld ist, dass nur einen char enthalten kann. Habe dabei sogar auf Maus und Tastatur gleichermaßen gehört/gelauscht =). Nun baue ich noch ein, dass man Fenster verschieben und erstelle sowas wie checkboxen. Danach widme ich mich Textfeldern und Textareas. Wenn ich das alles habe, werde ich den Header veröffentlichen =)

-------------------------------------------------------------------------------------------------------------------
PS:Schon 1500 Zeilen im header.

Ich warte schon gespannt und freue mich.

Dirk

DOS-Forum

TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]

Re: TUI programmieren [C]