Wie kann man Pythonprogramme starten, ohne Python zu install
Bei Open Source geht es, wie der Name ja schon sagt, um den Quellcode(SOURCE). Dabei ist es egal, was nach einem Kompiliervorgang am Ende für eine Code rauskommt. Du kannst denn Code immer noch unabhängig dazu online Stellen. Und das funktioniert sowohl für in C++ als auch in Assembler geschriebene Programme. Wenn du dich ein wenig umschaust, wirst du eine Menge in C++ realisierte Open-Source-Projekte finden.
-
Hannes-Spz
- User
- Beiträge: 123
- Registriert: Sonntag 7. August 2005, 22:42
so langsam wirds klar, aber ein bisschen steh ich noch auf dem schlauch - ist python denn NICHT geeignet für opensource-pojekte? das ist doch meine einzige aussage - dass es dafür geeignet ist. ist das falsch?
[size=85]"Unsere Situation ist immer die eines schwarzen Mannes der in einem schwarzen Keller einen schwarzen Hut sucht, den es vielleicht gar nicht gibt." Sir Karl R. Popper[/size]
-
lunar
*Jede* Sprache ist für freie Programme geeignet, sogar brainf*ck, auch wenn die meisten mit dem Code nichts anfangen könnenHannes-Spz hat geschrieben:so langsam wirds klar, aber ein bisschen steh ich noch auf dem schlauch - ist python denn NICHT geeignet für opensource-pojekte? das ist doch meine einzige aussage - dass es dafür geeignet ist. ist das falsch?
Du hast vorhin aber eine sehr eigenwillige Definition von Open Source gegeben, wonach jedes Programm Open Source wäre, dessen Kompilat man lesen könne. Diese Definition deckt sich aber nicht mit dem, was man gemeinhin unter "Open Source" versteht.
Open Source bezieht sich auf die Lizenz, unter der der *Quellcode* steht. Das resultierende Kompilat ist für die Lizenz des Quellcodes völlig unerheblich. Python ist also eine OpenSource-Sprache, weil der Quellcode der Referenzimplementierung CPython unter einer freien Lizenz steht, und nicht weil man aus Python-Quellcode resultierenden Bytecode relativ trivial rückübersetzen kann.
(Ich doziere doch so gerne, sorry ;)
Bytecode heißt so, weil die Maschinenbefehle typischerweise jeweils 1 Byte groß sind. Das ist sehr kompakt. Ein traditioneller Forth-Interpreter beispielsweise hat Befehle (eigentlich Sprungadressen), die ein Maschinenwort (z.B. 2 Byte auf einer 16-bit-Maschine) groß sind. Ein CISC-Prozessor wie der 80x86 hat's gemischt, ein RICS-Prozessor (etwa SPARC) hat meist einheitliche und große Befehle. Mit Bytecode meint man außerdem meist einen Befehlssatz für einen virtuellen Prozessor. Eigentlich ist auch der x86-Befehlssatz für einen virtuellen Prozessor, den längst haben die modernen Intel-Prozessoren intern einen anderen Befehlssatz und interpretieren die traditionellen Befehle durch Microcode-Makros. Man spricht hier dennoch auch von Maschinencode.
Assembler ist übrigens eine für Menschen lesbare textuelle Umschrift der Maschinenbefehle, also z.B. `LD HL, 1234H` statt der Bytefolge `213412`. Makro-Assembler fügt dann da noch einfache Abstraktionen wie das Benennen von Sprungmarken und Codeblöcken hinzu.
GCC spukt kein "Opensource" aus. GCC spuckt Maschinencode aus, im Fall von gcj auch Bytecode für die Java virtuelle Maschine (JVM). Möglicherweise gibt es andere Endstufen, ich meine mich an eine für die LLVM zu erinnern.
Eine Opensource-Lizenz kann es nur für den Quelltext geben, den man mit GCC verarbeitet hat. Diese Lizenz kann der Urheber (also Schreiber) des Quelltexts ausgeben. Was der GCC damit macht, ist unerheblich.
.dll- oder .exe-Dateien enthalten neben diversen Verwaltungsinformationen für einen Linker, der symbolische Adressen zu Betriebssystemfunktionen beim Laden automatisch auflöst, auch nur Maschinencode und diesen kann man mehr oder weniger einfach analysieren. Wer etwa in seinem Programm einen Kopierschutz einbauen will, der ungefähr so funktioniert, hat schon verloren:
So was ist leicht zu finden und man muss nur ein Byte tauschen, nämlich das von dem "jump-zero"-Befehl in einen "jump-non-zero"-Befehl, denn meist haben Prozessoren beides. Anders gesprochen: Man muss das "not" entfernen, vielleicht kann man auch diesen Befehl mit einem "no-op"-Befehl überschreiben.
Ich halte es in dem Wikipedia-Artikel für sehr unglücklich, Compiler zu erwähnen. Denn ob und wie eine Programmiersprache kompiliert wird, ist in der Regel ein Implementierungsdetail. Ob Python kompiliert wird oder nicht spielt keine Rolle, Hauptsache, das Verhalten ist wie es sein muss. Die meisten Programmiersprachen nutzen eh Mischformen, etwa in dem sie in einen Zwischencode kompilieren, der dann leider interpretiert werden kann.
Das beliebige Kopieren leitet sich IMHO nur aus dem Fakt ab, dass der Quelltext verfügbar sein muss. Da ich damit theoretisch ein neue Binärversion erstellen könnte, kann ich auch gleich diese kopieren. Es ist aber keine eigenständige Forderung. Und natürlich darf ich die Software verkaufen. Es macht eventuell nur nicht so viel Sinn, da sich mein Kunde die Software aus dem Quelltext auch selbst erstellen könnte oder dies einen dritten machen lassen kann, der es billiger oder kostenlos macht.
Übrigens: Es gibt keine Sicherheit. War das Überwinden des Xbox-Schutzes noch recht einfach, weil die Entwickler einen dummen Fehler gemacht hatten, der die "chain of trust" unterbrach, musste man für die Xbox-360 schon mal einen Prozessor Schicht für Schicht unter einem Elektronenmikroskop betrachen (wenn ich das richtig in Erinnerung habe) um so an Schlüssel zu kommen. Denn eigentlich treibt die Xbox-360 einen sehr hohen Aufwand damit etwa der Startcode niemals den Microprozessor verlässt - würde er im Hauptspeicher liegen, könnte man den Bus zwischen Prozessor und Speicher abhorchen. Am besten macht man seine Software so unattraktiv oder so günstig, dass niemand sich die Mühe macht, da einen Schutz zu umgehen. Oder aber, man hat so ein Ansehen, dass die Leute sich moralisch verpflichtet fühlen, die Software auch zu bezahlen. Das ist der IMHO beste Weg.
Schließlich: Python ist natürlich geeignet für Opensource-Projekte. Auch Microsofts C++-Compiler ist es. Wie kommst du, Hannes-Spz, zu dieser Schlussfolgerung. Die Lizenz des Compilers oder Interpreters färbt in der Regel nicht auf das ausgeführte Programm ab - oder umgekehrt.
Stefan
Bytecode heißt so, weil die Maschinenbefehle typischerweise jeweils 1 Byte groß sind. Das ist sehr kompakt. Ein traditioneller Forth-Interpreter beispielsweise hat Befehle (eigentlich Sprungadressen), die ein Maschinenwort (z.B. 2 Byte auf einer 16-bit-Maschine) groß sind. Ein CISC-Prozessor wie der 80x86 hat's gemischt, ein RICS-Prozessor (etwa SPARC) hat meist einheitliche und große Befehle. Mit Bytecode meint man außerdem meist einen Befehlssatz für einen virtuellen Prozessor. Eigentlich ist auch der x86-Befehlssatz für einen virtuellen Prozessor, den längst haben die modernen Intel-Prozessoren intern einen anderen Befehlssatz und interpretieren die traditionellen Befehle durch Microcode-Makros. Man spricht hier dennoch auch von Maschinencode.
Assembler ist übrigens eine für Menschen lesbare textuelle Umschrift der Maschinenbefehle, also z.B. `LD HL, 1234H` statt der Bytefolge `213412`. Makro-Assembler fügt dann da noch einfache Abstraktionen wie das Benennen von Sprungmarken und Codeblöcken hinzu.
GCC spukt kein "Opensource" aus. GCC spuckt Maschinencode aus, im Fall von gcj auch Bytecode für die Java virtuelle Maschine (JVM). Möglicherweise gibt es andere Endstufen, ich meine mich an eine für die LLVM zu erinnern.
Eine Opensource-Lizenz kann es nur für den Quelltext geben, den man mit GCC verarbeitet hat. Diese Lizenz kann der Urheber (also Schreiber) des Quelltexts ausgeben. Was der GCC damit macht, ist unerheblich.
.dll- oder .exe-Dateien enthalten neben diversen Verwaltungsinformationen für einen Linker, der symbolische Adressen zu Betriebssystemfunktionen beim Laden automatisch auflöst, auch nur Maschinencode und diesen kann man mehr oder weniger einfach analysieren. Wer etwa in seinem Programm einen Kopierschutz einbauen will, der ungefähr so funktioniert, hat schon verloren:
Code: Alles auswählen
gültig = komplizierteLizenzBerechnung()
if not gültig:
showDialog("Lizenz ist ungültig")
exit(1)
Ich halte es in dem Wikipedia-Artikel für sehr unglücklich, Compiler zu erwähnen. Denn ob und wie eine Programmiersprache kompiliert wird, ist in der Regel ein Implementierungsdetail. Ob Python kompiliert wird oder nicht spielt keine Rolle, Hauptsache, das Verhalten ist wie es sein muss. Die meisten Programmiersprachen nutzen eh Mischformen, etwa in dem sie in einen Zwischencode kompilieren, der dann leider interpretiert werden kann.
Das beliebige Kopieren leitet sich IMHO nur aus dem Fakt ab, dass der Quelltext verfügbar sein muss. Da ich damit theoretisch ein neue Binärversion erstellen könnte, kann ich auch gleich diese kopieren. Es ist aber keine eigenständige Forderung. Und natürlich darf ich die Software verkaufen. Es macht eventuell nur nicht so viel Sinn, da sich mein Kunde die Software aus dem Quelltext auch selbst erstellen könnte oder dies einen dritten machen lassen kann, der es billiger oder kostenlos macht.
Übrigens: Es gibt keine Sicherheit. War das Überwinden des Xbox-Schutzes noch recht einfach, weil die Entwickler einen dummen Fehler gemacht hatten, der die "chain of trust" unterbrach, musste man für die Xbox-360 schon mal einen Prozessor Schicht für Schicht unter einem Elektronenmikroskop betrachen (wenn ich das richtig in Erinnerung habe) um so an Schlüssel zu kommen. Denn eigentlich treibt die Xbox-360 einen sehr hohen Aufwand damit etwa der Startcode niemals den Microprozessor verlässt - würde er im Hauptspeicher liegen, könnte man den Bus zwischen Prozessor und Speicher abhorchen. Am besten macht man seine Software so unattraktiv oder so günstig, dass niemand sich die Mühe macht, da einen Schutz zu umgehen. Oder aber, man hat so ein Ansehen, dass die Leute sich moralisch verpflichtet fühlen, die Software auch zu bezahlen. Das ist der IMHO beste Weg.
Schließlich: Python ist natürlich geeignet für Opensource-Projekte. Auch Microsofts C++-Compiler ist es. Wie kommst du, Hannes-Spz, zu dieser Schlussfolgerung. Die Lizenz des Compilers oder Interpreters färbt in der Regel nicht auf das ausgeführte Programm ab - oder umgekehrt.
Stefan
nicht mehr nötig. du kannst die x-box jetzt programmieren und aushorchen.Es gibt keine Sicherheit. War das Überwinden des Xbox-Schutzes noch recht einfach, weil die Entwickler einen dummen Fehler gemacht hatten, der die "chain of trust" unterbrach, musste man für die Xbox-360 schon mal einen Prozessor Schicht für Schicht unter einem Elektronenmikroskop betrachen (wenn ich das richtig in Erinnerung habe) um so an Schlüssel zu kommen.
es gibt dafür jetzt einen schönen c-compiler zu kaufen.
die rechte der programme zur veröffnetlichung bleiben bis zum erwerb einer lizens für das entwickelte programm immer bei ms.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das es XNA gibt ist schon klar, aber das ermöglicht einem nicht in dem Maß kontrolle über die Hardware um etwa ein Linux draufzubooten. Darum ging es.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice