pyinstaller und Pmw

[pythonstarter]

Hallo,
würde gerne ein Programm, das auch Pmw megawidgets enthält mit pyinstaller in eine exe.Datei umwandeln. Die exe.Datei wird auch erzeugt es kommt aber immer wieder eine Fehlermeldung, aus der ich nicht so recht schlau werde. Sicher kann mir da jemand helfen.
Danke schon mal im Voraus.

C:\Test\dist\rech.exe
Traceback <most recent call last>:
File "<string>", line 4, in m<module>
File "C:\Python27\pyinstaller-1.5\iu.py", line 436, in importHook
mod = _self_doimport<nm, ctx, fqname>
File "C:\Python27\pyinstaller-1.5\iu.py", line 521, in doimport
exec co in mod.__dict__
File "C:\Test\build\pyi.win32\rech\outPYZ1.pyz/Pmw", line 28, in <module>
WindowsError: [Error 123] Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch: 'C:\\Test\\dist\\rech.exe?819263/*.*'

Ach ja, das hab ich bereits dazu gefunden, kann aber noch nix damit anfangen.

Pmw comes with a script named bundlepmw in the bin directory. If you follow the instructions in that script, you'll end up with a module named Pmw.py. Ensure that Builder finds that module and not the development package.

[pythonstarter]

Hallo,???, weiß niemand was? Schade.

[Xynon1]

Naja, das ist auch schwer zu sagen, mir ist immer noch unklar was du eigentlich gemacht hast. Zudem gibt es kaum Menschen die Windows -> Tk -> Pwm nutzen und das ganze dann noch in eine "exe"-Datei stopfen wollen. (warum das manche wollen ist mir sowieso immer wieder unklar )

Was ist rech.exe?
Die Fehlermeldung besagt nur das der Pfad ungültig ist, was durchaus anzunehmen ist, so wie dieser aussieht.
Hast du eigentlich schon den bundlepmw-Script ausgeführt, was sagt der denn?

[pythonstarter]

Zudem gibt es kaum Menschen die Windows -> Tk -> Pwm nutzen und das ganze dann noch in eine "exe"-Datei stopfen wollen. (warum das manche wollen ist mir sowieso immer wieder unklar )

Warum Dich das wundert versteh ich nicht
Das mit der exe. , weil es leider Leute gibt, die mir mit rechter Maustast und "Edit mit Idle" im Code rumschreiben.

Was ist rech.exe?

Aus rech.py wurde rech.exe

Hast du eigentlich schon den bundlepmw-Script ausgeführt, was sagt der denn?

Der sagt: No module named regsub

[Xynon1]

Dann gib den Leuten doch einfach den Bytecode, da malt keiner drin herum.

"regsub" ist AFAIK seit Python 1.5 unötig, dafür gibt es das "re"-Modul in Python. Eventuell musst du die entsprechenden Stellen einfach umschreiben. Für gewöhnlich ist das nicht viel.

[lunar]

@pythonstarter: Es ist doch nicht Dein Problem, wenn Leute im Quelltext rumpfuschen ...

[pythonstarter]

Ja, das mit dem Bytecode ist eine sehr gute Idee - dann kann ich wirklich auf die exe verzichten. Danke schön.

[Xynon1]

Das war eigentlich ein Witz, wie lunar schon sagte, wieso ist es dein Problem wenn jemand anders in dem Quellcode rumpfuscht? Du wirst es doch wohl verkraften können das jemand anders das Programm verbessern oder an seine eigene Bedürfnisse anpassen will. Wer keine Ahnung davon hat, lässt das meist von sich aus schon bleiben und wenn doch jemand drin herumkritzeln will, dann schafft er das auch beim Byte- oder Binärkode.

[pythonstarter]

... natürlich ist es mein Problem wenn Leute im Quellcode rumkritzeln, da dann mein Programm, so wie ich es geschrieben habe und wie ich es nutzen möchte nicht mehr funktioniert (weil die Leute irgeneinen Mist damit machen) . Die Leute, die zurzeit im Quellcode rumkritzeln kommen aber nicht auf die Idee im Bytecode zu kritzeln, da sie da nicht so einfach dran kommen.

[Xynon1]

Das versteh ich nicht, wie kommen die Leute an deine Daten ran? Ich würde den höchstens lese rechte geben, dann können die sich die source ziehen und selber bastel, wo ist da das Problem?

[pythonstarter]

