Nachrichten

1

Offtopic / Re: ToasterOS

« am: 08. July 2007, 15:58 »

rofl, unser pro Coder hat noch ned mal ne richtige TLD und will ernst genommen werden...

2

Offtopic / Re: Static Operating System

« am: 30. April 2007, 19:36 »

Wow 

Respekt, das sieht ziemlich gut aus

3

Offtopic / Re: Welche Software setzt ihr ein?

« am: 24. February 2007, 23:24 »

bochs
HxD Ein guter Hex-editor, mit dem man Diskettenimages Sektorweise betrachten kann (sehr hilfreich)

Hm, die hab ich ganz vergessen. Hab ich auch. Ist echt nützlich, wenn man Disketten auslesne möchte.
Habs vor allem gebraucht, als ich das FAT12 Sytsem eingebaut hab.

4

Offtopic / Re: Welche Software setzt ihr ein?

« am: 24. February 2007, 22:13 »

Hm, hab nur den FASM.

Und um meinen Bootsector auf die FD zu bekommen, nimm ich rawrite.

Als Editor hab ich Notepad2, gibt nix besseres 

5

Lowlevel-Coding / Re: Assembler-Programm will nicht...

« am: 19. February 2007, 16:29 »

Njain, es ist schon sinnlos, den Speicherblock zu verkleinern und dann einen neuen anzufordern, aber um das Timing exakt hinzukriegen, muss ich den Timer abfangen und timing-exakt die Daten an den Parallelport schicken. Dazu dachte ich im Prinzip zwei "Threads", den Producer (Puffer-Füller) und den Consumer (Interrupt-Handler). Und da ist die Adressierung über ein Segment (an bekannter Adresse) ganz praktisch.

Ist doch unter DOS egal?
Da haste ja keinen Speicherschutz, rein theoretisch könntest du überall hin schreiben, da meckert keiner 

Du hast als Segmentadresse für ds einfach ds=cs+1024*16 genommen, also fängt bei dir der Puffer genau 16k hinter dem Programm an?

Ja, wobei ich unnötig viel hinzuaddiert hab.
Dein programm ist ja keine 16KB groß^^

Es reicht auch, nur 40H hinzuzuaddieren.

Code: [Auswählen]

mov ax, ds
add ax, 40H
mov ds, ax

Dann liegt der Datenbuffer genau 1024 Byte hinter dem Start von dem Programm.

Und eine Verständnisfrage: Das Programm beginnt also bei Adresse cs:0x0000

Jo, also theoretisch schon, in der Praxis eher an CS:0x0100, weil vor nem .COM programm noch 256 Byte vom PSP sind.

und der Stack bei cs:0xffff ? Bringt dein Ansatz damit nicht den Stack durcheinander (wenn der Stack dann benutzt wird) ?

Hm, also rein theoretisch könnte es so sein, dass der Stack bei CS:0xFFFF beginnt.
Das würde dann wohl den Stack durcheinander bringen.
Aber das müsste man umgehen können, wenn du als Segment für deinen Datenbuffer CS+1000H nimmst.
Dann dürfte der Buffer direkt 64KB hinter dem Start deines programmes liegen und dem Stack keine Probleme mehr bereiten.

6

Lowlevel-Coding / Re: Assembler-Programm will nicht...

« am: 19. February 2007, 11:45 »

Also scheinbar haut das mit dem Speicher anfordern net ganz hin.
Keine Ahnung wieso.

Ich habs unter XP getestet, da hat mir das System den Fehler gebracht, dass auf das COM3 Gerät zugegriffen werden will (Bei der 3FH Funktion), aber das nicht geht.

Ich hab dann einfach die beiden FUnktionen zum verkleinern des Speichers und zum Anfordern eines Speicherblockes gelöscht.

Dann einfach auf die aktuelle Segmentadresse die Größe des eigentlichen Programmes addiert und das dann als neue Segmentadreses genommen.
So konnte ich dann eine Datei einlesen.

Code: [Auswählen]

