2016-06-29 18 views
0

Klingt wie eine dumme Frage, aber ich weiß nicht, wie ich sonst fragen könnte: Ich versuche, eine Python-Bibliothek zu machen, die CPUID Codes testen und ein Ergebnis zurückgeben wird, das sowohl auf Linux als auch auf Windows funktioniert. Die einzige Möglichkeit, CPUID effizient zu nutzen, bestand darin, es in Assembler zu programmieren, also gibt es eine Möglichkeit, den Erfolg oder Misserfolg eines Programms zu testen, das auf einer Maschine unabhängig vom Betriebssystem ausgeführt wird Python extensible library oder vielmehr ein Mittel, um eine OS-unabhängige Python-Bibliothek zu erstellen?können Sie Masm in Linux kompilieren/ausführen?

Python-Dokumentation ist nicht klar, wie dies würde/würde funktionieren. Muss ich zwei Bibliotheken erstellen, ein Windows und ein Linux (ich versuche nur einen für Effizienz)?

+0

Vielleicht [Inline-Assembler] verwenden (http://stackoverflow.com/a/4474704/10077)? –

+0

[Kann nicht] (https://msdn.microsoft.com/en-us/library/4ks26t93.aspx), das Problem ist Windows verwendet proprietäre Sprache für ihre Compiler. Ich brauche die Windows-Bibliotheken, und ich weiß nicht genug über Windows-Assembly, um dies zu tun. (Beachten Sie, dass das Inline unter einer Visual Studio '15-Überschrift ist) – NationWidePants

+0

@Fred Larson braucht nur ein wenig Unterstützung/Wissen/Erleuchtung beim Cross Compilieren – NationWidePants

Antwort

5

Da ich den Vertreter nicht habe, um einen Kommentar zu schreiben, muss ich eine Antwort geben.

Der Grund, warum Sie nicht "eine (dynamische) Bibliothek haben können, um sie alle zu beherrschen" ist, weil Windows und Linux dynamische lib-Dateien (.dll, .so) als ausführbare Formate ansehen. Dynamische Windows-Bibliotheken haben den PE-Header, den Linux nicht ausführen kann, und umgekehrt müssen gemeinsam genutzte Linux-Bibliotheken den ELF-Header haben, den Windows nicht ausführen kann. Es spielt keine Rolle, ob Ihr Code zu 100% plattformunabhängig ist oder nicht.

Wie bei einer statischen Lib sollte es möglich sein, einen zu erstellen, der sowohl von Windows als auch von Linux übersetzt werden kann. Andernfalls können Sie Ihre plattformunabhängige "lib" in einem gängigen Format wie COFF oder BIN zusammenstellen und auf der Plattform verbinden, die Sie gerade verwenden. Vielleicht sogar eine Art Runtime-Linking.

Es tut mir leid, dass ich den Antwortabschnitt verwendet habe, ohne die Einzelheiten anzugeben. Aber wenn Sie nur daran interessiert sind, eine statische Lib zu erstellen, die sowohl in Linux als auch in Windows in Ihrem Code enthalten sein wird, sollte es möglich sein.

EDIT: Nach einigen Recherchen fand ich heraus, dass es nicht möglich ist, MASM zu verwenden, um eine flache binäre zusammenzusetzen. Anscheinend ist es gegen die EULA, einen zu machen? Ungeachtet des zuvor beschriebenen Prozesses, der das allgemeine Format verwendet, würde mit MASM nicht funktionieren, da es PE/COFF als Objektdateien der "niedrigsten Ebene" erzeugt.

So könnte die Lösung sein; 1) Port Ihre Baugruppe zu etwas wie NASM (Netwide Assembler), die flache Binärdateien produzieren kann.

2) Zieht die PE-Header die flachen binär, mit QuasarDonkey sehr INVOLVED Methode zu extrahieren: https://stackoverflow.com/a/26877436/6509761

Unabhängig davon, wie Sie die Wohnung binären bekommen würden Sie haben;

Unter Linux: Link die flache binäre als eine ELF-ausführbare Datei, sollte ziemlich einfach sein.

FLAT BINARY -> ELF EXECUTABLE

Unter Windows: Fügen Sie die PE/COFF-Header an den der flachen binär, und verbinden Sie sie in eine EXE/DLL-Datei. Microsoft hat diesen Prozess so ziemlich auf Sperren. Ich konnte keine Beispiele dafür finden. Aber theoretisch würde der Prozess so aussehen.

FLAT BINARY -> PE/COFF -> WINDOWS EXECUTABLE

QuasarDonkey Methode könnte eine Option für die bestimmt sein (weshalb ich es eingeschlossen), aber ich würde es nie empfehlen.

Wirklich, die einzige gerade nach vorne Option ist eine Bibliothek für Windows und eine für Linux zu kompilieren, die MASMs PE/COFF-Format als Basis unpraktikabel ist mit :)

+1

Ja, Linux dynamisch verknüpfte aka shared libraries sind [ELF "shared objects"] (http://wiki.osdev.org/ELF), daher der '.so' Dateiname. Terminologie: Was Sie "rohe Binärdateien" nennen, werden oft als "flache" Binärdateien bezeichnet. Aber ja, das '.bin' -Ausgabeformat von NASM fügt Maschinencode ohne Header in die Ausgabedatei ein. –

+2

Was das OP eigentlich tun sollte: Verwenden Sie NASM oder AT & T (GNU) -Syntax, mit Assembler-Makros zu erkennen, Windows im Vergleich zu Nicht-Windows und wählen Sie die richtige Funktion Prolog auf die rufende Konvention entsprechen. Es sollte nicht zu schwer sein, eine asm Quelldatei zu haben, aus der man eine Windows DLL oder eine Linux shared lib erzeugen kann, ohne Unsinn wie eine flache Binärdatei ohne Symbole (was ein Problem ist, wenn es mehr als eine Funktion gibt) oder irgendwelche nicht sofortigen Konstanten.) –

+0

Ich habe die meine Antwort mit den Informationen aktualisiert, die Sie in Ihrem ersten Beitrag angegeben haben. – slowvomit