C++ & Asm - Prośba o wskazówki nt. własnego OS

0

Hejka :)

Wiem, że takich jak ja przewinęło się na pewno trochę osób. Ale co tam, warto pytać. Od dwóch dni szukam info nt. jak napisać własny OS. Znalazłem - wiki.osdev.org,

  • linuxfromscratch pl/org

Jest tam tak wiele informacji, że zrobiło mi się nieco przykro ;]

Co do swojego mini systemu wymagań nie mam wielkich, chciałbym jedynie, żeby się bootował, uruchomił mikro jądro i uruchomił naprawdę prosty terminal, kilka komend tylko. Zero GUI. Ogarnięcie materiału z podanych wyżej stron to kilka miesięcy, jak nie lepiej. Nie zmienia to postaci rzeczy, że i tak i tak będę nadal je przeczesywał, żeby osiągnąć swoje.

Może jest tu kto, kto ma zalążek kodu i zechciałby się podzielić? Głównie bootloader i przejście w tryb 32-bit.

Z góry dzięki za wszelkie wskazówki, i sorka jeśli zły dział :)

0

Polecam (przynajmniej na początek) pójść w stronę jądra zgodnego z multiboot. Wtedy po prostu użyjesz gruba i tę kwestię masz z głowy. Tak na dobrą sprawę z bardzo niewielkimi zmianami / kilkunastoma linijkami przekopiowanego kodu / skryptu linkera z osdev.org możesz mieć prosty kernel w C++ (!) skompilowany przy pomocy GCC albo Visual Studio.

0

Może jest tu kto, kto ma zalążek kodu i zechciałby się podzielić?

Są tysiące, jak nie dziesiątki tysięcy ludzi, którzy tworzyli/tworzą własne OS-y, duża część z nich jest open-source; wystarczy dobrze się rozejrzeć ;)
Also, są także przecież poradniki na wiki.osdev.org, w których jest napisane, jak po kolei stworzyć własnego OS-a (tzn.podstawy do systemu).

Ogarnięcie materiału z podanych wyżej stron to kilka miesięcy, jak nie lepiej.

Jeżeli bierzesz się za programowanie własnego systemu, zakładam, że znasz Assemblera oraz jakiś język wysokopoziomowy (chyba, że planujesz pisać go w samym Asmie), wtedy wystarczy po prostu ogólne zrozumienie o co chodzi, a wiele rzeczy i tak załapiesz od razu. Nikt nie każe uczyć Ci się wszystkich manuali Intela na pamięć.

0

Ja dodam, że często systemy własnej roboty mylnie nazywane są „systemami czasu rzeczywistego” (real-time OS), a przecież własny system może ale nie musi być «realtime».

0

Polecam zacząć od tego

1

Ja pisałem w oparciu o to:
http://www.brokenthorn.com/Resources/OSDevIndex.html

Całkiem przyjemne się to czytało (ale miałem już dość solidne podstawy z asm, real i protected mode itp, więc nie musiałem się wszystkiego uczyć od zera).
Spróbuj, może Ci pomoże.

0

Ja też się w tym bawię. Masz parę linków:
http://lukaszsowa.pl/2010/09/tworzenie-systemu-operacyjnego-%E2%80%93-czesc-0%C3%9701-wlaczam-komputer-i-bootloader/

http://www.returninfinity.com/pure64.html

[Link do wątku]
http://forum.programuj.com/viewtopic.php?t=14854

A jak ładujesz/ będziesz ładował krenel ???
Gotowym bootloaderem czy piszesz własny ???

0

Dziękuję wszystkim za wskazówki i za nieodsyłanie do Google ;]
Wszystko się przyda, wieczorem, gdy będzie więcej czasu, zacznę ogarniać. Tak czy owak pierwsze efekty mam ;)

Dziex jeszcze raz

0

A co myślicie o OS napisanym w Javie? Wystarczyłoby do plików OS dołączać JVM i zrobić jakoś tak, by komputer włączał JVM i system w pliku .jar i... już. Poza tym, gdzieś mi się mignął system napisany w Javie.

0

Gdyby udało się CI cx3 załadować kernela to mnie powiadom jak tego dokonałeś i jakbyś miał jakieś problemy to może rozwiązanie jest już tutaj:
http://forum.programuj.com/viewtopic.php?t=14854
http://forum.programuj.com/viewtopic.php?t=14903
http://4programmers.net/Forum/Hardware_Software/212732-ladowanie_pliku_-_fat16
A co do pytania ShookTea czy można zrobić OS w Javie to

