Nachrichten

21

Softwareentwicklung / Re:Globale, Initialisierte Variable in .bss!?

« am: 18. December 2010, 16:50 »

PS.: Was ist blos in diesem Thread los? Der ist ja mindestens 3 mal so breit wie mein Bildschirm, ich muss ständig den horizontalen Scrollbalken benutzen.

Bei mir wird der Text ordentlich umgebrochen . Ich habe dennoch mal den post bearbeitet und ein paar Zeilenumbrüche eingefügt

Dass die .bss Sektion mit Nullen gefüllt wird, steht im ELF-Standard.

Genau das war ja auch damals das Problem - ich habe alles in eine Binärdatei gepackt und die dann in den RAM gelegt. So etwas wie ein bss-segment gab es nicht 
Inzwischen befindet sich aber auch der Kernel in einer elf-Datei. 

22

Lowlevel-Coding / Re:Task verwaltung

« am: 07. September 2010, 14:52 »

Dieser Thread guck die ganze Zeit auf eine Liste mit Tasks die beendet werden sollen. Die Elemente der Liste sind die gleichen wie die des Schedulers bzw der Taskliste.

Soll jetzt eine Task beendet werden wird dessen Struktur aus der Tasklist genommen und in die Liste der zu beendenden Tasks gegeben.

Der Thread - ich nenne ihn Terminator - stellt dann fest das sich ein Element in der Liste befindet. (die idr 0 Elemente groß ist wenn nicht gerade ein großer Prozess mit 1000 Threads beendet wurde)

Jetzt kann der Terminator-Thread den Speicher der Struktur (des listen-elementes) freigegeben.

Die Pages die der Prozess reserviert hat wird vorher von ihm selber frei gegeben.

Das beenden sieht bei mir im ganzen so aus:
task: suizide
task: suizide: pages freigeben
task: suizide->kill(MyPID());

kill: struktur von der taskliste in die kill-liste schieben !! der Kritische punkt

terminator: task aus der kill-liste nehmen
terminator: delete task;


Es ist wichtig zu beachten das die task erst dann aus der taskliste genommen wird, wenn sie in der kill-liste steht.
ABER das Element darf nicht freigegeben werden solange es noch in der tasklist steht.
Das kann man z.B. in dem man guckt ob die task aus der kill-list zusätzlich noch in der tasklist steht. falls ja, einfach abwarten und später noch mal prüfen.

Ich hoffe es ist verständlich
Ich werde diesen post jedenfalls in meine doku kopieren - so gut hab ich da nämlich nicht beschrieben

23

Lowlevel-Coding / Re:Task verwaltung

« am: 07. September 2010, 09:02 »

Meine Tasks befinden sich ebenfalls in einer einfachen Liste, wobei das letzte Element auf das erste Verweist. Die Liste ist also ring-förmig.
Der Scheduler holt sich dann immer das nächste Element aus der Liste und verarbeitet dieses.

Um Tasks aus der Liste zu nehmen meldet sich der Prozess oder Thread bei einem extra Thread der Tasks entfernt, da ein Prozess oder Thread sich nicht selber aus der Liste löschen darf, da zum einen der Scheduler später noch drauf zugreift und zum anderen der Speicher evtl gar nicht mehr frei gegeben werden kann wenn der finale Taskswitch zu früh kommt

Bisher läuft das recht geschmeidig, wobei ich derzeit selten mehr als 10 Tasks laufen habe.

24

Lowlevel-Coding / Re:floppy, formatierung

« am: 31. August 2010, 16:07 »

Mit dd kannst du ein Image erstellen. Das funktioniert unabhängig von den Daten auf der Diskette.

Code: [Auswählen]

root@linux# dd if=/dev/fd0 of=./floppy.img
Du kannst entsprechend auch ein Image auf die Diskette schreiben, egal was in dem Image steht.

dieses Image kannst du dann mit jedem beliebigen Hex-editor oder anderem Tool untersuchen.


