Qual è la ragione storica di includere lo stub DOS nelle immagini PE?

Question

Qual è la ragione storica di includere lo stub DOS nelle immagini PE?

#1 da (3 voti)

1

Recentemente mi sono chiesto questa domanda. Perché le immagini PE devono essere eseguibili in MS-DOS? Ho letto sull'argomento e la maggior parte delle risposte che ho visto lo spiegano semplicemente con la compatibilità. Ma cosa significa in realtà questa compatibilità e quali obiettivi?

Se si intendeva consentire a un singolo file eseguibile sia su DOS che su Windows - qual era il problema di includere invece due eseguibili per ciascun sistema operativo?

Alcune delle risposte che ho letto spiegandole con la compatibilità affermano che se i file ".exe" erano puramente formattati nel formato COFF con la firma PE ciò avrebbe comportato un arresto anomalo nel sistema quando eseguito su DOS. Ma mi chiedevo se fosse effettivamente vero. Il controllo MS-DOS per "MZ" non era la firma iniziale e, in caso contrario, sarebbe stato troppo costoso includere tale controllo e forse un altro per stampare un messaggio simile allo stub DOS se l'immagine iniziava con "PE" ( e quindi era un eseguibile PE invece?)

windows ms-dos

posta FISOCPP 26.01.2016 - 14:53

fonte

1 risposta

Leggi altre domande sui tag windows ms-dos

Utilizzo di self.method rispetto all'ambito: metodo DSL Dove memorizzare standalone.xml e altri file in modo che sia accessibile nel mio server CI?

score 3 · Answer 1

Sì, MS-DOS includeva un controllo per la firma "MZ".

Credo che (lo stub) fosse originariamente incluso perché era una buona quantità di tempo che Windows girava interamente come una "shell" attorno a MS-DOS e le prime versioni di Windows (prima della 3.0) erano quasi inutilizzabili per l'esecuzione di MS- Programmi DOS In quanto tale, era abbastanza normale per le persone avere Windows installato, e avere programmi Windows installati, ma non eseguire la maggior parte del tempo - avevano solo avviato Windows quando eseguivano (pochi ) particolari programmi che avevano bisogno (es. Excel).

Penso che Microsoft si aspettasse che fosse (ed era corretto), e credevo che in tali circostanze era probabilmente più amichevole stampare un messaggio di errore leggibile piuttosto che morire con "non un file eseguibile valido", o qualcosa del genere su questo ordine.

C'era anche almeno una certa idea di avere degli eseguibili ibridi reali, cioè un eseguibile che conteneva un vero programma MS-DOS, quindi se lo avessi richiamato da MS-DOS, avrebbe eseguito un programma DOS per fare ciò che 'd chiesto, e se lo hai eseguito da Windows, avrebbe eseguito un programma nativo di Windows. Si noti che il supporto per questo era abbastanza limitato - il programma stub non poteva essere molto grande, quindi se aveste deciso di usarlo in questo modo nella maggior parte dei casi lo stub avrebbe probabilmente dovuto generare il programma DOS del programma, piuttosto di quanto il programma DOS sia realmente contenuto nello stub stesso.

Non so che ciò avvenga commercialmente, ma conosco un'altra variante che a volte è stata utilizzata e ha funzionato abbastanza bene: un programma stub MS-DOS che, invece di stampare semplicemente un messaggio di errore ed uscire, è stato effettivamente eseguito Windows con se stesso (cioè, questo eseguibile) sulla riga di comando, quindi richiamare il programma da un prompt dei comandi DOS lo ha ancora eseguito in Windows.