Aplikacja, platforma sprzętowa, platforma systemowa (OS)

Witam
Ciekawi mnie jedna rzecz na temat aplikacji. Programista pisze sobie aplikacje i żeby ona działała musi ja skompilować.
Wiadomo że platforma systemowa -OS (czyli system operacyjny) musi być przystosowana do platformy sprzętowej (czyli do danej architektury procesora np. x86, PowerPC, ARM itd.)
Ale jak to jest z aplikacją którą pisze się na dana platformę systemowa, ta aplikacja wystarczy że jest zgodna z systemem operacyjnym czy musi być też zgodna z platforma sprzętowa?
Bo jak wiadomo system operacyjny może byc skompilowany na kilka platform sprzętowych. Czy to ma jakieś znaczenie dla aplikacji w jakiej wersji sprzetwej jest skompilowany system?

Powiedzmy że ktoś napisał program na Linuxa a jak wiadomo linux jest kompilowany na wiele platform sprzetowych. To znaczy że jak ktoś napisze program na linuksa to on bedzie działał na każdej wersji kompilacji sprzętowej danej dystrybucji Linuksa ?
Inny przykład: Obecnie windows jest kompilowany na platformę sprzętowa x86, ale powiedzmy że microsoft umyślał sobie skompilować windowsa na PowerPC.
I co w takim razie każdy, programy napisane na windowsa bedzą działałać na każdym "Windowsie x86" i "Windows PowerPC" ?

A może to jest tak że zgodnosc musie być na wszystkich trzech stopniach: sprzet x86, system x86 i aplikacja x86 ??
A może kilka wersji działania aplikacji jest możliwych?
Będę wdzięczny jak ktoś to opisze jak to jest w rzeczywistości.
Pozdrawiam

Bo jak wiadomo system operacyjny może byc skompilowany na kilka platform sprzętowych. Czy to ma jakieś znaczenie dla aplikacji w jakiej wersji sprzetwej jest skompilowany system?

Oczywiście. Jeżeli piszesz w jakimś języku "natywnym" (kompilowanym do kodu maszynowego) to musisz program mieć skompilowany na odpowiednią architekturę sprzętową. Inaczej po prostu się nie uruchomi.

Inny przykład: Obecnie windows jest kompilowany na platformę sprzętowa x86, ale powiedzmy że microsoft umyślał sobie skompilować windowsa na PowerPC.
I co w takim razie każdy, programy napisane na windowsa bedzą działałać na każdym "Windowsie x86" i "Windows PowerPC" ?

Windows dla PPC kiedyś był dostępny ;-) Obecnie jest dla kilku architektur sprzętowych - x86, x86-64 oraz ARM.

I tutaj jest pies pogrzebany - Microsoft zrobił piękną wersję Windows dla ARM, dał ludziom... ale nic się nie da tam odpalić, bo wszystkie ("zwykłe") programy są dostępne tylko dla x86 względnie x86-64. Stąd całe kombinowanie emulacji x86 na Windows 10 dla ARM - po to, aby móc uruchamiać wszystko, co napisano dla Windows przez ostatnie dziesięciolecia. M.in. z tego powodu IA64 niezbyt się przyjęło.

Aczkolwiek jest trochę więcej kombinacji tutaj - np. wszelkie maszyny wirtualne (Java = JVM, .NET = CLR), gdzie program kompilowany jest do języka pośredniego (bajtkod, MSIL), który jest kompilowany podczas uruchamiania aplikacji dla danej platformy sprzętowej (Just-In-Time). x86-64 jest kompatybilny z x86 - w znaczeniu, że procesor uruchamia kod 32-bitowy bez problemu, ale aby zapewniać równoczesne działanie 32 i 64-bitowego kodu w Windows też jest trochę kombinowania (WOW64).

Są też pomysły w stylu "fat binary", gdzie jeden program zawiera kod dla wielu architektur, ale tego rozwiązania się raczej nie stosuje - raczej oddzielne binarki, a mechanizm instalacyjny wybierający odpowiednie dla danej architektury.

Z kolei języki interpretowane nie mają tego problemu - zadziałają wszędzie, gdzie jest interpreter.

Może ja podsumuje jak teraz to rozumiem i Ty lub ktos inny potwierdzi lub zaneguje moją wiedzę i wyjaśni wtedy.

Ja rozumiem to teraz tak że standardowo/klasycznie wygląda to tak (podam na przykładach):

Przykład A)
A1) platforma sprzętowa x86/system OS skompilowany na x86/aplikacja skompilowana na x86 - wtedy wszystko działa poprawnie
A2) platforma sprzętowa PowerPC/system OS skompilowany na PowerPC/aplikacja skompilowana na PowerPC - wtedy wszystko działa poprawnie

Na powyższych przykładach A1, A2 system OS zarządza uruchomionymi programami, przydziela dostępy do pamieć i dostępy do czasu procesora ale całość oprogramowania (OS + aplikacja) jest na tą samą platformę sprzętowa x86, PowerPC lub inne.

Przykład B)
Pewnym odstępem od powyższej reguły (przykłady A1, A2) jest system Android.
Jest on dostępny/skompilowany na dwie architektury ARM oraz x86 i ma on w sobie wbudowaną maszynę wirtualną. Programistę który pisze program nie interesuje w tym przypadku jaka bedzie platforma sprzętowa, interesuje go tylko tyle że będzie dany program kompilował na platformę systemową czyli system Android. Z tego tez powodu niezależnie od tego na jakim sprzęcie zainstalujemy Androida to każda aplikacja napisana na androida bedzie działać na każdej platformie sprzętowej.

