Nytt OS : Dvorient diskusjon

[ze5400]

".exe" er da bare en filendelse for at DOS/Windows skal vite at det er en kjørbar fil. Fila endrer ikke innhold om den slutter på ".txt" eller ".kaffe".

 

No shit da sherlock.

 

Bare sier at det er litt brød å legge seg på samme filendelse for forsjellig innehold, for det sier seg selv at GOS ikke vil kjøre exe filer i MS format

 

Men med txt er det så mye greiere, for det er jo faktisk en standard hvemsomhelst kan bruke lett

[GeirGrusom]

".exe" er da bare en filendelse for at DOS/Windows skal vite at det er en kjørbar fil. Fila endrer ikke innhold om den slutter på ".txt" eller ".kaffe".

Dette burde egenmtlig blitt klistret med store bokstaver på toppen av Programvare delen av forumet...

Jeg vet ikke hvor mange ganger for har byttet extension på f.eks. ogg til mp3 etc.

[Jaffe]

for det sier seg selv at GOS ikke vil kjøre exe filer i MS format

 

Nettopp. Derfor bør ikke filendelse ha noe å si.

 

Men med txt er det så mye greiere, for det er jo faktisk en standard hvemsomhelst kan bruke lett

8059461[/snapback]

 

Nei, det fins mange måter å lagre tekst på. (F.eks. Unicode, ASCII, Extended ASCII, osv.) Jeg har selv vært ute for å ikke kunne åpne tekstfiler ordentlig i Windows.

 

Men dette spørsmålet er jo faktisk besvart:

 

Jeg vil selsagt ikke beholde .exe filer eller .dll filer, alle henvendelser jeg bruker vil kun være som eksempel.

[GeirGrusom]

Men med txt er det så mye greiere, for det er jo faktisk en standard hvemsomhelst kan bruke lett

8059461[/snapback]

 

Nei, det fins mange måter å lagre tekst på. (F.eks. Unicode, ASCII, Extended ASCII, osv.) Jeg har selv vært ute for å ikke kunne åpne tekstfiler ordentlig i Windows.

 

Problmet her, er faktisk at det ikke er noen enkel måte å skille mellom de forkskjellige tekstformatene, hvis du åpner en UTF-8 fil, som unicode, så vil den tro den er på kinesisk eller noe, og hvordan skal programvaren forstå forskjellen? det står jo ikke i fila.

Kanskje på tide å endre på dette?

Man kan legge til et EOF symbol på slutten av fila, og legge til formatering etter det, da blir formatet bakoverkompatibelt.

Endret 2. mars 2007 av GeirGrusom

[Dead_Rabbit]

Åkey, lurer på et par ting her:

- Hvor seriøst tenker du at dette skal være?

- Hvor langt er du i requirements?

- Hvor grundig har du planlagt designet til nå?

[GeirGrusom]

Jeg tenker det som et lang-tids prosjekt, så ganske seriøst.

 

Requirements skal være fra >Pentium for jeg kan tenke meg å bruke mye extensions og slikt for å få opp hastigheten, men samtidig så er det viktig at det skal kunne kjøre på low-end maskiner.

 

Så jeg regner med at Pentium 3 er minimum, ikke fordi prosessorer under er for trege, men fordi de mangler Multimedia Extensions (MMX) og Streaming SIMMD (SSE)

 

Jeg holder på å skrive et dokument, og noen tegninger i InkScape, men jeg har ikke skrevet en linje kode enda, men jeg har lest endel.

 

edit:

 

Jeg har lastet ned 2 emulatorer, Bochs, og Open86, men jeg stoler mest på Bochs, siden den er i versjon 2.3.2 mens Open86 er i versjon 0.1

 

Jeg kommer til selv til å bruke MASM, og Visual C++ som utviklingsverktøy

Endret 2. mars 2007 av GeirGrusom

[Emancipate]

Problmet her, er faktisk at det ikke er noen enkel måte å skille mellom de forkskjellige tekstformatene, hvis du åpner en UTF-8 fil, som unicode, så vil den tro den er på kinesisk eller noe, og hvordan skal programvaren forstå forskjellen? det står jo ikke i fila.

Det er jo akkurat det det gjør. http://unicode.org/unicode/faq/utf_bom.html#BOM

 

> MASM

Anbefaler fasm, nasm eller hva som helst annet egentlig.

[j000rn]

