Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - clemensoft

Seiten: 1 2 [3] 4 5
41
Lowlevel-Coding / GRUB/Multiboot.
« am: 24. January 2005, 18:34 »
Hallo. Hat jemand von euch ein Multiboot-kompatibles Betriebssystem geschrieben? Ich hab versucht, Delta Multiboot-konform zu machen, ich kriege die GRUB-Meldung: 13: Unsupported executable format. Ich habs mit ELF, A.OUT, COFF, PE und sonstwas probiert. Müsste mit bin eigentlich gehen! Hier mal der Code von nc_init.asm:


;=======================================\
;   Delta Nanocore Project              |
;                                       |
;    Nanocore Main Core                 |
;=======================================/


%define dnc_version 'Delta Nanocore v0.0.0-14012005-deca1',dnc_arch,dnc_tag,' compiled with nasm-',__NASM_VER__  ;Nanocore version information
%define dnc_arch '-x86-32-grub'
%define dnc_tag '-epsilon15' ;Place your name here if you edited the file



;Functions in this file:

;IM, BF nanocore_entry:
;Start of Nanocore. Gets memory size and initializes the core

;IM, BF nanocore_hangup:
;Used to kill the computer by infinite loop

;IM, BF debug_print:
;Clears the first line of the screen and prints a 0-terminated String at DS:ESI

;IM, BF nanocore_getmemsize:
;BUG: This doesn't work uin VMware
;Counts the amount of memory installed in the computer





bits 32
org 0x100000
jmp nanocore_entry



;Multiboot Header
nmh_magic dd 0x1BADB002
nmh_flags dd 0x00000000
nmh_checksum dd 0xE4524FFE

nmh_header_addr dd nmh_magic
nmh_load_addr dd 0x100000
nmh_load_end_addr dd nanocore_end_kernel
nmh_bss_end_addr dd 0
entry_addr dd nanocore_entry



;Nanocore's Entry Point

nanocore_entry:
    mov esp,0x200000
    call nanocore_getmemsize
    cmp ax,0x10
   
    jl nanocore_entry.toolessmem ;comment this out if you build for VMWare
   
    jmp nanocore_entry.enoughmem ;enough...
   
    nanocore_entry.toolessmem:
    mov esi, msg_memtooless
    call debug_print ; And tell the user
    jmp nanocore_hangup ; And hang up ;)
       
    ;Here we go:
    nanocore_entry.enoughmem:
    mov esi, msg_memenough
    call debug_print
    mov esi, msg_version
    call debug_print
   
    ;call nanocore_init_mods

nanocore_hangup:
    jmp nanocore_hangup
   


debug_print:
mov edi, 0xB8000
mov ecx, 80*2*25
xor eax, eax
rep stosb
mov edi, 0xB8000
debug_print.1:
lodsb
or al, al
jz debug_print.2
stosb
mov al, 12
stosb
jmp debug_print.1
debug_print.2:
ret

nanocore_getmemsize:
    push ebp
    mov ebp, esp
    push edx
    mov eax, 0
    mov edx, 0x1EFFFC
    nanocore_getmemsize.1:
    inc eax
    mov DWORD [edx], 0xAAAAAAAA
    mov ebx, [edx]
    add edx, 0x100000
    cmp ebx, 0xAAAAAAAA
    je nanocore_getmemsize.1
    pop edx
    mov esp, ebp
    pop ebp
    ret



nanocore_data:
    msg_version db dnc_version,0
    msg_memenough db 'nanocore:You have enough RAM',0
    msg_memtooless db "nanocore:FATAL:You don't have enough RAM! Note: if you have more than 16 MB RAM, you are possibly running Delta Nanocore on VMWare. Either get the VMWare-compatible kernel or use Bochs as a virtual machine or use it on a real computer. If you still get this message, something is terribly wrong i.e., Nanocore doesn't fit your system.",0
   
   
   
   

nanocore_end_kernel:

42
Lowlevel-Coding / Code-Segment ansprechen führt zu Neustart
« am: 14. January 2005, 16:09 »
ich hatte das gleiche problem. schau dir mal GhostCoder's bootloader an, da ist das problem gelöst. ich hab einfach die gesamte routine von mir noch mal neu geschrieben, dann hats gefunzt
43
Lowlevel-Coding / Memory Mapping (ISA Hole)
« am: 09. January 2005, 14:37 »
Soweit ich weiß, geht das im BIOS. Also mit beim Starten entf drücken. Wie man das vom OS aus abschalten kann, weiß ich auch nicht.
44
Offtopic / Gmail?
« am: 08. January 2005, 16:30 »
Hab schon einen aus dem RWSBetas Board
45
Lowlevel-Coding / Delta Nanocore-Update
« am: 08. January 2005, 01:03 »
Die Projektseite ist jetzt online! Ihr könnt euch registrien, auch wenn ihr nicht mitmachen wollt. Wenn ihr mitmachen wollt, bitte email an epsilon15@gmail.com