mov ax, ds
add ax, 1024
mov ds, ax

        ; read (next) 64K of file
        mov ah,3Fh
        mov bx,[cs:FILEHANDLE]
        mov cx, 0ffffh
        mov dx,0
        int 21h
        jc err_fread


Wenn deinem programm von DOS sowieso schon der ganze Speicher zugeordnet wurde, isses ja sowieso egal, dann wärs doch sinnlos (?) , extra den Block zu verkleinern und dann nochmal einen neuen anzufordern.

7

Lowlevel-Coding / Re: Assembler-Programm will nicht...

« am: 18. February 2007, 19:11 »

Mein Problem: In dem Moment, wo ich den int 21h aufrufe, bricht mein gesamtes Programm zusammen. Den Code zum Berechnen der aktuellen Programmgröße habe ich aus dem Netz.

Bei welchem Int 21H Aufruf bricht das programm ab?
Bei dem Stück Code, der den Speicherblock vergrößern soll?
Was soll das überhaupt bringen?
Was hast du davon, den Speicherblock, wo dein Programm drinne ist, auf 64KB zu erweitern?

Steht grad aufm Schlauch 

Code: [Auswählen]


; set program's memory size to 64K (limit of "tiny" COM files) - CS=DS=ES=SS
        mov bx,ss
        mov ax,es
        sub bx,ax
        mov ax,sp
        add ax,14h
        shr ax,4
        add bx,ax
        mov ah,04ah
        int 21h



8

Offtopic / Re: osdever

« am: 18. February 2007, 19:01 »

Du hast die Links zu dem Probekapitel falsch gesetzt.
Auf der Seite, wo man das Teil saugen könnte, hats du osdever.net statt osdever.net.tc angegeben.

9

OS-Design / Re: Kernel in Pascal

« am: 08. February 2007, 19:40 »

http://debian.fmi.uni-sofia.bg/~nickysn/paskernel/
http://sourceforge.net/projects/glider-kernel

Ohne Gewähr, hab ich nur auf die schnelle gefundne, weis nicht, ob es das ist, was du suchst.

10

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 01. January 2007, 20:28 »

Und nein, auch du bist nicht so gut, daß du vollkommen fehlerfreien Code schreibst.

So gut ist wohl niemand 

btw
ich habs mir mittlerweile angewöhnt, in ASM soviel in FUnktionen auszulagern wie möglich.
bzw. so machs ich mittlerweile in jeder anderen Sprache auch.
hat den Vorteil, dass man nur relativ geringe Codemengen auf "Fehleranfälligkeit" testen muss und wenn dann Fehler auftreten, man bestimmte Funktionen von vornerein ausschließen kann.

11

Offtopic / Re: frohes neues!!!

« am: 01. January 2007, 15:37 »

Ein frohes Neues jahr
Und viel Glück bei euren projekten 

12

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 01. January 2007, 12:23 »

Den INVOKE Funktionsaufruf möcht ich in der W32 programmierung nicht mehr missen.

Schau dir OS-64s APIs an!!!

Was hab ich davon? *dumm-frag* 

Damit wollte ich nur demonstrieren das schlechte APIs nichts mit ASM zu tun haben. Meine lassen sich ganz einfach mit ASM ansprechen. Oder was wolltest du sagen mit den Win APIs?

bitmaster

Nö, ich meinte es im Bezug darauf, dass jemand schrieb, Programmierung in ASM sei generell fehleranfälliger.
Dem habe ich zugestimmt und habe als Bemerkung angeführt, dass der Macro Assembler von MS dem Programmierer einiges abnimmt, z.b. mit der INVOKE Direktive(?).
INVOKE sparrt dem Programmierer das Pushen und Poppen von Parametern.
z.b.: INVOKE DoSomething, Parameter1
Das verwandelt der Assembler automatisch um in:

PUSH Parameter1
CALL DoSomething
POP parameter1

Dadurch vermeiden sich fehler, die sich ergeben, wenn man z.b. die Parameter in der falschen Reihenfolge pushen würde oder nach dem CALL vergessen würde, den stackPointer wieder richtig hinzubiegen.