(kunnskapstest, som i Larry kanskje? )

8055953[/snapback]

 

Som i originale Leisure Suit Larry 1 (her snakker vi 16 farger, IKKE den "nyere" VGA versjonen nei...) hvor man kunne jukse og trykke ALT+X for å slippe spørsmålene?

[GeirGrusom]

Stemmer det, men å jukse er ikke noe gøy da

Det er jo akkurat det det gjør. http://unicode.org/unicode/faq/utf_bom.html#BOM

 

> MASM

Anbefaler fasm, nasm eller hva som helst annet egentlig.

Fett, visste jeg ikke om.

 

Hmmm, jeg har lest at MASM er den beste assembleren du finner...

har nbasm og nasm fra før, men jeg har brukt mye inline assembly og masm før, og det har stort sett fungert glimrende (men den er litt dårlig dokumentert)

Endret 2. mars 2007 av GeirGrusom

[Dead_Rabbit]

Med requirements mente jeg egentlig requirements i forhold til design. Har du "kartlagt" alt som du har planer om å implementere, eller står det fortsatt litt "åpent"?

[vidarlo]

One word: Plan9. Plan9 skulle ha alt som filer, og fungerer. Ikkje finn opp hjulet på nytt, fortsett på det som finst.

 

Ellers er ikkje tanken din om å flytte funksjoner for zip-filer og slikt inn i filsystemet så eminent IMHO...

[GeirGrusom]

Designet rundt bootloaderen og memory management er vel ganske fast, siden det ikke er så fryktelig mange måter å gjøre dette på

Jeg holder på å lage skisse over hvordan programfil formatet skal se ut, men det er langt ifra ferdig kartlagt.

 

One word: Plan9. Plan9 skulle ha alt som filer, og fungerer. Ikkje finn opp hjulet på nytt, fortsett på det som finst.

 

Ellers er ikkje tanken din om å flytte funksjoner for zip-filer og slikt inn i filsystemet så eminent IMHO...

8066933[/snapback]

 

Det å lage et nytt operativsystem er å finne opp hjulet på nytt

Idéen min er å forsøke å lage et som er raskt, og enkelt i bruk.

 

Tanken med zip filer, har ingenting med filsystemet å gjøre, filsystemet er en del av "operativsystemet", som jeg mener blir forklart ganske greit hvis du tester C# consolen jeg laget.

 

Idéen er at driver skal bli devices, som blir listet i treet, det man kan gjøre, er å skrive en egen driver for spesielle filformater (zip filer f.eks.) som gjør at det vil bli en del av systemet.

Det som blir er at man må skrive en egen driver for å kjøre native code programmer, og en egen driver for å kjøre evt. VM programmer, og disse to delene skal kunne være i samme binærfil, og bli kjørt på kryss av hverandre, dette har jeg nevnt før, men bare for å gi en forståelse om at Zip filer ikke skal bli en del av filsystemet, det er ikke det som er idéen, det er bare et resultat av hvordan det hele fungerer.

 

dette blir litt vanskelig å forklare, men jeg skal jobbe litt mer på consolen, siden det er den beste måten å forklare det på.

[ze5400]

Vet du hva Geir, jo mer du sier, jo mer overbevist blir jeg på at dette er en god ide!

 

Mangler bare å få med noen tusen utviklere nå

[GeirGrusom]

hyggelig

 

Jeg har masse idéer, skal bare få skrivd dem ned

 

The executable code format will be a "group" file, wich can consist of several groups, defining code, that can be cross-accessed, and resources.

 

all datatypes are unsigned, if not otherwise noted

 

typedef dword offset

 

typedef string // null terminated ASCII string

 

enum grouptype : byte

  undefined

  native_code

  vm_code

  script

  resource

 

enum pointersize : byte

  undefined

  p8

  p16

  p20 // Intel 16-bit extended address space

  p32

  p64

 

 

file header

  dword magic = 'ownd'

  dword crc

  dword number_of_groups

  offset(groupinformation) group_list_offset

 

groupinformation

  dword crc

  dword length

  string description

  grouptype type

  pointersize ptrsize

  offset codeoffset

  dword optionaldatasize

  offset(optionaldataentry) optionaldataoffset

 

optionaldataentry

  (driver defined)

  // This section will define entrypoints, and other driver specific information

  // So the kernel will have to retrieve code offset from the driver.

  // Therfore, script engines will have to parse files first, and create a list of entrypoints, that can tell the scriptdriver to launch specfic procedures defined

  // in the script.

 