Seite
http://www.clemensoft.de/Mambo
46
Lowlevel-Coding / Delta Nanocore
« am: 07. January 2005, 22:32 »
@joachim

Schluss mit dieser Virendiskussion, wer schreibt denn Viren für ein Betriebssystem, das von 0,00000000001% (noch hehehe...) der Menschheit benutzt wird?
47
Lowlevel-Coding / Delta Nanocore
« am: 07. January 2005, 16:26 »
@joachim_neu: die max. zeit ist so ausgelegt, dass das system noch benutzbar wird
48
Offtopic / Bestes OS für...
« am: 07. January 2005, 01:12 »
Bestes OS für einen alten Pentium MMX Laptop. Eigentlich ist er ganz okay, aber er hat nur 32 MB RAM, also kann ich Linux knicken. Aber Windows will ich auch nicht. Was soll ich nehmen bzw. wie kriege ich Linux MIT X zum Laufen?

THX.
49
Lowlevel-Coding / Delta Nanocore
« am: 07. January 2005, 00:45 »
zack heißt ja nachdem, wie sich das programm verhält
vorerst wird es gekillt.
die beste idee wäre, den user zu fragen: "Der Prozess WINWORD verhält sich wie vermutet unkooperativ. Drücken sie Beenden, um den Prozess zu beenden oder Nicht Beenden, um den Prozess trotzdem zu beenden ;-)"
50
Lowlevel-Coding / Delta Nanocore
« am: 06. January 2005, 22:13 »
@joachim_neu:
Dafür gibt es einen Timer-Interrupt, der guckt, wie lange das Programm schon rumm,acht, und wenns zulange ist, dann zAcK
51
Lowlevel-Coding / Delta Nanocore
« am: 06. January 2005, 22:04 »
@PorkChicken:

Was für eine Rede, aber ich stimme voll und ganz zu!
52
Lowlevel-Coding / Delta Nanocore
« am: 06. January 2005, 15:28 »
Ich meine mit kooperativ lediglich, dass die Anwenderprogramme dem Kernel mitteilen, wann der nächste Taskswitch erfolgen soll. Dafür kriegen Programme eine bestimmte Zeitspanne, die sie nicht überschreiten dürfen, sonst werden sie halt beendet.
53
Lowlevel-Coding / Delta Nanocore
« am: 06. January 2005, 14:18 »
Hat irgendwer Lust, dabei mitzumachen? Ich habe schon einen ftp-Server aufgesetzt, und ein Forum kommt auch bald, ebenso eine Webseite. Die Planung des Projekts wird von mir durchgeführt, an meinem Linux-Rechner, an dem regelmäßig (Immer Sonntag Vormittags) Builds durchgeführt werden.
Hier mal der Designtext

Delta Nanocore ist ein sehr sicheres Betriebssystem, obwohl es kooperatives Multitasking benutzt. Wenn Prozesse nicht kooperieren, merkt sich der Nanocore dies und killt den Prozess nach einer Bestimmten Zeit. Der Benutzer wird sofort informiert. Das Ziel ist, den Kernel möglichst klein zu halten, und alle unnötigen Funktionen in Module zu verpacken. Diese Reduzierung erfolgt bis zu einer Ebene, wo Software vollkommen Betriebssystemunabhängig laufen kann. Für diesen Nanocore werden dann Module programmiert, wie zum Beispiel Grafiktreiber oder Diskettentreiber.
Basierend auf diesem Prinzip wird eine Grafische Benutzeroberfläche programmiert, die auf bestimmte Module zurückgreift.
Der Nanocore wird von einem in zwei Stufen geteilten Loader geladen. Die erste Stufe (Stage-B) wechselt in den Protected Mode und lädt die zweite Stufe (Stage-M), einen monolithischen Kernel, der den Prozessor und andere Geräte auf Delta vorbereitet und auf Kompatibilität prüft. Ist alles ok, wird der Nanocore von Diskette oder Festplatte oder Netzwerk geladen. Er wird anhand zweier Prüfsummen analysiert (zum Beispiel auf Infektion durch Viren). Wurden Fehler festgestellt, wird der Benutzer informiert. Falls Stage-M Zugriff aufs Internet oder Netzwerk hat, wird ein aktueller Nanocore heruntergeladen und installiert. Dann werden noch die Module überprüft, die geladen werden sollen. Wird hier kein Fehler oder Inkompatibilität festgestellt, werden die Module in eigene Adressräume geladen. Jedes Modul wird initialisiert. Danach wird der Nanocore an eine bestimmte Speicheradresse geladen. Dann werden dem Nanocore an einer anderen Speicheradresse Parameter übergeben, also welches Modul (in diesem Fall das GUI) nach dem Start aufzurufen ist usw.Dann wird der Nanocore aufgerufen. Er zerstört per Speicherüberschreibung alles vom Loader. Dann schaut er in seiner Parameterliste nach, welches Modul er zuerst aufrufen soll. Dieses Modul wird dann in einen geschützten Speicherbereich geladen und ausgeführt. Dieses Sicherheitsprinzip setzt sich im ganzen System durch, alles ist isoliert, Kommunikation zwischen Objekten nur durch Pipes und System Calls.

