[Asembler] Programy pisane bezpośrednio dla procesora

Dzień dobry,
Mam pytanie, czemu nie tworzy się programów do otwierania bezpośrednio na procesorze, tylko wszystko jest otwierane przez system operacyjny?
Czemu system operacyjny nie ma wbudowanego mechanizmu do otwierania programów bezpośrednio dla procka?
Mam tylko podejrzenia, że chodzi o możliwość otwierania na różnym sprzęcie tego samego programu, ale i tak przecież procesory mają takie same zestawy opcode(programy pisane w asemblerze pisane 10 lat temu i tak by się uruchomiły na nowym sprzęcie), także nie rozumiem..
Będę wdzięczny za odpowiedź

Co to znaczy, że nie tworzy się programów do otwierania bezpośrednio na procesorze?
Koniec końców to przecież nic innego jak właśnie procesor przetwarza opkody.

Co to znaczy, że nie tworzy się programów do otwierania bezpośrednio na procesorze?
Koniec końców to przecież nic innego jak właśnie procesor przetwarza opkody.

Pewnie o to że system nie pozwala ci unicestwić maszyny.

w plikach exe jest gdzieś zapisany kod maszynowy samej aplikacji, ale jest też cała otoczka(samo to że jest .exe), na linuxie jest inna otoczka, w androidzie jeszcze inna.. i właśnie nie ogarniam co ta 'otoczka' takiego robi, że nie można jej po prostu zdjąć..

Ta otoczka na przykład informuje system, jakie uprawnienia aplikacja potrzebuje, jakie biblioteki do niej załadować itd.

skoro aplikacja sama może sobie nadać uprawnienia, to nie byłoby łatwiej po prostu ustawić że aplikacja może wszystko i tyle?;D
(wiem, że byłaby trochę anarchia, ale no skoro aplikacja mówi czego potrzebuje i jest jej to udostępniane, to trochę bez sensu..)
biblioteki rozumiem, oszczędzanie zasobów itp. ale w takim razie, to ta otoczka powinna być dodatkiem, a nie być obowiązkowa

A co do unicestwienia maszyny, to też się nie zgodzę.. nie mam wiele doświadczenia w programowaniu(z tego względu też takie pytania stawiam), ale już zdążyłem sobie pięknie napisać trojana, ściągającego obraz z pulpitu, mogącego sterować myszką i klawiaturą, ukryty na pasku zadań, tylko w procesach było to widać, jako "Microsoft coś tam coś".. żeby było śmieszniej, program napisany przy wykorzystaniu samego WinAPI w C++, także z tą ochroną systemu to też jakieś wielkie żarty... jedynym problemem w tym trojanie to jest to że musisz znać IP komputera komputera do któego chcesz się włamać (i to że musisz wcześniej go tam zainstalować, co akurat nie jest takie cięzkie);P ale to już inna bajka, trojan był testem, a nie funkcjonalnym programem, także nie kontynuowałem
W każdym razie, system nie kontroluje zbyt dobrze programów które się na nim instaluje/uruchamia..

Czemu tylko procesora, a co np z kartą graficzną? Ta "otoczka" o której piszesz ma właśnie przetłumaczyć to czego chce program, na to co jest w stanie zrozumieć sprzęt (układ graficzny, dźwiękowy, sieciowy itp). Zawsze pozostaje ci też https://pl.wikipedia.org/wiki/POSIX.

Czemu system operacyjny nie ma wbudowanego mechanizmu do otwierania programów bezpośrednio dla procka?

Ma.
„normalne” programy, czyli nie pisane w Javie czy C#, ale np. w C++, tzw. natywne, to są programy „bezpośrednio dla procka” - zawierające w pliku EXE gotowy kod wykonywalny procesora (te „opcode'y”).
No, prawie gotowy, bo są jeszcze relokacje, ale to powiedzmy są poprawki kosmetyczne które OS musi nanieść po załadowaniu programu a przed jego uruchomieniem.

Ale głównym zadaniem OS nie jest wcale bezpieczeństwo czy separacja jednego procesu od drugiego.
Głównym zadaniem OS jest uniezależnienie programu od konkretnego sprzętu.

Nie musisz się zastanawiać jak jest do komputera podłączona myszka, jak klawiatura, jak wyglądają ich protokoły komunikacji (zupełnie inne w przypadku USB i PS/2), jak obsługiwać kontroler USB i podłączony do niego pendrive, na którym chcemy zapisać plik, i jak wygląda system plików na tym konkretnym penie.
Jak obsłużyć kartę graficzną, dźwiękową i sieciową. Konkretny model konkretnego producenta. Jak wygląda sieciowy protokół TCP/IP.
I mnóstwo innych rzeczy, które robi za nas system operacyjny.