Ich würde den höchstens lese rechte geben,

Ich steh auf*m Schlauch - wie geb ich den Leuten denn ausschließlich Leserechte?

[problembär]

Ich finde das Anliegen, Deinen Code zu schützen, berechtigt.
Nur ist das gerade bei Python-Skripten besonders schwierig: Soweit ich weiß, ist in dem, was PyInstaller u.a. zusammenpacken, auch das Skript mit dabei, so daß andere das immer noch verändern können.
Auch der Bytecode ließe sich notfalls decompilieren.
Außerdem, wenn Du ein .pyc weitergibst, läuft das beim Anwender nur mit exakt derselben Python-Version.
Code-Obfuscation klappt bei Python auch nicht gut, wegen der klar vorgegebenen Syntax.
Ich denke, letztendlich ist es wohl nicht möglich, ClosedSource-Python-Programme zu schreiben.
Wahrscheinlich liegt das daran, daß Guido bei Google vor allem an Programme denkt, die nur serverseitig laufen, also gar nicht an die Kunden herausgegeben werden.
Anders bei Java. Da kann man ein .jar zusammenstellen, in dem sich nur kompilierter Code, also kein Source-Code, befindet (ein Beispiel für ein solches kostenloses, aber dennoch ClosedSource-Programm in Java hier). Aber für mich ist Schreiben in Java und das Verhalten der virtuellen Java-Maschine bäh.

Gruß

P.S.: Bezüglich der Ausgangsfrage zu Pmw: Manchmal nützt es auch, das Handbuch zu lesen.

[BlackJack]

@problembär: Code-Obfuscation hat doch nichts ”mit der klar vorgegebenen Syntax” zu tun — die Syntax ist auch bei anderen Programmiersprachen klar vorgegeben. Wäre dem nicht so, könnte man keinen Parser für die Sprachen schreiben und damit keinen Compiler oder Interpretierer. Ein als Bytecode ausgeliefertes Python-Programm ist ClosedSource. Also kann man selbst mit CPython schon ClosedSource-Python-Programme schreiben.

Es gibt auch Decompiler für Java-Bytecode. JARs sind in der Beziehung also nicht ”sicherer” als CPython-Bytecode.

Der Vermutung was Guido van Rossum sich dabei gedacht hat die Sprache so zu entwerfen, entbehrt ja wohl jeder rationalen Grundlage. Überleg doch bitte mal wie lange das CPython-Ökosystem mit Quelltext und Bytecode in der jetzigen Form besteht und wie verhältnismässig wenig Anteil seine Zeit bei Google daran hat.

@pythonstarter: Beschäftige Dich ein wenig mit dem Betriebssystem dass Du verwendest. Wenn jeder einfach Deine Dateien manipulieren kann, dann kann da Python nichts dafür…

[deets]

@BlackJack

Es geht hier wohl eher nicht um System-Leserechte. Xynon meinte wohl ein online-repository. Auf dem eigenen Rechner ist wohl kaum etwas nur mit reinen Leserechten versehbar, ausser das System unterstuetzt sowas mit signierten Executables oder so. Und das ist wohl hier eher nicht die Frage, und zumindest unter OSX/Linux waere mir sowas auch unbekannt.

@problembaer

Fuer Java ist dekompilation sogar noch einfacher als fuer Python, weil quasi schon in jede IDE eingebaut (respektive simpel nachruestbar als Plugin) - weil's praktisch ist.

http://java.decompiler.free.fr/?q=jdeclipse

Und code-obfuscation hat nichts mit der "klar vorgegebenen Syntax" zu tun - da geht es aussschliesslich um Bezeichnernamen, nicht um Block-Strukturen. Da haben statische Sprachen durchaus Vorteile, weil man mehr als nur reine Namens-Aequivalenz nutzen kann, und ihre geringere Dynamizitaet einem dann nicht die Fuesse zerschiesst - aber wie die vielen Javascript-Obfuscater/Komprimierer zeigen, ist das kein fundamentales Problem.

Deinen Schlussfolgerungen mangelt es also etwas an Substanz.

[Xynon1]

@problembär
Code zu schützen klappt rechtlich nur mit einer Lizenz. Wer wirklich den Code knacken will, schafft das auch mit ".exe"-Dateien (zugeben ist natürlich schwerer als den richtigen Source-Code gleich zuhaben).
Dein P.S. zeugt aber nur davon das du noch nicht mal den ersten Post gelesen hast.

