Programowanie systemu operacyjnego

Cześć,
chciałbym rozwiać pewne swoje wątpliwości dotyczące programowania systemów operacyjnych. Mianowicie:

• czy przy pisaniu systemu operacyjnego można używać wszystkich funkcji ze standardowej biblioteki C?,
• czy przy pisaniu systemu operacyjnego można całkowicie obyć się bez assemblera (ew. poza samym kodem bootującym system operacyjny),
• czy żeby wyświetlać tekst na monitorze będę musiał pisać specjalne sterowniki do monitora i karty graficznej?,
• czy żeby wyświetlić punkt w określonym miejscu ekranu monitora będę musiał napisać sterowniki do monitora i karty graficznej?

Z góry dziękuję za odpowiedzi,
Pozdrawiam.

Na pierwsze nie odpowiem, ponieważ nie tworzę systemu w C, tylko w Pascalu.

czy przy pisaniu systemu operacyjnego można całkowicie obyć się bez assemblera (ew. poza samym kodem bootującym system operacyjny),

Chciałbyś :D
Tzn.nie jest go dużo, tylko parę miejsc i ew.optymalizacje.

czy żeby wyświetlać tekst na monitorze będę musiał pisać specjalne sterowniki do monitora i karty graficznej?,

Domyślny tryb to tryb tekstowy, więc wszystko (tzn.tekst) renderuje za nas BIOS.

czy żeby wyświetlić punkt w określonym miejscu ekranu monitora będę musiał napisać sterowniki do monitora i karty graficznej?

Nie nazwałbym tego sterownikiem, ale trochę z tym zabawy jest.

Polecam syscall.pl; jest tam parę takich podstawowych spraw omówionych.

• czy przy pisaniu systemu operacyjnego można używać wszystkich funkcji ze standardowej biblioteki C?,

Jeśli zaimplementujesz wszystkie zależności to raczej tak.

• czy przy pisaniu systemu operacyjnego można całkowicie obyć się bez assemblera (ew. poza samym kodem bootującym system operacyjny),

W dużej mierze tak. Nawet jeśli w jakimś miejscu potrzebujesz kodu asemblerowego, to możesz użyć intrinsics.

• czy żeby wyświetlać tekst na monitorze będę musiał pisać specjalne sterowniki do monitora i karty graficznej?,
• czy żeby wyświetlić punkt w określonym miejscu ekranu monitora będę musiał napisać sterowniki do monitora i karty graficznej?

Są pewne standardowe tryby tekstowe i graficzne - korzystając ze standardów VESA (chyba nie przekręciłem nazwy) możesz dobrać się nawet do dość wysokich trybów. Jednak bez sterowników, a co za tym idzie akceleracji 2D i 3D, wydajność będzie słaba.

Kolejny system operacyjny ? :D WyderOS-reaktywacja ? :D

• czy przy pisaniu systemu operacyjnego można używać wszystkich funkcji ze standardowej biblioteki C?,

Zwłaszcza z tych zależnych od WinApi...

• czy przy pisaniu systemu operacyjnego można całkowicie obyć się bez assemblera (ew. poza samym kodem bootującym system operacyjny),

Nie umiesz assemblera a chcesz OS pisać?

• czy żeby wyświetlać tekst na monitorze będę musiał pisać specjalne sterowniki do monitora i karty graficznej?,

Zależy jak to napiszesz... są instrukcje które pozwalają zrobić to bez pisania 'specjalnych' sterowników

• czy żeby wyświetlić punkt w określonym miejscu ekranu monitora będę musiał napisać sterowniki do monitora i karty graficznej?

Zależy jak to napiszesz... np. tryb 13h umożliwia zrobienie tego bez sterowników... ale na CUDA nie licz...

• czy przy pisaniu systemu operacyjnego można używać wszystkich funkcji ze standardowej biblioteki C?,

Zwłaszcza z tych zależnych od WinApi...

Od kiedy to WinAPI powstało przed stdlibem C?

Bartekmmms napisał(a)

• czy przy pisaniu systemu operacyjnego można używać wszystkich funkcji ze standardowej biblioteki C?

