DOS-Forum

Hallo allerseits,

Ich komme aus Österreich und habe am Commodore 128 angefangen.
Anfang der 90er kam dann der erste PC, ein Phillips NMS TC-100, 286er mit DOS 3.3 und 10 MhZ.
Ich habe bis 1999 hauptsächlich Windows 3.11 benutzt.
Ich interessiere mich sehr für Systemprogramierung, vorzugsweise in Assembler und C, habe früher unter DOS programmiert und schreibe bis heute
kleine Tools damit (So schön kleine, kompakte .com Files sind schon was Feines - natürlich 100% Assembler).
Zu meinen Lieblingsbüchern zählt PC Intern 4 und ich glaub auch Ralf Browns Interruptliste ist jedem DOS-Programmierer ein Begriff

Ich bemühe mich bis heute, DOS-Applikationen so lange wie möglich am Leben zu erhalten und bin der Meinung, dass gerade auch für Programmiereinsteiger DOS das optimale Betriebssystem ist, um seine Hardware einmal kennen zu lernen, auch wenn ich zugeben muss,
auch die Vorteile des Protected Mode schätzen gelernt zu haben. Aber für sowas gibt's ja ohnehin DOS-Extender...
Nun hoffe ich, im Forum Gleichgesinnte zu finden.

In diesem Sinne: Totgesagte leben länger.

MOV AX, 4C00h
INT 21h

Hallo und willkommen!

Danke für die Vorstellung... Ich habe Deinen Account gerade freigeschaltet.

Viel Spaß im Forum!

Gruß,
Stephan

Hey dosfreak,

zunächst mal Willkommen im Forum! Den einen oder anderen DOS-Programmierer haben wir schon unter uns, z.B. DOSferatu oder freecrac. :-) Sorry, wenn ich jemanden vergessen habe.

Letztens hab' ich selbst auch ein kleines Tool geschrieben in C. Wenn Interesse besteht, kann ich dir ja mal den Source-Code zukommen lassen. Vielleicht hast du ja ein paar Tipps für mich, wie man das ganze noch verbessern kann.

Gruß,
locutus

Hallo und willkommen dos-freak .

_dos-freak hat geschrieben:Hallo allerseits,

Ich komme aus Österreich und habe am Commodore 128 angefangen.
Anfang der 90er kam dann der erste PC, ein Phillips NMS TC-100, 286er mit DOS 3.3 und 10 MhZ.
Ich habe bis 1999 hauptsächlich Windows 3.11 benutzt.
Ich interessiere mich sehr für Systemprogramierung, vorzugsweise in Assembler und C, habe früher unter DOS programmiert und schreibe bis heute
kleine Tools damit (So schön kleine, kompakte .com Files sind schon was Feines - natürlich 100% Assembler).

Prrima. Mit C kenne ich mich so gut wie gar nicht aus, aber Assembler verwende ich auch am liebsten.

Zu meinen Lieblingsbüchern zählt PC Intern 4 und ich glaub auch Ralf Browns Interruptliste ist jedem DOS-Programmierer ein Begriff
Ich bemühe mich bis heute, DOS-Applikationen so lange wie möglich am Leben zu erhalten und bin der Meinung, dass gerade auch für Programmiereinsteiger DOS das optimale Betriebssystem ist, um seine Hardware einmal kennen zu lernen,

Das ist auch meine Meinung.

auch wenn ich zugeben muss,
auch die Vorteile des Protected Mode schätzen gelernt zu haben. Aber für sowas gibt's ja ohnehin DOS-Extender...