13

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 01. January 2007, 11:33 »

Den INVOKE Funktionsaufruf möcht ich in der W32 programmierung nicht mehr missen.

Schau dir OS-64s APIs an!!!

Was hab ich davon? *dumm-frag* 

14

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 31. December 2006, 18:05 »

Im Ernst..in Assembler zu programmieren ist nicht nur ineffizient, fehleranfaellig, unproduktiv, nicht nachhaltig, etc., sondern auch ausserordentlich gut fuer die Portierbarkeit. Wirklich gut. Vor allem, wenn man verschiedene Microprozessoren hat und die gleiche Applikation drauf laufen lassen will. Viel Spass.

Das hat hier auch niemand behauptet, zumindest habs ich nicht mehr im Kopf.
Klar ists fehleranfälliger, wenn ich mich selber um den Stack kümmern muss, wenn ich selber nach nem Funktionsaufruf die werte zurückholen darf, wenn ich vor ner Schleife nen Wert pushe und aus versehen den in der Schleife wieder poppe.
Wenn ich dann Stunden damit verbringe den fehler zu suchen und ihn nicht finde, weil ich jedesmal irgendwo ein "POP XY" übersehe.

Gelobt sei der Macro Assembler von Microsoft.
Den INVOKE Funktionsaufruf möcht ich in der W32 programmierung nicht mehr missen. 

15

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 31. December 2006, 14:33 »

@bluecode
Funzt aber auch nur solange, wie das Ergebnis nur eine Ziffer hat, oder?
Oder wandelt der Compiller die Char variable erst in nen Integer, und dann wieder zu nem Char?

16

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 30. December 2006, 20:12 »

bin mir aber ziemlich sicher, dass das nicht geht

Geht das denn in ASM?

bitmaster

Nicht ganz genauso, aber das hab ich nie behauptet
Weil wäre ASM = PHP würd ich nicht mit MOV Werte in Variablen kopieren sondern mit einem IstGleich Zeichen

mov ax, "1"
add ax, 02h
--> Ergebnis="3"
 
geht solange das ergebnis nur eine Ziffer hat.


@us
Oh, das geht?
Sieh an, wusst ich nicht 
Dann muss ich wohl meine Behauptung zurückziehen 

Edit: Eigentlich wollte ich aber garnicht so eine Diskussion lostreten!  sad

Ach, schadet doch nix.
So hat man wenigstens mal wieder ne ordentliche Diskussionsrunde 

17

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 30. December 2006, 18:46 »

Erklär mir bitte mal, welchen Sinn es machen soll, einen Wahrheitswert als Zahl zu behandeln.

Wie gesagt, war nurn beispiel.

Mir ist die Funktion von Typecasts durchaus bewusst (bzw. ich weis, dass es sie gibt, benutzt habe ich sie mangels C(++) projekte nie), allerdings war meine Aussage nur, dass ich sowas in ASM nicht brauche.
Das, und nichts anderes, habe ich gesagt.
Wie einfach und simple TC's zu bedienen sind, ist mir relativ egal, in ASM brauche ich das nicht.

Offensichtlich kannst du nicht besonders gut PHP, sonst wüßtest du, daß PHP Datentypen hat. Und wenn man das nicht beachtet, kann man auf die Schnauze fliegen. (z.B. Größer-/Kleiner-Vergleich auf Strings und auf Zahlen macht einen Unterschied!)

Offensichtlich habe ich dann meine PHP projekte ohne große PHP Kentnisse geschrieben   
Damit meinte ich eher, dass es egal ist, das ich schreibe:

$a=5;
echo $a;
$a="abc";
echo $a;

oder:

$a="5";
$b=7;
$c=$a+$b;
echo $c;

Und das mach mal in C (ohne Typecast natürlich).
Ich bin zwar der C 'schen Sprache nicht mächtig, bin mir aber ziemlich sicher, dass das nicht geht...
Dass ich in PHP auf einen Buchstaben keinen Integer addieren kann, weis ich auch...