Twoje „programy bezpośrednio dla procka” to programy nie korzystające z systemu operacyjnego, czyli tak jakby własne systemy operacyjne.
Spoko. Można. Da się. Dzień roboty i masz hello worlda. Po tygodniu będziesz miał obsługę myszy i klawiatury. I jakiś tryb graficzny, zapewne w niskiej rozdzielczości, a o akceleracji zapomnij.

Ma to sens jeśli chcesz pisać system operacyjny, ale jeśli chcesz napisać edytor tekstu albo gierkę, to lepiej się skupić na pisaniu edytora tekstu i gierki, a nie systemu operacyjnego.

I z góry uprzedzam, że napisanie takiego własnego Windowsa czy Linuksa w pojedynkę będzie trwało mniej więcej tyle co rozbijanie diamentowej ściany pięścią.

Cholera, ktoś szybko rozgryzł że mam nikczemny plan pisania własnego OSa;P
Wiem już to wszystko o pisaniu OSa(to o diamentowej ścianie włącznie), ale nie mam planu pisać Windowsa, czy linuksa, tylko chciałbym bardziej zrobić coś w rodzaju administratora z wbudowanym kompilatorem(jeszcze nie wiem czego, może własny język;P), czyli w skład systemu ma wchodzić: kompilator, program od dzielenia czasu procka na wątki, system plików i same te takie najpotrzebniejsze sprawy, a całe GUI, zabezpieczenia itd. miałyby być oddzielnymi modułami(programami) i właśnie się zastanawiałem jak z tymi wątkami zrobić.. czy nie wystarczy wydzielić pamięci ram dla wątku wkleić tam pliku zawierającego kod maszynowy programu i włączyć.. ale faktycznie.. skąd wziąć samo to że myszkę mam na usb, a nie pod to stare wejście.. racja racja.. a do obsługi karty graficznej/dźwiękowej w asemblerze(bezpośrednio) nie doszedłem, nigdzie nie mogę znaleźć, jedyne co jest jakimś źródłem to biblioteka na C++ OpenCL.. no marnie, co poradzić.. systemy operacyjne to jest w dużej mierze monopol(rozumiem że wystarczy przeczytać dokumentacje do każdego procka, płyty głównej, dźwiękowej itp. i wszystko stanie się jasne, ale naprawdę mogliby zrobić bardziej dostępne to.. w sensie.. żeby programista chociaż wiedział co w google wpisać, żeby coś znaleźć, a nie że poświęca 2 miechy, żeby znaleźć coś co się okazuje że wystarczy wpisać "opcodes x86" i jest jako pierwszy wynik.. teraz ciekawe po ilu znajdę chociaż nazwę architektury pod GPU, nie mówiąc już o dźwiękowej.. a może okaże się, że nikt nie udostępnia dokumentacji tak po prostu i że jak wyprodukuję ten system, to będę musiał grzecznie prosić, czekać żeby kochana nvidia zmodyfikowała sterownik pod ten system, czego pewnie nie zrobi, bo się nie opłaca, bo popularność systemu = 0(ciekawe czy się skapną, że to ze względu na niską zgodność ze sterownikami).. ehh co za czasy...) Sorry za płakanie wam w ramię, ale czasem trzeba;P

Bardzo dziękuję za odpowiedzi, wiedziałem że ten ".exe" coś potrzebnego robi, teraz wiem co;D

Bardzo dziękuję za odpowiedzi, wiedziałem że ten ".exe" coś potrzebnego robi, teraz wiem co;D

Drogi Nazgul_, bardzo dobrze, że zadajesz takie pytania ponieważ aby programować na niskim poziomie pasuje znać podstawy działania komputerów i systemu. Postaram się odpowiedzieć tak ogólnie jak to tylko możliwe.

Po pierwsze, kod języka assembera to tylko tekst i dyrektywy dla programu assemblera. Niektóre mnemoniki przekładają się jeden do jednego na konkretny kod operacji ale nie musi tak być. Niektóre instrukcje to pseudo-instrukcje i assembler może je zamienić na rzeczywiste instrukcje procesora. Istnieją tylko po to by łatwiej było pisać programy.

Po drugie, wszystkie programy są wykonywane bezpośrednio przez procesor. Nawet jeśli program jest w postaci bytecode'u i wykonuje go wirtualna maszyna to "pod spodem" są instrukcje dla procesora. Nie ma innego wyjścia :).