Ich bin schon beim Coden und grade dabei, ein VESA-Modul zu schreiben.
54
Lowlevel-Coding / Pixel im VESA Modus
« am: 06. January 2005, 10:06 »
:shock: Du arbeitest im RM und benutzt einen far-Pointer auf eine 32-Bit-Adresse???
vor allem ist der Framebuffer nicht immer dort, bei mir zum Beispiel bei 0xE0000000
55
Lowlevel-Coding / Wieder mal ein paar Fragen (PMode, IDT)
« am: 04. January 2005, 10:34 »
Also: "Running in Bogus Memory heißt bei bochs, dass der Prozessor versucht hat, Code am Ende des RAMs auszuführen. Wenn du zum Beispiel deinen Bootloader irgendwo hinspringen lässt, wo nur 0 steht (beim bochsbooten der Fall), dann führt der prozessor 00 aus ( also add [bx+si],al ), bis EIP höher als der verfügbare RAM ist und der Speicher controller absagt :twisted:
56
Lowlevel-Coding / Wieder mal ein paar Fragen (PMode, IDT)
« am: 02. January 2005, 19:25 »
Bei mir hab ichs gelöst indem ich [bits 32] vor den Code gesetzt habe.
57
Offtopic / OS-Coder-Karte
« am: 02. January 2005, 14:31 »
Zitat von: sp
Hannover


NOCH EIN HANNOVERANER!
58
Lowlevel-Coding / Problem mit Floppy-Treiber
« am: 02. January 2005, 11:48 »
Meee. Das ist ja C. Trotzdem nichts schlimmes gefunden. Versuch doch mal, die genaue Stelle im Code zu finden, wo er abbricht.
59
Lowlevel-Coding / Funzt nicht?
« am: 02. January 2005, 00:24 »
00000812920p[CPU  ] >>PANIC<< jump_protected: cs == 0
00000812920i[SYS  ] Last time is 1104621686
00000812920i[CPU  ] protected mode
00000812920i[CPU  ] CS.d_b = 16 bit
00000812920i[CPU  ] SS.d_b = 16 bit
00000812920i[CPU  ] | EAX=c88e0010  EBX=0000000f  ECX=00000002  EDX=00000000
00000812920i[CPU  ] | ESP=0000fff4  EBP=00000000  ESI=00000143  EDI=0000ffe4
00000812920i[CPU  ] | IOPL=0 NV UP DI NG NZ NA PE NC
00000812920i[CPU  ] | SEG selector     base    limit G D
00000812920i[CPU  ] | SEG sltr(index|ti|rpl)     base    limit G D
00000812920i[CPU  ] |  DS:2000( 0001| 0|  0) 00020000 000fffff 1 1
00000812920i[CPU  ] |  ES:2000( 0001| 0|  0) 00020000 000fffff 1 1
00000812920i[CPU  ] |  FS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00000812920i[CPU  ] |  GS:0000( 0000| 0|  0) 00000000 0000ffff 0 0
00000812920i[CPU  ] |  SS:1000( 0000| 0|  0) 00010000 0000ffff 0 0
00000812920i[CPU  ] |  CS:2000( 0000| 0|  0) 00020000 0000ffff 0 0
00000812920i[CPU  ] | EIP=00000337 (00000332)
00000812920i[CPU  ] | CR0=0x60000011 CR1=0x00000000 CR2=0x00000000
00000812920i[CPU  ] | CR3=0x00000000 CR4=0x00000000
00000812920i[     ] restoring default signal behavior
00000812920i[CTRL ] quit_sim called with exit code 1



Laut Bochs ist also in CS noch ein RealMode-Wert drin. In DS und ES ist limit fffff im gegensatz zu den anderen. obwohl ich cs auch geladen habe, scheint es ihn nicht zu interressieren!
60
Lowlevel-Coding / Funzt nicht?
« am: 01. January 2005, 22:22 »
aber wenn ich jmp dword cs:kernel_pm mache, meckert er auch, obwohl ich in den zeilen davor cs und ds geladen habe
Seiten: 1 2 [3] 4 5

Einloggen