Evtl könnte dein Problem aber auch sein, das es gar kein /dev/fd0 gibt, nämlich wenn du ein USB-Diskettenlaufwerk verwendest.
Dies findest du dann unter /dev/sd*
Ich empfehle dir dann aber über /dev/disk/by-id/* zu gehen da sd* auch die Festplatten beschreibt, und man doch schnell mal auf die falsche Taste kommen könnte

25

Lowlevel-Coding / Re:Treiber C oder Assembler

« am: 13. July 2010, 12:15 »

Nur die 32Bit Version war open source.
Du kannst dir aber den KolibriOS code runterladen, der basiert auf dem Menute32-Code, bzw ist ein fork.

26

Lowlevel-Coding / Re: BIOS pwd copy

« am: 25. June 2010, 08:50 »

Ich denke das ist allgemein ein Hierarchie-Problem.
Selbst die beste Software bringt nichts, wenn man Zugriff auf die Hardware hat, denn davon ist die Software abhängig.
Bei einem meiner PCs sind am Gehäuse hinten 2 Ösen angebracht durch die man ein kleines Vorhängeschloss schieben kann. Vieleiche ist das bei dir auch der Fall.

Gegen den Zugriff per Live-CD könnte vielleicht das Verschlüsseln der Platte/Systempartition helfen. Kenne mich in den Bereichen aber (leider) nicht so gut aus.

Aber auch da gibt es bestimmt Mittel und wegen. Zumal man eine Live-CD ja nicht unbedingt zum cracken des Schutzes nutzen muss. Man kann ja auch direkt von dort aus arbeiten / im Netz surfen. Und dann bringt auch eine unter win eingerichtete Kindersicherung nichts

27

Lowlevel-Coding / Re: BIOS pwd copy

« am: 24. June 2010, 18:40 »

Wie man das BIOS PW umgeht lässt sich im Internet finden, wie man einen selbst geschriebenen Bootloader umgeht nicht
Von daher kann es durchaus sinnvoll sein. Zumindest als Kindersicherung.

Man kann GRUB dazu bringen nach einem Passwort zu fragen bevor man einen Eintrag booten kann. Falls du Linux verwendest ist dies mit wenigen handgriffen getan: grub-eintrag-mit-passwort-schutzen @ linuxnetz.wordpress.com[url]

Wenn du Windows verwendest kannst du es per chainload versuchen.
Es ist mit Sicherheit einfacher und sicherer als selber etwas zu proggen.

menu.lst darf für diese Person natürlich nicht zugänglich sein. Keine Ahnung ob sowas inzwischen unter Windows möglich ist - Da war man ja zumindest früher generell als Admin unterwegs  .

--edit--
Natürlich musst du in dem Fall auch verhindern dass jemand live-CDs starten kann. Damit hätte man dann wieder die Möglichkeit menu.lst abzuändern.
Und um das zu verhindern musst du es im BIOS verbieten. Und das widerum muss dann per PW geschützt werden.

maw: du gerätst in einen Teufels-kreis und wirst feststellen müssen, dass man einen PC zu dessen Hardware man Zugang hat nicht ohne weiteres schützen kann.

Am einfachsten währe wohl, das Gehäuse zu zu schweißen

28

Lowlevel-Coding / Re: Externe Unterprogramme mit NASM

« am: 10. May 2010, 13:10 »

Hab ich das falsch verstanden, oder befinden sich die SW-Interrupts in der IVT und der Code für die SW-Interrupts in einem seperaten File im Speicher ?

Die IVT beginnt an 0x0000:0x0000 ist hat höchst wahrscheinlich eine konstante Größe von 0xFF*(2+2)

Ein Eintrag in der IVT besteht aus dem Segment, und dem Offset einer Funktion.
=>Die Datei kann in irgendeinem Segment liegen. Du kannst auch die Datei für die Funktionen unter int 0xFF in ein anderes Segment laden als die für int 0xFE

PS: Wenn man seine SW-Ints in die IVT einträgt, verbraucht man damit doch eigentlich fast keinen Arbeitsspeicher (bis auf den Teil, der für die neuen SW-Ints im Bereich 0x0000:0x0000 draufgeht, oder ?

Die IVT muss auf jeden fall vorhanden sein - und ist es auch. Du veränderst die Einträge später nur noch, fügst also nichts hinzu.

29

Lowlevel-Coding / Re: Externe Unterprogramme mit NASM

« am: 07. May 2010, 10:04 »

Ich habe das bei meinem bootloader so gelöst, dass die Interrupts 0xF0-0xFF je eine Funktion entsprechen - das erlaubt zwar max 15 Funktionen, aber bisher komme ich gut damit aus.
Kommt natürlich drauf an, wie ausgiebig die API sein soll.
Der Vorteil ist, dass man ein Register weniger "verbraucht" und man sich somit die calls besser in Code integrieren lassen.
So kann man diverse log-ausgaben erledigen, ohne auch nur einmal ein Register zu überschreiben (mal abgesehen von si)

Die Funktionen befinden sich alle in der Binärdatei des Bootloaders werden dort wie folgt in die IVT eigetragen:

Code: [Auswählen]

        mov WORD [es:0xF0*4],   int_0xF0
        mov WORD [es:0xF0*4+2], cs
        mov WORD [es:0xF1*4],   int_0xF1
        mov WORD [es:0xF1*4+2], cs
die Funktion int_0xF0 kann dann z.B. so aussehen:

Code: [Auswählen]

int_0xF0:
    call writestring ; si = string-offset; ds = segment des strings
    iret
Du musst in allen Funktionen die writestring aufruft natürlich beachten das ds und es idr auf "fremde" Segmente zeigen.

Der Bootloader kann nun andere Binärdateien laden, (in ein anderes Segment) und diese Programme können dann ganz einfach per int 0xF0 die writestring-Funktion des Bootloaders aufrufen


zu deinem 1. PS:
nahezu unendlich viele
du könntest ax:bx:cx:dx für eine fortlaufende Nummer benutzen, und die Argumente auf den Stack pushen

zu PS2:
Du musst die Datei im Speicher belassen, die die Funktionen beinhaltet. Wenn sich diese Funktionen so wie bei mir teil des Bootloaders sind ist das ohnehin nicht zu verhindern
Eine zusätzliche Datei (quasi ein shared object file) ist dann natürlich nicht mehr nötig.

30

Offtopic / Re: welches Linux?

« am: 29. April 2010, 18:04 »

Also ich bin mit openSuSE 11.2 & KDE4.4 sehr zufrieden (openSuSE 11.0 war mir auch etwas unsympathisch)

Soweit ich weiß verwendet debian 5 noch KDE3

Sonst fällt mir aber auch nicht mehr viel mit KDE3 ein...

Wenn's auch Gnome sein darf ist Fedora vielleicht interessant. Habe ich auf meinem Viert-rechner. Zum Programmieren ist es auf jeden Fall super da man immer die neusten libs/compiler hat.

EDIT: War ich wohl zu langsam, aber zumindest hätte der Beitrag dir geholfen

31

Softwareentwicklung / Re: call im RM in variables Segment

« am: 29. April 2010, 15:05 »

Super - Funktioniert und ist sogar relativ sauber
wobei der far-call probleme mit dem as86-format machte - habe es dann wie folgt gelöst:

Code: [Auswählen]

push cs
call go_kernel

Die fertige Funktion:

Code: [Auswählen]

[global _ExecSegment]
_ExecSegment:
    push bp
    mov  bp, sp
    push si
    push di
    push ds
    push es

    mov  ax, [bp+4]
    mov  ds, ax
    push cs
    call FarExec  ; Segment //ax// ausführen

    pop  es
    pop  ds
    pop  di
    pop  si
    pop  bp
    ret

FarExec:
    push ax
    push word 0x0000
    retf ; spring in den kernel

32

Softwareentwicklung / Re: call im RM in variables Segment

« am: 29. April 2010, 14:04 »

Allerdings muss ich ja dann auch meinen aktuellen ip und das aktuelle Segment auf den Stack legen damit anschließend der Rücksprung funktioniert.
Ich habe gehofft dass es da eine elegantere Lösung gibt 

33

Softwareentwicklung / call im RM in variables Segment

« am: 29. April 2010, 13:53 »

Hi
Ich erweitre gerade den Skrip-Interpreter meines Bootloaders und möchte gerne das Feature einbauen ein Segment, in welches vorher Daten geladen wurden, auszuführen.

Beispiel:

Code: [Auswählen]

ld /reos/reos16.knl 3000
exec 3000Die Datei reos16.knl wird in das Segment 0x3000 geladen, und soll anschließend ausgeführt werden

Bisher war das Ausführen hart im Code des Bootloaders - nach der Ausführung des Skriptes wurde call 0x3000:0x0000 ausgeführt.
Das würde allerdings in einem Chaos enden, falls jemand im Skript den Kernel in ein anderes Segment lädt.
Ein weiterer Nachteil ist, das nach dem Laden das Skript beendet werden muss, damit der call kommt. Beim runterfahren - also wenn der Kernel wieder verlassen wird, muss nun ein 2. Skript ausgeführt werden anstatt das 1. Skript nach einem exec weiter auszuführen.

Daher die Frage:
Wie kann ich in ein beliebiges Segment springen?

So sieht die Exec-Funktion aus:

Code: [Auswählen]

[global _ExecSegment]
_ExecSegment:
    push bp
    mov  bp, sp
    push si
    push di
    push ds
    push es

    mov  ax, [bp+4]
    mov  ds, ax
    ; call

    pop  es
    pop  ds
    pop  di
    pop  si
    pop  bp
    ret
[bp+4] ist das Segment

34

Softwareentwicklung / Re: lib in nasm / undefined reference

« am: 24. March 2010, 19:12 »

  habs gefunden. Hab ich wohl überlesen 
Danke

35

Softwareentwicklung / Re: lib in nasm / undefined reference

« am: 24. March 2010, 17:23 »

 
Das war ja einfach  Vielen Dank.

Aber warum hat es mit der anderen lib funktioniert? 
Auf der man-page steht auch nirgends dass die libs ans ende gestellt werden müssen...  (im abschnitt zu -l)

36

Softwareentwicklung / lib in nasm / undefined reference

« am: 24. March 2010, 13:41 »

ich habe in nasm eine Bibliothek erstellt. Wenn ich aber Funktionen aus dieser lib nutzen möchte findet mein Linker diese nicht:

Header der lib

Code: [Auswählen]

// ...
extern "C" int OpenPipe(PIPE *pipe, BYTE port, bool write, pipesig signal);
// ...
Code der lib

Code: [Auswählen]

%macro APICALL 2
[global %1 %+ :function]
%1 %+ :
    push ebp
    mov  ebp, esp

    mov  eax, %2
    mov  ebx, ebp
    add  ebx, 2*4 ; eip, ebp
    int  0xFF

    leave
    ret
%endmacro

; ...
APICALL OpenPipe,           0x00020002
; ...
Bau der lib:

Code: [Auswählen]

nasm -f elf -o capi.o capi.asm
ar qf libreos.a capi.o
Code eines Programms

Code: [Auswählen]

#include <reos/reosapi.hpp>
#include <fnc/strex.hpp>
//...
error = OpenPipe(...);
//...
Bau des Programms

Code: [Auswählen]

#kompilieren zu test.o
ld -static -s -o test -L $LIBDIR -lreos -lfnc test.o
Fehler:

Code: [Auswählen]

./pipetest.o: In function `main':
pipetest.cpp:(.text+0x1c): undefined reference to `OpenPipe'

Es wird also das Symbol OpenPipe gesucht, aber nicht gefunden.
Nochmal zur Kontrolle ein blick in die .o des Programms:
readelf -s test.o

Code: [Auswählen]

   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
     9: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND OpenPipe
Nun ein Blick in die libreos.a um zu gucken, ob es ein Symbol OpenPipe gibt:
readelf -s libreos.a

Code: [Auswählen]

Symbol table '.symtab' contains 23 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
    18: 0000012c     0 FUNC    GLOBAL DEFAULT    1 OpenPipe

Das Symbol ist vorhanden - aber warum findet der Linker es nicht? 
(Problem besteht bei allen Funktionen aus dieser lib)

Ich verwende in dem Programm eine andere Bibliothek welche ich in C++ geschrieben habe (libfnc.a) - Diese wird anstandslos gelinkt. Beide libs liegen im selben Verzeichnis.

Wo könnte mein Fehler liegen?
In der lib ist doch genau das gesuchte Symbol vorhanden.

Versionen:
nasm: "NASM version 2.07 compiled on Nov  6 2009"
ld: "GNU ld (GNU Binutils; openSUSE 11.2) 2.19.51.20090527-10.26.4"

37

OS-Design / Re: Wohin mit dem virtual keycode? Wie vom Treiber zum Programm?

« am: 03. March 2010, 17:06 »

Ok
Also entscheidet der parent-prozess darüber an welchen child-prozess die taste geschickt wird.

Danke für die ausführliche Antwort

38

OS-Design / Wohin mit dem virtual keycode? Wie vom Treiber zum Programm?

« am: 03. March 2010, 15:45 »

Hi
Ich beschäftige mich jetzt schon einige tage mit der Frage, wie ich den im Treiber verarbeiteten Tastendruck zu dem richtige Programm bekomme.

Folgende Situation:
Programm A möchte eine Taste einlesen, Programm B ebenfalls.
Der User drückt 'x' - woher weiß ich jetzt zu welchen Programm das x gehört?

Das ganze mal anhand von Linux:
Linux läuft, mit KDE und 2 Terminal-fenster.

der User drückt 'x'
was passiert jetzt mit dem 'x'?
Wird 'x' jetzt erst zu dem entsprechenden tty geschickt, von tty7 dann nach KDE, von KDE dann zu dem im Vordergrund liegenden Terminal, und dieser dann an den zuletzt ausgeführten Prozess?

Demnach müssten ALLE Programme eine Art Fenster/Prozessverwaltung implementiert haben, damit diese wissen an welches Programm (child) das 'x' weiter zureichen ist!?

Mich quälen im Moment 2 Fragen:
1. Welche Methode? Taste senden, oder buffern (die Anwendung holt sich also die Taste selber)?
2. Woher weiß ich, welches Programm diese Taste bekommen soll?

39

OS-Design / Re: Tabelle für Deutsche Scancodes?

« am: 21. February 2010, 15:37 »

Ich brauche den User ja nur zu bitten zu Beginn die Tasten 0..9 zu drücken.

40

OS-Design / Re: Tabelle für Deutsche Scancodes?

« am: 21. February 2010, 13:18 »

das XLAT-Bit habe ich gelöscht, und dann scancodes aus set 2 angefordert:

Code: [Auswählen]

int SetScanCode2()
{
 ///Scancode 1 übersetzung deaktivieren
 SendKBC_Command(KBCCMD_READ_CCMDBYTE);
 BYTE ccmdbyte = GetKBCAnswer();

 ccmdbyte &= ~KBCCCMDBYTE_TRANSLATE_SCANCODE;

 SendKBC_Command(KBCCMD_WRITE_CCMDBYTE);
 SendKBC_Data(ccmdbyte);


 ///Scancode 2 festlegen
 SendKB_Command(KBCMD_SETSCANCODE);
 SendKB_Data(KBSC_2);

 return ERROR_NOERROR;
}
Ich spiele im Moment mit dem Gedanken einfach ein Tool für mein OS zu schreiben, mit dem man lookup-tables für seine Tastatur generieren lassen kann - man zeichnet ein Tastendruck auf, und fragt den User nach dem entsprechenden ASCII-Code...
Die Tabelle wird anschließend natürlich gespeichert - bei jeden booten allen Tasten ASCII-Codes zuzuweisen ist nicht sehr user friendly