(z.B. Größer-/Kleiner-Vergleich auf Strings und auf Zahlen macht einen Unterschied!)

Wie? Willst du Buchstaben(-strings) mit zahlen vergleichen?

btw
Primitiv heißt aber auch nicht zwingend unübersichtlich... 

18

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 30. December 2006, 15:32 »

Aber Winsocks? Das ist doch selbst in C geschrieben, ich bezweifle, daß man das besser versteht, wenn man es mit Assembler anspricht.

Jo, warn schlechtes Beispiel, zumal man in C und in ASM die WinAPI dafür nutzen muss, demzufolge war mein Argument ziemlich daneben gegriffen 

Hm, ja... Ich persönlich finde ja Ausdrücke wie "(a + b) *c" schon übersichtlicher (oder sagen wir vielleicht lieber: aus dem richtigen Leben gewohnter) als ein paar Zeilen Assembler für dasselbe.

ich mein den gesamten Syntax an sich, aber wie gesagt, das ist Ansichtssache.

Ist mir nicht direkt einsichtig. Kontrolle durch den Compiler bedeutet schonmal einige vermiedene Fehler. Einen Nachteil sehe ich dagegen nicht.

Naja, wenn ich erstmal ne Funktion suchen muss, um nen Bool in nen Integer umzuwandeln, oder z.b. in Delphi nen TString in nen String Datentyp (sind nur Beispiele), ist es mir lieber, wenn ich ein DWord habe, und sonst nix 
Ich  bins von PHP schon gewöhnt, nur einen Datentyp zu haben, alles andere finde ich nich gerade berauschend 

Ich kann mich daran erinnern, dass es jemanden in diesem oder einem anderem Forum gab, der Hardcode geschrieben hat (also mit nem Hexeditor alle Befehle eingetippt... -_- ).

lol, das hab ich auch mal gemacht; da wirste verrückt mit der zeit 
ich glaub, ich hab nen Tag gebraucht für ein Prog, das den ASCII Code einer Taste ausgibt.
aber ne Erfahrung wars wert 

19

Offtopic / Re: Ist C und Unix nur ein Joke?

« am: 28. December 2006, 22:57 »

Ich halte mich an Bitmaster und schreibe Assembler.

* Biehler Productions2 too

@taljeth
Mir gefällt Assembler einfach, weil ich selber alles in der Hand haben kann.
Vor allem hilft mir Assemblerprogrammierung, systeminterne Dinge besser zu verstehen, z.b. wie ein Prozessor funktioniert, oder wie WinSockets funktionieren.
Dadurch, das ich in W32 ASM Sockets benutze, muss ich meine HTTP Header etc. selber zusammenbasteln, was wiederum dafür sorgt, dass ich weis, wie solcher aufgebaut ist.
Gäbe genügend solcher Beispiele.

Was ich an C nicht mag:
Ich finde, C Syntax ist unübersichtlicher als ASM Syntax.
Aber das wird wohl im Auge des Betrachters liegen.
Außerdem hab ich was gegen Datentypen, bzw. die strenge Kontrole derjenigen.
In ASM hab ich ein byte7word (16Bit) und in 32Bit ASM eben ein DoubleWord.
Da isses egal, ob der Rückgabewert einer Funktion eine Zahl oder ein Pointer oder ein Handle ist.
Wird alles in einem DoubleWord gespeichert, fertig aus, Amen.

Was für C (und jede andere höhere Sprache) spricht:
Grob über den Daumen gepeilt würd ich sagen, dass ein in C geschriebenes Prog nur 1/4 soviel quellcode hat wie ein in ASM geschriebenes, gleichwertiges Prog.

20

Offtopic / Re: Welches Betriebssystem verwendet ihr zum proggen?

« am: 27. December 2006, 20:46 »

ich progge nur auf nem Win XP, bins einfach gewohnt, außerdem zock ich unterm Coden immer mal wieder ne Runde, um mich zu entspannen