To trochę problem jajka i kury. Wiele funkcji biblioteki standardowej jest czysto algorytmiczna, nie musi używać żadnych funkcji systemu. Taką jest np. strlen().
Ale już fopen() ma otwierać plik — coś co jest ściśle zależne od mechanizmów systemu operacyjnego. Taka funkcja musi wykorzystywać API systemowe.
Przykładowo fopen pod Windowsem uruchamia systemową funkcję CreateFile — która to siłą rzeczy nie może otwierać pliku przez fopen, bo się zapętlimy. Gdzieś w końcu ten plik trzeba będzie otworzyć a nie tylko delegować zadanie do następnej funkcji (przy czym „otwarcie” pliku polega na przeprowadzeniu paru kroków: sprawdzeniu czy plik istnieje, sprawdzeniu uprawnień do niego, utworzeniu struktury zawierającej m.in. nazwę pliku, wpisaniu informacji że plik jest otwarty do jakiejś listy otwartych plików).

Przyjąć należy zasadę: piszesz system — to jednocześnie piszesz bibliotekę standardową. Ewentualnie przerabiasz pod swój system jakąś istniejącą.
Tu trzeba pamiętać, by w sytuacji jak z otwarciem pliku, to biblioteka korzystała z wywołań API systemu, a nie odwrotnie.

• czy przy pisaniu systemu operacyjnego można całkowicie obyć się bez assemblera (ew. poza samym kodem bootującym system operacyjny),
  Można minimalizować, ale całkiem zlikwidować nie — tu i ówdzie zajdzie potrzeba wygenerowania jakiejś specjalnej instrukcji procesora.

• czy żeby wyświetlać tekst na monitorze będę musiał pisać specjalne sterowniki do monitora i karty graficznej?,
  Na początek można używać przerwań BIOS-u, ale za parę lat standardem mają się stać komputery z EFI. Nie wiem jak tam wygląda kwestia wstecznej zgodności.
  Ale generalnie im bardziej złożone rzeczy będziesz chciał osiągnąć (np. grafikę) tym bardziej będzie to przypominać sterownik.
  A i nie ma czegoś takiego jak osobny „sterownik do monitora”, podobnie jak nie ma do sterowników do głośników. Monitor wyświetla co mu karta podaje. Ten „sterownik monitora” które czasem instaluje się pod windą to tak naprawdę plik konfiguracyjny z listą obsługiwanych przez monitor rozdzielczości.

Wibowit napisał(a)

Jednak bez sterowników, a co za tym idzie akceleracji 2D i 3D, wydajność będzie słaba.
Samo użycie VESY to już w zasadzie jest „pisanie sterownika”. Z wydajnością wcale nie jest aż tak tragicznie: do okienek wystarczy w zupełności, do video niekoniecznie, do 3D na pewno nie.

Bartekmmms napisał(a)

• czy żeby wyświetlić punkt w określonym miejscu ekranu monitora będę musiał napisać sterowniki do monitora i karty graficznej?
  Chcesz pisać system, a boisz się słowa „sterownik”? System operacyjny to ZNACZNIE więcej, niż jeden sterownik. Wyświetlenie punktu na ekranie z tego wszystkiego nie jest rzeczą najtrudniejszą.

Bartekmmms napisał(a)

• czy żeby wyświetlać tekst na monitorze będę musiał pisać specjalne sterowniki do monitora i karty graficznej?,

Brzmi to jakbyś miał zamiar pisać system operacyjny. Jeżeli masz poważny zamiar, to myślę, że możesz sobie odpuścić. Gdybyś miał wystarczającą wiedzę do napisania najprostszej wersji, to nie musiałbyś zadawać tych pytań

Cześć,
nie zamierzam oczywiście pisać systemu operacyjnego, ale jedynie uważam powyższe kwestie za dość ciekawe.
Dzięki za wyczerpujące odpowiedzi.
Jeszcze dwa pytania, na które chciałbym znać odpowiedź:

