Quando gcc non funziona su Windows [chiuso]

Esistono molte varianti tra i sistemi operativi simili a UNIX e Windows. GCC è più comunemente usato su sistemi operativi simili a UNIX. Esistono situazioni in cui i valori predefiniti sono scelti in strumenti o codice che sono rilevanti solo per quel tipo di sistema operativo. Un semplice esempio potrebbe essere il separatore per le directory in un albero di directory. Negli ambienti DOS / Windows è un \ mentre negli ambienti UNIX è un /. Un esempio leggermente più complesso potrebbe essere una libreria alla ricerca di un'impostazione di sistema in / etc / * (posizione standard per UNIX) rispetto alla chiamata a una chiamata di sistema per recuperare tale impostazione da Windows. Tuttavia, entrambi i miei esempi qui sopra sono specificamente sul codice compilato da GCC vs VisualC e NON hanno nulla a che fare con i compilatori stessi. Molte persone confondono il compilatore con il compilatore più le librerie che sono spesso distribuite con esso. GCC compilerà il codice bene per l'uso su Windows. Il LibC di GNU di solito (non sempre) funziona per la compilazione incrociata su Windows, purché si abbia un livello intermedio per farlo funzionare come MinGW. Oltre a ciò, altre librerie che funzionano con GCC possono o non possono essere portatili, quindi usarle a proprio rischio.

Un altro modo di considerare questo problema è questo: GCC e le librerie ad esso associate spesso prendono in considerazione la portabilità e, quindi, ci permettono di scrivere codice portatile. Microsoft Visual C e le librerie ad esso associate non prendono quasi mai in considerazione la portabilità e, quindi, praticamente limitano sempre il codice a Windows. Detto questo, quale vorresti usare?

Questo è probabilmente un problema con le convenzioni di chiamata dato che Linux e Windows si differenziano nonostante si usi la stessa CPU x86. Anche con il codice generato per lo stesso set di istruzioni, due pezzi di codice compilati per diverse convenzioni di chiamata a volte non sempre sono in grado di chiamarsi l'un l'altro.

Le differenze di convenzione di chiamata si verificano di solito nel passaggio / restituzione di strutture e valori in virgola mobile e raggruppamenti di registri della CPU in salvataggi di caller vs. callee. (Quando c'è una differenza sostanziale tra le convenzioni per alcune firme, il risultato sarà spazzatura senza avviso. (Potrebbero esserci anche potenziali differenze nell'allineamento del campo nelle strutture, vale a dire dove va il riempimento).

(Windows ha anche diverse convenzioni di chiamata alternative utilizzate in alcune chiamate di sistema).

Esamina ulteriormente le "convenzioni di chiamata" e "ABI" (interfaccia binaria delle applicazioni).

Se vuoi che un programma sia portatile devi fare attenzione a rispettare le funzioni definite nello standard per il runtime C e persino quelle funzioni potrebbero comportarsi in modo leggermente diverso su Windows rispetto ad altre piattaforme. Uno dei mal di testa più comuni è che i sistemi di stile UNIX prevedono linee terminate da un avanzamento di riga, mentre Windows si aspetta una coppia di ritorno a capo / avanzamento di riga.

I sistemi operativi variano ampiamente nell'API che forniscono, quindi al di fuori del runtime standard C, non vi è alcuna garanzia che una particolare funzione sarà supportata su tutte le piattaforme. Ad esempio, la funzione fondamentale per la creazione di processi su sistemi di stile UNIX è fork() , mentre su Windows è CreateProcess() . Le due funzioni hanno comportamenti molto diversi.

Microsoft MSDN fornisce alcuni consigli sul porting tra Windows e UNIX .