Po trzecie, system operacyjny jest programem działającym w specjalnym trybie uprzywilejowanym (w odróżnieniu od programów użytkownika działających w trybie użytkownika). Mówiąc tryb mam na myśli tryb procesora. W takim stanie, działający program ma większy dostęp do zasobów maszyny niż aplikacja
użytkownika (np. ma dostęp do ważnych rejestrów procesora, przestrzeni adresowej w której są rejestry urządzeń, mapy pamięci, itd.). System operacyjny to tzw. jądro. W systemach Unixowych/Linuxowych np., zwykle monolityczne, rezydentne cały czas w pamięci operacyjnej. Znajdują się w nim m.in. sterowniki urządzeń, systemy plików, stosy sieciowe, urządzeń masowych itd. W skrócie jądro jest komponentem systemu, który umie gadać ze sprzętem i tworzy jego abstrakcyjny model dla programów użytkownika. Stąd np. Twój program nie musi wiedzieć w jaki sposób odczytać plik z dysku tylko korzysta z tzw. wywołania systemowego.
Nie wdając się zbytnio w szczegóły (choć i tak już za późno), system operacyjny tworzy zwirtualizowane środowisko uruchomieniowe dla wielu programów użytkownika w taki sposób, że z perspektywy programu ma on cały komputer (procesor, pamięć, urządzenia, itd.) na wyłączność. W rzeczywistości oczywiście tak nie jest a program nie musi nawet w całości znajdować się w pamięci operacyjnej w momencie uruchomienia.

Po czwarte, to co zostało nadmienione w pkt. 3 oznacza również, że program użytkownika jest odizolowany od reszty programów, w szczególności od programu jądra. Dzięki temu nie możesz np. nadpisać swoim programem, danych albo kodu programu koleżanki lub kolegi ani w szczególności uszkodzić systemu. Przynajmniej w teorii, jeśli system nie ma wad. Niedozwolona operacja skończy się albo "zabiciem" niepoprawnej aplikacji albo niepożądanym jej zachowaniem (np. będzie niepotrzebnie zabierała czas procesora) ale niczym poważniejszym.

Po piąte, w skrócie, informacje zawarte w pliku wykonywalnym są potrzebne systemowi do stworzenia wcześniej wymienionego, zwirtualizowanego środowiska uruchomieniowego. Tworzony jest nowy proces w systemie, pamięć operacyjna jest rezerwowana i inicjowana (m.in. fragmentami programu). Co warte jest zauważenia to to, że w przypadku takich języków jak np. C, gdy wszystko zostanie już przygotowane, nowy proces (program) ma zostać uruchomiony to procesor nie skacze bezpośrednio do pierwszej instrukcji zawartej w ciele funkcji main() lecz do kodu uruchomieniowego, dołączonego do każdego programu. Przeczytaj sobie co nieco o crt0.

Już na koniec tej epopei, odpowiadając na jedno z Twoich pytań to są programy działające bez systemu operacyjnego (który sam notabene działa bez systemu
operacyjnego ;-)). Np. bootloadery, firmware, aplikacje bare-metal, systemy do walidacji chipów. Tylko tak jak powiedziałem, muszą wtedy robić wszystko same i nie ma mowy o wielozadaniowości chyba, że każdy program działa na osobnym procesorze i ma z góry zarezerwowane zasoby.

Wow! Dzięki zbb, super, że tak się rozpisałeś, o wszystkim wiedziałem, ale nie miałem tak ładnie tego uporządkowanego w głowie, dzięki wielkie!
Swoją drogą fajnie, że poruszyłeś kwestię wielozadaniowości w assemblerze, bo to jest coś czego też bardzo długo szukam i nie mogę znaleźć.
Tak samo o ile dobrze wiem sam bios ma swoje przerwanie w sprawie klawiatury, to nie mogę nigdzie znaleźć jak się odwołać do samego ekranu(mam na myśli tryb graficzny)(tryb tekstowy już znalazłem;D)

Hahaha coś ze mną nie tak, najpierw piszę o trojanie w C++, a teraz czytając o tym crt0 jedyne o czym myślę, to o zarażaniu kompa w taki sposób, że podmieniamy w entry point adres funkcji main() na funkcję, którą dodamy na koniec kodu programu, a nasza funkcja włącza jakieś swoje funkcje w osobnym wątku i po włączeniu przeskakuje na adres funkcji main(tak żeby użytkownik nie ogarnął, że coś jest nie tak); P

@nazgul może żeby nie wymyślać koła na nowo rzucisz okiem na pozycje książkową forumowego kolegi @Gynvael Coldwind pod tytułem Praktyczna inżynieria wsteczna? Jest tam trochę o sposobach doczepiania sie malware do binarek. Robił też streamy na temat osdev -> no i na forum mamy też wątek Cyjon OS :)

Jeny, jesteś wielki!!!!! Bardzo Ci dziękuję;)