Przykład C)
Przykład ten bedzie takim rozdrobnieniem przykładu A.
Weźmy sobie platformę sprzętowa x86. Jak wiadomo na tą platformę jest kilka systemów operacyjnych: Windows, Linux, macOS itd.
W takim przypadku oprócz tego że mamy zgodne 3 rzeczy: platforma sprzętowa, system OS i aplikację (i wydawało by się że wszystko powinno działać) może nastąpić niezgodność systemu OS i aplikacji.
Wtedy mamy taki problem że programista piszacy program musi skompilować tak program aby działał na danej platformie sprzętowej i danej platformie systemowej OS.

Rożnica w takim wypadku polega na tym, że program skompilowany na dany system operacyjny ma inaczej opakowane skompilowane dane (inne rozszerzenia plików) dostosowane do obsługi przez poszczególny system operacyjny, (np. plik wykonywalny programu dla windows ma rozszerzenie .exe, dla Linux ma rozszerzenie ...... , dla macOS ma rozszerzenie .....)
{napisałem kropki ponieważ nie znam rozszerzeń dla Linud i macOS}

================================================================================================================================================================

**Moje pytanie brzmi, czy ja dobrze rozumiem poszczególne przykłady A,B,C ?? ** (jesli dobrze prosze napisać dobrze rozumujesz, jeśli coś źle napisałem to mi to poprawcie tak jak ma być)
Pozdro i liczę na odpowiedź w tej sprawie.

Ogólnie to dobrze rozumiesz.

Android nie zawsze działa tak, jak mówisz - możliwe jest kompilowanie na Androidzie natywnych binariów dla danej architektury sprzętowej (np. tylko dla x86 albo tylko dla ARM) i wtedy takie aplikacje nie uruchomią się na innej architekturze. Pomija się wtedy całkowicie maszynę wirtualną. Mogą też być aplikacje, które same są uruchamiane na maszynie wirtualnej, ale korzystają z bibliotek skompilowanych pod konkretną architekturę.

Dość podobnie jest w Windows 10, tak nawiasem: paczka APPX zawiera binarki dla różnych architektur i system podczas instalacji tej paczki używa po prostu odpowiednich z nich.

Rożnica w takim wypadku polega na tym, że program skompilowany na dany system operacyjny ma inaczej opakowane skompilowane dane (inne rozszerzenia plików) dostosowane do obsługi przez poszczególny system operacyjny,

Tak, program na każdym systemie ma inaczej opakowane dane, ma inny format. Ale programy wykonywalne na Linuksie na przykład najczęściej nie mają rozszerzeń w ogóle :-)

Dzięki za odpowiedzi i wyrozumiałość, bo właśnie zauważyłem że mało jest jej na forach internetowych. Zawsze odsyłają do googla a nie wszystko tam jest. Wydaje mi sie że własnie po to są fora aby dopytać coś żywego człowieka, czasami nawet na własny specyficzny sposób. Wielkie dzięki i szacun.

Ktos napisał(a):

Dość podobnie jest w Windows 10, tak nawiasem: paczka APPX zawiera binarki dla różnych architektur i system podczas instalacji tej paczki używa po prostu odpowiednich z nich.

1.Wyjaśnij APPX ?)
2.Nie do końca rozumiem to co napisałeś. Aby zainstalować system trzeba zabotować go z płytki/pendriva. Na takiej płytce znajduje sie system live z instalatorem który nazywa sie WinPE.
Żeby odpalić WinPE (czyli instalator systemu) na danej architekturze sprzętowej to wymaga sie aby również WinPE było na x86 i ARM. Czyli instalator WinPE oraz już sam windows musi znajdować sie na płytce w podwójnej wersji x86 i ARM??

3. Pytanie to jest troche z innej beczki. Przegladam internet, wszędzie piszą o aplikacjach na windowsa ogólnie opisujac je jako win32. Przecież sa aplikacje 64 bitowe a nie spotkałem sie z oznaczeniem win64.
   Przykład: https://answers.microsoft.com/pl-pl/windows/forum/windows_10-windows_store-winpc/publikacja-w-windows-store-aplikacji-gry-napisanej/9f2a0fe3-1260-46a3-91b8-e2af38294419?auth=1
   Wdzięczny będę również za ta odpowiedź.

Pozdrawiam

1. APPX to format dystrybucji aplikacji dla Windows 10 (dla sklepu - Microsoft Store). W takiej paczce APPX może znajdować się wersja aplikacji dla architektury x86, x86-64 lub ARM - system podczas instalacji paczki sam wybierze taką, która pasuje do naszego systemu. Totalnie nie ma to nic wspólnego z WinPE ani instalacją systemu;
2. Akurat w przypadku Windows to na płycie jest zawsze tylko wersja dla jednej architektury (x86 lub x86-64). Po prostu jak spróbujesz odpalić płytę instalacyjną Windows x86-64 na komputerze z 32-bitowym procesorem to nie uruchomi się. Dla ARM nie istnieją płyty instalacyjne (aczkolwiek WinPE jest dostępny dla ARM - można sobie płytę z nim spreparować). Da się zrobić samemu płytę z obrazami dwóch architektur, ale uruchamia się WinPE w wersji 32-bitowej i przekopiowuje po prostu obraz 64-bitowy na dysk z tego co pamiętam;
3. Nazwa Win32 to głównie kwestia historyczna - "zwykłe" aplikacje dla Windows (korzystające ze standardowego API Windows - WinAPI) są tak określane - niezależnie od tego czy są 32 czy 64-bitowe. Samo WinAPI ma niby określenie Win64 (https://en.wikipedia.org/wiki/Windows_API#Versions), ale w praktyce chyba nie widziałem go w użyciu. Podobnie w 64-bitowym Windows katalog System32 zawiera biblioteki 64-bitowe :-) [nawiasem, to temat do którego linkujesz cytuje mój własny post z 4p ;-)]