• jak się mają pliki wykonywalne do konkretnego systemu operacyjnego? Tzn. np. DOS umożliwia wykonywanie plików EXE, Linux ma inny format plików wykonywalnych. Jeżeli zlecam jądru wykonanie konkretnego procesu, to jaka jest jego rola w tym wszystkim, tzn. dlaczego np. DOS nie odpali wykonywalnych plików linuksowych, a Linux plików w formacie EXE? Dokładniej: jeżeli mam napisany program w języku ANSI C, to po skompilowaniu go na Linuksie i DOS-ie obie wersje dadzą identyczny rezultat wyjściowy (w sensie od strony końcowego użytkownika programu), więc gdzie i z jakiego powodu pojawiają się różnice? Czy plik wykonywalny, to zasadniczo zestaw instrukcji assemblera z jakimś "opakowaniem"?
• dlaczego sterowniki do karty graficznej umożliwią wydajniejszą obsługę grafiki niż korzystanie bezpośrednio z przerwań BIOSU.

Azarien napisał(a)

System operacyjny to ZNACZNIE więcej, niż jeden sterownik. Wyświetlenie punktu na ekranie z tego wszystkiego nie jest rzeczą najtrudniejszą.

A co jest najtrudniejszą rzeczą przy pisaniu systemu operacyjnego? Piszesz, że system operacyjny, to znacznie więcej niż jeden sterownik, ale o ile rozumiem, to masz na myśli, że system operacyjny to jeszcze system plików, zarządzanie pamięcią itd., tak? Czy do systemu operacyjnego w wersji minimum, konieczny byłby jakiś inny sterownik niż ten obsługujący system plików (chociaż chyba sterownik nie jest tu najwłaściwszą nazwą). Przez wersję minimum rozumiem, że:

• umożliwia odbieranie tekstu z klawiatury i wyświetlanie tego tekstu na ekranie,
• udostępnia mechanizm zarządzania plikami,
• udostępnia wszystkie wywołania systemowe dla wszystkich powiązanych z systemem operacyjnym funkcji określonych przez standard ANSI C
• umożliwia wykonywanie plików wykonywalnych.

Bartekmmms,
Pozdrawiam

Jeżeli zlecasz jądru wykonanie konkretnego pliku wykonywalnego, to zanim stanie się on procesem, musi zostać między innymi wczytany do pamięci. No właśnie - ale jak to zrobić? Nawet taka najprostsza rzecz - jak gdzie znajduje się faktyczny kod maszynowy i gdzie mamy zacząć jego wykonywanie - nie jest tak proste do "odgadnięcia" i musi być sprecyzowane jakimś określonym formatem - pod Windowsem PE, pod Linuksami ELF. Kolejna, wcale nie taka prosta jak na pierwszy rzut oka sprawa to biblioteki dynamiczne. W jaki sposób będą one ładowane do pamięci, w jaki sposób plik wykonywalny mówi, że będzie z nich korzystał, w jaki sposób? Kod wykonywalny też nie będzie identyczny pod dwoma systemami, bo metoda dostępu do pamięci może być inna, nawet funkcję można wywołać na kilka sposobów.

Karty graficzne dzisiaj nie tylko umożliwiają wyświetlenie pojedynczych pikseli, ale robią masę innych rzeczy (takie jak np. bardzo wydajne operacje matematyczne na wielu wektorach równocześnie), które umożliwiają specjalne sterowniki.

Jeżeli zlecam jądru wykonanie konkretnego procesu, to jaka jest jego rola w tym wszystkim, tzn. dlaczego np. DOS nie odpali wykonywalnych plików linuksowych

Pierwsza przyczyna, to że plik ma inny format (inne „opakowanie” jak to nazwałeś).
Druga to inny zestaw i inny sposób wywołania funkcji systemowego API. Tu akurat DOS i Linux mają więcej ze sobą wspólnego (przerwania) niż Windows (całe WinAPI jest w bibliotekach dynamicznych).
Trzecia to inne dostępne biblioteki: do dźwięku pod Linuksem mamy ALSA, pod Windowsem DirectSound. Pod DOS-em musieliśmy się odwoływać bezpośrednio do sprzętu, czyli w zasadzie pisać sterownik. Na szczęście była wtedy mniejsza różnorodność sprzętu i był on dobrze publicznie udokumentowany.