Ein Problem bei der Programmierung für den Protectmode ist es, das so gut wie keiner selber den Kernel dafür programmiert und alle nur Anwendungen für ein bereits vorhandenes OS programmieren und dabei es nur lernen wie man dortige
Systemdienste benutzt, ohne Kenntnis darüber zu haben wie die verwendeten Dinge selber zu realisieren sind. Oft schon habe ich dort eine Unkenntnis z.B. über den Unterschied zwischen dem 16 Bit-Mode und dem 32 Bit-Mode festgestellt.
Viele glauben z.B. das man im 16 Bit- PM keine 4GB mehr addressieren könne. Das stimmt natürlich nicht. Ich selber habe allerdings kaum Erfahrungen mit dem PM gesammelt und verwende vorzugsweise DOS zum programmieren.
Und dabei sehe ich keinen Grund den PM durchgehend zu verwenden. Ich benutze für DOS-Anwendungen wenn es erforderlich ist den 16Bit-Unrealmode/Big-Realmode(http://www.dosforum.de/viewtopic.php?f=15&t=2921) um damit 4GB
zu adressieren und kann damit auch weiterhin DOS und BIOS Aufrufe verwenden, da diese überweigend für den 16Bit RM entwickelt wurden und mit dem PM nicht benutzbar sind.

Nun hoffe ich, im Forum Gleichgesinnte zu finden.

Deine Hoffnung hat sich nun erfüllt.

In diesem Sinne: Totgesagte leben länger.

MOV AX, 4C00h
INT 21h

Ein Errorlevel von Null ist mir am liebsten.

Dirk

Locutus hat geschrieben:Hey dosfreak,

zunächst mal Willkommen im Forum! Den einen oder anderen DOS-Programmierer haben wir schon unter uns, z.B. DOSferatu oder freecrac. Sorry, wenn ich jemanden vergessen habe.

Letztens hab' ich selbst auch ein kleines Tool geschrieben in C. Wenn Interesse besteht, kann ich dir ja mal den Source-Code zukommen lassen. Vielleicht hast du ja ein paar Tipps für mich, wie man das ganze noch verbessern kann.

Gruß,
locutus

Das kleine Assembler-Programm(Link) ist leider nicht mehr vorhanden. Ich selber habe allerdings ein vergleichbares Programm (ab)geschrieben, allerdings ist es schon etwas her(1997) so das ich mich an die dort verwendeten Funktionen kaum noch errinnere.

Code: Alles auswählen

; Mit diesem Programm wird die Schublade eines CD-Laufwerks geöffnet (, oder geschlossen wenn ein Befehl weiter unten geändert wird).

; Assemblieren mit MASM 5 z.B so:
; MASM /Z OpenCD.asm,OpenCD.obj,,
; LINK /CP:1 OpenCD.obj,OpenCD.exe,,,

.MODEL SMALL
.386
 CODE SEGMENT use16 'CODE'
 assume cs:CODE,ds:DATEN,ss:STAPEL
 org 100h
;--------------------------------------
START:    mov      ax, DATEN
          mov      ds, ax
          mov      ah, 52h             ; get "List of Lists"  from dos
          int    21h                   ; (undocumented dos function)
          add      bx, 22h             ; advance to NUL driver offset
;--------------------------------------
; identify driver type: block or character type
;--------------------------------------
ISBLDRV:  test    BYTE PTR es:[bx+5], 80h ; check driver type
          jnz short ISCD               ; jump if it is character device

ISDRV:    mov      di, bx              ; reload driver offset
          mov      bx, es:[di]         ; and get offset of next drvr
          cmp      bx, 0FFFFh          ; end of driver chain?
          jz  short BACK               ; jump if no more to check
          mov      ax, es:[di+2]       ; else retrieve next segment
          mov      es, ax              ; load in extra register
          jmp  short ISBLDRV           ; then jump to check next driver
;--------------------------------------
; check character driver for match
;--------------------------------------
ISCD:     mov      di, bx              ; point to driver offset
          mov      si, OFFSET STRING   ; point to string to match
          add      di, 0Ah             ; advance to driver name
          cmpsb                        ; compare first byte
          jnz short ISDRV              ; jump if no match
          mov      cl, 3               ; 3 more character to match
LOOKASC:  cmpsb                        ; compare next byte
          jnz short ISDRV              ; jump if not matched
          dec      cl
          jnz LOOKASC
;--------------------------------------
; transfer complete driver name to a buffer
;--------------------------------------
          mov      ax, es
          mov      dx, ds
          mov      si, bx              ; point source to driver offset
          mov      di, OFFSET DATEI    ; point to buffer to store name
          mov      cx, 8               ; name length=8 characters
          mov      ds, ax
          mov      es, dx
          add      si, 0Ah             ; and advance to driver name to load
          rep movsb                    ; copy complete driver name
          mov      ds, dx
;--------------------------------------
; continu to open/close the cdrom...
;--------------------------------------
          xor      cl, cl              ; Open-CD = 0 / Close-CD = 5
          mov      ax, 3D21h           ; Open Device using handle:
          mov      dx, OFFSET DATEI
          int    21h
          jc  short BACK
          mov      CTRL, cl            ; Parameter Open or Close !
          mov      bx, ax              ; file handle into bx
          mov      ax, 4403h           ; IOCTL function
          mov      cx, 1               ; number of bytes to write
;          mov      dx, OFFSET CTRL
         dec      dx
          int     21h
;--------------------------------------
BACK:     mov      ah, 4Ch             ; exit program
          int    21h
  CODE ends
;---------------------------------------------------------------------------
  DATEN SEGMENT use32 'DATA'
 org 0
STRING DB "CD1 "                       ; start of driver name
CTRL   DB ?                            ; offset ControlBlock
DATEI  DB "MSCD000 ", 0                ; offset DATEI
  DATEN ends
;---------------------------------------------------------------------------
  STAPEL SEGMENT use16 STACK 'STACK'
       DB 10h dup (?)
  STAPEL ends
 end

Dirk

@freecrac: Mh, der Link zum Ursprungsprogramm scheint echt tot zu sein. Aber ehrlichgesagt programmiere ich aus Gründen der Wiederverwendbarkeit und Übersichtlichkeit sowieso lieber in C. Ich muß den Thread zu CDBeQuiet! mal ein wenig aufräumen und in dem Zug stelle ich dann den Quellcode auch online. Wenn du Lust hast, kannst du ja dann mal drüberschauen. Wahrscheinlich habe ich einiges umständlicher gelöst, als es sein muß und außerdem fehlt auch noch die eine oder andere Funktion (z.B. Sicherheitsmaßnahmen wie Erkennung ob es sich Festplatte oder optisches Laufwerk handelt). Außerdem fehlen noch Sachen wie Abfragen des IDE-Error-Registers etc.

Gruß,
locutus

Locutus hat geschrieben:@freecrac: Mh, der Link zum Ursprungsprogramm scheint echt tot zu sein. Aber ehrlichgesagt programmiere ich aus Gründen der Wiederverwendbarkeit und Übersichtlichkeit sowieso lieber in C.

Wegen der Übersichtlichkeit programmiere ich lieber alles in Assembler, weil dann sieht man ganz genau was die CPU macht. Daneben schreibe ich dann jedoch auch Erklärungen mit dazu,
damit ich später schneller erkennen kann was der jeweilige Code-Abschnitt genau bezwecken soll. Mit C habe ich hierbei meine Schwierigkeiten z.B. überhaupt einen verwendeten IRQ zu finden,
auch mag ich die gesamte Struktur von C überhaupt nicht leiden. Pascal gefällt mir hierbei schon um einiges besser. Auch mag ich es nicht besonders leiden den Code auf verschiedene Dateien zu zerteilen,
ich habe bisher immer den gesamten Code für eine Anwendung in einer einzigen Quelldatei geschrieben und auf jegliche Macros des Macro-Assemblers verzichtet. Linus Torwald sagt zwar das er ebenfalls eine
objectorientierte Programmierung für besser hält, wesentliche Teile von Linux hat er aber selber nicht mal objectorientiert programmiert. Das klingt schon etwas paradox in meinen Ohren.

Ich muß den Thread zu CDBeQuiet! mal ein wenig aufräumen und in dem Zug stelle ich dann den Quellcode auch online. Wenn du Lust hast, kannst du ja dann mal drüberschauen. Wahrscheinlich habe ich einiges umständlicher gelöst, als es sein muß und außerdem fehlt auch noch die eine oder andere Funktion (z.B. Sicherheitsmaßnahmen wie Erkennung ob es sich Festplatte oder optisches Laufwerk handelt). Außerdem fehlen noch Sachen wie Abfragen des IDE-Error-Registers etc.

Gruß,
locutus

Mich interessiert es schon wie man ein CD-Rom ausbremsen kann, doch wie schon erwähnt habe ich mit C oft erhebliche Probleme so das es mir schwer fällt den Code zu lesen.
Beispielsweise gibt es ein C-Listing um VESA Generalized Timing Formula(GTF siehe url) selber zu berechnen und ich war leider immer noch nicht in der Lage die Funktionsweise
dort richtig zu erkennen. So habe ich versucht mit dem Taschenrechner die Formel nachzurechnen, doch ich kam immer nur auf falsche Werte.
http://www.opensource.apple.com/source/ ... ools/gtf.c

Aber dein Listing schaue ich mir natürlich auch gerne mal an. Möglicherweise kann ich etwas daraus lernen.

...

Bei der Suche nach "gtf.c" bin ich wieder mal auf ein PDF(diesmal von der Universität Ulm) gestossen wo behauptet wird das man für den lineraren Framebuffer ein 32 Bit-OS benötigt.
Ich weiss wirklich nicht wer so eine falsche Information erstmalig in die Welt gesetzt hat, zumindest scheinen dort die Autoren(P. Schulthess & M. Schöttner) des PDFs nicht wirklich
den Unterschied zwischen dem 16Bit-Mode und dem 32Bit-Mode zu kennen und so wird aus Unwissenheit darüber diese falsche Information immer weiter verbreitet.
http://www-vs.informatik.uni-ulm.de/tea ... 2/Kap7.pdf siehe Kapitel 7.5 Linearer Bildspeicher Seite 201. Die dortigen Informationen sind falsch und natürlich ist es auch möglich
im 16Bit-Mode den gesamten 4GB-Adressraum(so auch den linearen Framebuffer) zu adressieren. Das geht mit dem 16Bit-PM und dem 16Bit-Unrealmode bei der Verwendung eines 80386+.

In meinen Beiträgen hier http://www.dosforum.de/viewtopic.php?f=15&t=2921 habe ich den Unterschied zwischen dem 16Bit-Mode und dem 32Bit-Mode mal etwas genauer erklärt.

Dirk

freecrac hat geschrieben:Wegen der Übersichtlichkeit programmiere ich lieber alles in Assembler

Jedem das Seine. :-)

Die GTF von Vesa sieht aber kompliziert aus...

Den Thread habe ich jedenfalls aktualisiert, inkl. Download für den Sourcecode. Viel Spaß!

locutus

Locutus hat geschrieben:
freecrac hat geschrieben:Wegen der Übersichtlichkeit programmiere ich lieber alles in Assembler
Jedem das Seine.

Möglicherweise kann ich dein C-Lising ja leichter lesen.

Die GTF von Vesa sieht aber kompliziert aus...

Das finde ich auch.

Den Thread habe ich jedenfalls aktualisiert, inkl. Download für den Sourcecode. Viel Spaß!

locutus

Ah prima, dann schaue ich dort gleich mal rein.

Dirk

DOS-Forum

Vorstellung

Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung

Re: Vorstellung