kod źródłowy programów pisanych w Javie kompiluje się do kodu pośredniego. Powstały kod jest niezależny od systemu operacyjnego i procesora, a wykonuje go tzw. wirtualna maszyna Javy

Więc jeśli napiszesz bootloader który uruchomi mini-system który z kolei uruchomi maszynę wirtualna Javy to tak można bezie resztę OS'a pisać w Javie

Najczęściej wymienianą wadą języka Java jest to, że programy pisane w Javie wykonują się wolniej niż programy pisane w językach natywnie kompilowanych

Więc gdybyś jakimś sposobem napisał system w Javie to :
1.Mógł by "zamulić bez wyraźnej przyczyny" - przynajmniej to moje doświadczenie jeśli komputer nie ma dużo RAM
2. Java jest RAM-żerna i to tyle że klękajcie narody

0
ShookTea napisał(a)

A co myślicie o OS napisanym w Javie?

Krytyczne części systemu (jak i sama maszyna wirtualna) i tak musiałyby zostać napisane w jakimś wysokopoziomowym języku, ale ogólnie pomysł nie jest najgorszy; jedynie przesadnie skomplikowany.

Wystarczyłoby do plików OS dołączać JVM i zrobić jakoś tak, by komputer włączał JVM i system w pliku .jar i... już.

To nie kwestia "do plików OS dołączyć JVM", tylko napisania tego wszystkiego od podstaw, by cały system współgrał z tą JVM-ką.

Poza tym, gdzieś mi się mignął system napisany w Javie.

Android? :D

kacper546 napisał(a)

Najczęściej wymienianą wadą języka Java jest to, że programy pisane w Javie wykonują się wolniej niż programy pisane w językach natywnie kompilowanych

Oj no już nie przesadzajcie.
Dajcie jakieś porównanie najnowszej wersji vm-ki Javy, a nie jakiejś kilkuletniej ;)

  1. Java jest RAM-żerna i to tyle że klękajcie narody

Nawet smartfony w tej chwili mają ponad 2 GB ramu, więc nie sądzę, by było to problemem.
Poza tym, skoro jest aż tak RAM-żerna, to dlaczego pierwsze telefony obsługujące gry opierały się właśnie na JVM? ;)
Also, sam Android to jedna wielka JVM-ka i bez większych przeszkód działa nawet na mojej poczciwej Milestone z 256 MB ramu (chociaż fakt faktem, że mam zRam włączony :P).

0
Patryk27 napisał(a):
ShookTea napisał(a)

A co myślicie o OS napisanym w Javie?

Krytyczne części systemu (jak i sama maszyna wirtualna) i tak musiałyby zostać napisane w jakimś wysokopoziomowym języku, ale ogólnie pomysł nie jest najgorszy; jedynie przesadnie skomplikowany.

Wystarczyłoby do plików OS dołączać JVM i zrobić jakoś tak, by komputer włączał JVM i system w pliku .jar i... już.

To nie kwestia "do plików OS dołączyć JVM", tylko napisania tego wszystkiego od podstaw, by cały system współgrał z tą JVM-ką.

Poza tym, gdzieś mi się mignął system napisany w Javie.

Android? :D

kacper546 napisał(a)

Najczęściej wymienianą wadą języka Java jest to, że programy pisane w Javie wykonują się wolniej niż programy pisane w językach natywnie kompilowanych

Oj no już nie przesadzajcie.
Dajcie jakieś porównanie najnowszej wersji vm-ki Javy, a nie jakiejś kilkuletniej ;)

  1. Java jest RAM-żerna i to tyle że klękajcie narody

Nawet smartfony w tej chwili mają ponad 2 GB ramu, więc nie sądzę, by było to problemem.
Poza tym, skoro jest aż tak RAM-żerna, to dlaczego pierwsze telefony obsługujące gry opierały się właśnie na JVM? ;)
Also, sam Android to jedna wielka JVM-ka i bez większych przeszkód działa nawet na mojej poczciwej Milestone z 256 MB ramu (chociaż fakt faktem, że mam zRam włączony :P).

od kiedy android jest napisany w Javie? Chodzi ci może o Dalvik'a?

0

