windows - Hvorfor er operativsystemet 'Executable files' afhængige?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg forstår, at hver CPU/arkitektur har sin egen instruktion, derfor kan et program (binært) skrevet til en bestemt CPU ikke køre på en anden. Men det jeg virkelig ikke forstår er, hvorfor en eksekverbar fil (binær som .exe for eksempel) kan ikke køre på Linux, men kan køre på vinduer selv på samme maskine.


Dette er et grundlæggende spørgsmål, og svaret, som jeg forventer, er at .exe og andre binære formater sandsynligvis ikke er rå maskininstruktioner, men de indeholder nogle data, der er afhængige af operativsystemet. Hvis dette er sandt, hvad er dette OS afhængige data for? ligesom? og som et eksempel, hvad er formatet for en .exe-fil og forskellen mellem den og Linux-eksekverbare filer?


Er der en kilde, kan jeg få korte og detaljerede oplysninger om dette?

Bedste reference


For at gøre noget meningsfuldt, skal applikationerne interface til operativsystemet. Da systemopkald og brugerrumsinfrastruktur ser grundlæggende anderledes ud på Windows og Unix/Linux, er der de mindste problemer med at have forskellige formater til eksekverbare programmer. Det er programlogikken , der skal ændres.


(Du kan nok argumentere for, at dette er meningsløst, hvis du har et program, der udelukkende afhænger af standardiserede komponenter, for eksempel C-runtime-biblioteket. Dette er teoretisk sandt - men irrelevant for de fleste applikationer, da de er tvunget til at bruge OS-afhængige ting).


De andre forskelle mellem binærerne Windows PE (EXE, DLL, ..) og Linux ELF er relateret til de forskellige billedlæssere og nogle designkarakteristika for begge operativsystemer. For eksempel på Linux bruges et separat program til at løse ekstern biblioteksimport, mens denne funktionalitet er indbygget på Windows. Et andet eksempel: Linux-delte biblioteker fungerer forskelligt end DLL'er på Windows. For ikke at nævne, at begge formater er optimeret for at gøre det muligt for de respektive OS kerner at indlæse programmer hurtigst muligt.


Emulatorer som vin forsøger at udfylde hullet ( og bevise faktisk, at det største problem ikke er det binære format, men snarere OS-grænsefladen! ).

Andre referencer 1


.exe og andre binære formater er [[absolut]] ikke rå maskininstruktioner, men de indeholder nogle data, der er afhængige af operativsystemet.



  hvad dette OS afhængige data er som? og som et eksempel, hvad er formatet for en .exe-fil og forskellen mellem den og Linux-eksekverbarheder?



Nå, jeg tror, ​​at Google mislykkedes dig helt. .EXE-formater er meget veldefinerede af Windows-dokumentation.


http://support.microsoft.com/kb/65122[10]


Linux ld applikationen lægger en eksekverbar i hukommelse forud for 'exec' til den pågældende fil. Du kan læse op på ld format eller endda den berømte a.out fil.


http://linux.die.net/man/1/ld[11]


http://en.wikipedia.org/wiki/A.out[12]


http://en.wikipedia.org/wiki/Executable[13]

Andre referencer 2


Bortset fra det eksekverbare format, der skal genkendes af systemlasteren (det vil sige den del af et operativsystem, der bringer den eksekverbare til hukommelse), er det reelle problem grænsefladen til operativsystemet. Du kan tænke på et operativsystem som en slags API, der giver adgangspunkter, som man skal opfordre til at gøre specifikke ting, som for eksempel at skrive et tegn til konsollen.


Disse oplysninger er normalt mere eller mindre skjult for slutbrugeren, så du kan opnå skrivning af et tegn på skærmen med samme kildekode på højere niveau sprog. Men ofte er tingene mere forskellige, som for eksempel Windowing-miljøet. Ikke alle sprog på højt niveau giver et vindueslag, der abstraherer endda over disse forskelle.

Andre referencer 3


Et meget naivt svar:



  1. Deres struktur er forskellig på grund af forskellige proceslastere;

  2. Brug os-afhængige funktioner som syscalls, som varierer fra OS til OS.


Andre referencer 4


Jeg kan ikke kommentere for meget på * nix, men ja, koden del af binæret er typisk glad for at køre på begge miljøer, men det er OS'et, der stiller visse krav til det binære. I Windows skal du læse på PE Headers . [14]


Den anden del er simpelthen op til bygherren, mange gange vil kodedelen henvise til libarier, der er OS-specifikke. Derfor kan du have både bærbar og ikke-bærbar C ++-kode, før du kompileres til en binær.

Andre referencer 5


Programmer skal vide, hvordan man påberåber operativsystemtjenester. Sådan gøres dette afhænger af operativsystemet: nogle brug afbrydelser, nogle bruger x86 lcall instruktionen, nogle (især Windows) har skelnet delte biblioteker og dokumenterer ikke, hvordan man direkte påberåber tjenester. Gamle 680x0 Mac'er og nogle andre 680x0 operativsystemer brugte et reserveret instruktion sæt område og fanget den resulterende 'ugyldige CPU opcode' undtagelse. Desuden, selvom mekanismen er den samme, varierer ordningsopkald og argumentformat for systemopkald mellem operativsystemer (og nogle gange forskellige versioner af samme operativsystem, se stat() i Linux-kernen for et eksempel på en grænseflade, der er ændret flere gange).


Der er en vis evne til at håndtere andre operativsystemer. Konventioner: FreeBSD har 'linuxulator', der håndterer den Linux-specifikke kerneinterface. NetBSD har tilsvarende emulatorer til systemopkaldsformaterne for andre operativsystemer ved hjælp af Den samme hardware (f.eks. Ultrix på MIPS eller OSF/1 på Alpha), Linux plejede at have iBCS2 til at håndtere UnixWare/SCO Unix-kernelgrænsefladen, Vin leverer udskiftede delte biblioteker og en binær loader til PE-stil Windows-eksekverbare filer. 'kan ikke huske, om vin også understøtter OS/2-stil LX .exe s; det håndterer sandsynligvis det originale format .exe, og så er der s .com, som er et råhukommelsesdump med en header slået på.) Alligevel er der altid et format, der bruger forskellige konventioner, og til tider er konventionerne ens nok til at kræve hints til operativsystemet om, hvordan man skal håndtere det. (Se bless på FreeBSD for eksempel.)