@deets
Ich meinte schon Leserechte, aber im Zusammenhang das keiner was darin herum schreiben kann. Da ich nicht weiß wer alles Zugriff auf den Code hat, hatte ich es halt verallgemeinert - kann ja auch Lokal freigegeben sein und da sollte es mit der Rechte verwaltung kein Problem geben. Kommen natürlich mehrere Leute auf einen Benutzer-Account, dann kann man nur empfehlen für jeden einen eigenen Account anzulegen und das $home-Verzeichnis entsprechend sauber einteilen.
Andererseits wäre ein online-repository natürlich immer eine gute Wahl.

[deets]

@Xynon1

Naja, aber das ist ja ein bisschen sehr weit verallgemeinert. Wenn der Benutzer, der eine Software installiert hat, die Datei *anlegen* konnte, dann kann er sie auch immer veraendern. Und das ist das allgemeinste aller Szenarien.

In einer (zwangs)administrierten Umgebung ist das natuerlich machbar, weil der User die notwendigen Rechte nicht hat - aber das ist ja nun eher nur in Firmenkontexten/anderen Organisationen der Fall. Ich bezweifele, dass dies das Szenario des OP ist.

[Xynon1]

Ich weiß ja nicht wirklich was für eine Umgebung er hat, kann ja auch ein Schulnetzwerk(was dann bei dir warscheinlich unter "anderen Organisationen" fällt) sein, dort währe das sicher auch machbar.

[problembär]

@problembär
Dein P.S. zeugt aber nur davon das du noch nicht mal den ersten Post gelesen hast.

Oh, stimmt, da steht's. Na ja, werd' hier ja nicht für absolute Präzision oder auch nur überhaupt bezahlt.

Obfuscation geht in C recht gut, siehe z.B. hier, in Perl sogar sehr gut. In Python dagegen schlecht. Wenn's nicht an dem Grund liegen sollte, den ich genannt habe, dann klärt mich halt auf.

Daß man auch Java-jars einfach dekompilieren kann, wußte ich nicht. Wieder was dazugelernt.

Auf eine ausführbare C/C++-Datei einen Decompiler anzusetzen, liefert nach meiner Erfahrung allerdings völlig unbrauchbaren, weil viel zu komplizierten "Quelltext". Insofern halte ich .exe schon für relativ sicher (wenn's nicht - wie wohl bei PyInstaller - eigentlich ein gepacktes Archiv ist). Widerlegt mich mit Nachweisen, z.B. einem Link zu einem brauchbaren C/C++-Decompiler, wenn ihr könnt. Ich glaube, ihr könnt nicht.

[deets]

@problembaer

Du hast von *Java* gesprochen, und dafuer gibt es sehr brauchbare decompiler. Denn durch seine dynamische Natur (volle Reflektion) kann der Java-Compiler die ganzen Bezeichner nicht wegschmeissen. Mit Ausnahm von lokalen Variablen vielleicht, das weiss ich jetzt aus dem Kopf nicht.

Und Obfuscation ist etwas, das sich einzig und alleine auf die Bezeichner bezieht. Und damit ist Python exakt genauso gut geeignet dafuer wie jede andere dynamische Sprache.

Fuer C/C++ gibt's in der Tat keine mir bekannten de-compiler, aber davon war vorher ja auch nicht die Rede. Und es gibt durchaus leistungsfaehige Tools welche reverse-engeneering und "hacken" unterstuetzen.

[lunar]

@deets: Java-Bytecode enthalt keine lokalen Namen und keine Kommentare. Bezeichner haben allerdings wenig damit zu tun, dass man Java-Bytecode einfach rückübersetzen kann. Das liegt viel eher an der abstrakten Natur des Bytescodes, der sich fast 1:1 in Java-Quelltext abbilden lässt (schon, weil Java-Compiler keine Optimierungen durchführen). Bei C- und C++-Kompilaten ist das nicht der Fall, weil die Zielsprache Assembler wesentilch primitiver ist, und zudem oftmals weitreichende Optimierungen (bishin zu Schleifenumordnungen oder automatischen Vektorisierungen) durchgeführt werden.

Öffentliche Namen dagegen bleiben auch in den Symboltabellen von C- oder C++-Kompilaten größtenteils erhalten, lediglich auf Template-Funktionen muss man verzichten.

@problembär: Auch binäre Kompilate kann man mit Debuggern und anderen Programmen untersuchen.