@sdfsdfs: nie musiałeś od razu całego posta cytować :P
Myślałem ofc. o tej jego maszynie wirtualnej Dalvik (de facto nie jest to "czysta" Java, ale i tak się liczy ;P).

0

Mam takie pytanie odnośnie systemów operacyjnych
Gdy piszemy własny OS to oczywiście musimy zaimplementować wyświetlanie znaków na ekran ale nie wiem czy mając własnego OS'a będę mógł korzystać powiedzmy z biblioteki Boost lub ze strumieni cout czy tez muszę je tez zaimplementować

0

Wszystko samemu.

0
kacper546 napisał(a):

musimy zaimplementować wyświetlanie znaków na ekran (...) czy mając własnego OS'a będę mógł korzystać (...) ze strumieni cout czy tez muszę je tez zaimplementować

Chyba sam sobie odpowiedziałeś :P
Wszystko pisze się od zera (chociaż niekoniecznie samemu - niektóre biblioteki można próbować portować bądź skorzystać z jakichś gotowych i przystosować pod kernel).

0

Czyli muszę jeszcze raz napisać bibliotekę boost i próbować sprawić by program napisany przy pomocy np boost działał
A te np boost musiałbym pisać w kernelu czy jak żeby program działał
Ja myślałem że w programie jest wszystko co potrzeba by działał na każdym systemie i tylko problemy pojawiały się gdy używaliśmy WinAPI a program miał działaś jeszcze np na Linuksie

1

Czyli muszę jeszcze raz napisać bibliotekę boost

Ale po co od razu portować to wszystko?
Wystarczy zaimplementować podstawowe funkcje z języka C, takie jak printf oraz inne pomniejsze, nie od razu cały zbiór bibilotek Boost.

A te np boost musiałbym pisać w kernelu czy jak żeby program działał

Nielogiczność na poziome składni tego zdania: skąd się wziął nagle jakiś "program"?
Jeżeli poprzez ten "program" rozumiesz swój kernel, to tak - musisz wszystko mieć zaimplementowane w kernelu.

Ja myślałem że w programie jest wszystko co potrzeba by działał na każdym systemie i tylko problemy pojawiały się gdy używaliśmy WinAPI a program miał działaś jeszcze np na Linuksie

Em, no technicznie tak.
W rzeczywistości wygląda to tak, że: mamy np.dwa kompilatory GCC: jeden na Windowsa, a drugi na Linuksa.
Każdy z nich ma własną definicję funkcji printf:

int printf(const char* format, ...)
{
 console_put_text(...); // przyjmijmy, że tak nazywa się funkcja WinAPI
}
int printf(const char* format, ...)
{
 /* (...) */
 do_interrupt(0x80); // przyjmijmy, że w Linuxie za wyświetlanie tekstu służy przerwanie 80h.
}

Więc taki kod:

#include <stdio.h>

int main()
{
 printf("asdf");
}

Jest technicznie przenośny między systemami (bo korzysta z przenośnej funkcji printf), o ile istnieje kompilator na dany system (bo - jak już wspomniałem - dla Ciebie ten kod wygląda identycznie, ale od środka wygląda zupełnie inaczej na różnych systemach, bo każdy system zaimplementowany jest w różny sposób i korzysta z różnych rozwiązań/nazw wewnętrznych/etc/etc).
Ty, jeżeli tworzysz swój własny system, nie masz do dyspozycji tych funkcji i musisz je ręcznie napisać.

0

Czyli przykładowo pisząc program wyświetlający tekst za pomocą funkcji printf ona tak naprawdę odwołuje się do wewnętrznego API kernela ?

0

Tak, dokładnie tak to działa.
Dlatego nie możesz w kernelu korzystać z tych funkcji dopóki ich nie popełnisz (napiszesz), bo po prostu ich nie ma.

1

console_put_text(...); // przyjmijmy, że tak nazywa się funkcja WinAPI

Z ciekawości pobawiłem się debugerem żeby zobaczyć jak to wygląda:

main -> printf -> ftbuf -> flush -> write -> write_nolock -> WriteFile -> WriteFileImplementation -> WriteConsoleA -> WriteConsoleInternal -> ConsoleClientCallServer -> NtRequestWaitReplyPort -> KiFastSystemCall

... i tu się ślad niestety urywa na instrukcji asemblera sysenter, powodującej przejście w tryb jądra.

Lasagna code ;-)

1 użytkowników online, w tym zalogowanych: 0, gości: 1