veldig tidlig, den definerer enda ikke formatet for native code filer

og jeg har lurt på om det kanskje er fornuftig å tildele filformater en GUID, for å skille dem forholdsvis enkelt fra hverandre, og for enkelt å kunne tilegne en datastrøm en driver.

Endret 4. mars 2007 av GeirGrusom

[GeirGrusom]

Vel, jeg har med suksess klart å lage en bootloader (ved å følge tutorials )

Og det var slettes ikke så vanskelig

Reglene er at det må ta 512 byte, og slutte med AA55 og det var det.

[Magnus Holm]

Kan du dele tutorial'en med oss?

[Jaffe]

Vel, jeg har med suksess klart å lage en bootloader (ved å følge tutorials )

Og det var slettes ikke så vanskelig

Reglene er at det må ta 512 byte, og slutte med AA55 og det var det.

8077005[/snapback]

 

Bootloaderen er det minste problemet ditt, da det er enkel assembly og kan gjøres med ekstremt lite kode. Det som kan bli verre, er å lage et grensesnitt mot OS-et ditt -- hvordan skal kernel osv. loades inn? Du får umulig plass til en hel filsystemdriver som skal arbeide opp mot det avanserte systemet ditt i en bootloader. Kanskje en "system initializer"-ting er noe. Den kan switche CPU-en inn i protected mode, laste kernelen (på ordentlig måte fra filsystemet), osv.

 

Bare et innspill

[Jaffe]

Kan du dele tutorial'en med oss?

8077919[/snapback]

 

Jeg har ikke noen tutorial, men her er en "bootloader" som viser en streng på skjermen:

 

CODE

bits 16 ; 16-bits kode (real mode)

org 0x7C00 ; offset 7C00 er der bootloader lastes

 

start:

mov ax, 0 ; dataene våre ligger i segment 0

mov ds, ax ; få det inn i datasegmentregisteret DS

 

mov si, streng ; adressen til strengen inn i SI

mov ah, 0x0E ; AH holder funksjonen vi vil kalle for

; å printe bokstavene i strengen

 

puts:

lodsb ; AL = bokstav i strengen som SI peker til, SI++

or al, al ; har vi nådd slutten (0)?

jz .puts_ok ; jepp, ferdig med saken

int 0x10 ; nei, vi printer bokstaven til skjermen ved å

; kalle BIOS-ens skjermkortrutiner

jmp puts ; vi kjører loopen en gang til

 

; ferdige!

.puts_ok:

jmp .puts_ok ; bare looper om igjen og om igjen...

 

; strengen som skal printes:

streng: db "Hallo fra Mr. Bootloader.", 13,10,0

 

; fyll resten (opp til 510 bytes) med 0

times 510-($-$$) db 0

 

; på slutten må vi ha en signatur (0xAA55)

dw 0xAA55

 

BIOS-en laster bootloaderen til 0x0000:0x7C00 og hopper til den, derfor settes segmentregisteret til 0 og offset til 0x7C00.

[GeirGrusom]

Det er egentlig veldig enkelt, du trenger en assembler, som nasm, og et ISO verktøy (jeg bruker PowerISO)

Du kompilerer nasm koden til en flat binærfil (/f bin)

og legger dette inn i Action->Boot->Add boot info

 

Men boot programmet må som sagt være 512 byte, og slutte på 0xAA55

 

For å kunne bruke det skikkelig, må du skru på protected mode og noe slikt, men har ikke kommet så langt enda.

 

ISO filen bruker du i Bochs som du ser jeg har gjort, jeg har kalt det CDrom foreløpig, for enkelhetsskyld, men jeg vet dette ikke vil fungere i det lange løp.

 

Synd jeg har så lite tid til å drive med dette nå, for det er veldig gøy.

Endret 4. mars 2007 av GeirGrusom

[Jaffe]

For å kunne bruke det skikkelig, må du skru på protected mode og noe slikt, men har ikke kommet så langt enda.

 

Protected mode slår du vanligvis på senere i bootprosessen, da bootloaderen har veldig begrenset med plass til det. Og protected mode må du jo simpelthen inn i ... Er ikke spesielt kjekt med 16-bits registre, 20-bits adressering, ingen multitasking, osv.