Heute habe ich auf einem Rechner ein altes Pythonprojekt von mir mit py2exe als NT-Dienst übersetzt. Nix ging: es lies sich übersetzen (mit ewig vielen Warnings wegen der Konstanten und der ümläutä - worüber gesondert zu lästern wäre). Langer (1 Stündiger) Suche kurzer Sinn: run_srv.exe aus dem py2exe-Setup für Python2.3 verlinkt auf die PyWinTypes22.dll, welche auf die python22.dll verlinkt, welche sich mit der python23.dll nicht so recht verträgt. Also sourcen laden und "setup.py build" versuchen -> brauchst du PYWIN32 Sourcen. Die Pywin32 sourcen sind riesig & ich genervt, also habe ich einfach per Hexeditor die Referenz von pywintypes22.dll auf pywintypes23.dll gepatched und voila - alles geht. So habe ich das schon mehrfach gemacht (z.B. um PIL in 2.3 benutzen dank "The Free Hexeditor" ;). Wer kann mir bitte nochmal erklären, warum man auf die ***ZENSIERT*** Idee mit "pythonxx.dll" kam (die mir so aus keinem anderen NT-Projekt bekannt ist und, so leid es mir tut, ich kenne das eine oder andere NT-Projekte seit 1994) ??? DLLs linkt man *dynamisch*, d.h. man kann auch zur Laufzeit ermitteln, ob 'ne Funktion da ist oder nicht. Und structs haben ein Size-Element. Die Win32-DLLs haben ja auch seit Menschengedenken die gleichen albernen Namen und wachsen mit jedem neuen Release um neue Funktionen. Ansonsten habe ich gestern & heute mal wieder prima Python-Erfolgserlebnisse gehabt: Danke, beste Programmiersprache der Welt! _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson.Kurz@t-online.de (Gerson Kurz) writes:
run_srv.exe aus dem py2exe-Setup für Python2.3 verlinkt auf die PyWinTypes22.dll, welche auf die python22.dll verlinkt, welche sich mit der python23.dll nicht so recht verträgt.
Warum hast Du nicht einfach PythonWin für Python 2.3 installiert?
So habe ich das schon mehrfach gemacht (z.B. um PIL in 2.3 benutzen dank "The Free Hexeditor" ;). Wer kann mir bitte nochmal erklären, warum man auf die ***ZENSIERT*** Idee mit "pythonxx.dll" kam (die mir so aus keinem anderen NT-Projekt bekannt ist und, so leid es mir tut, ich kenne das eine oder andere NT-Projekte seit 1994) ???
Was ist mit msvcrt.dll, msvcrt4.dll, msvcr7.dll, msvcr71.dll? Oder mit tcl83.dll, tcl84.dll? Die verschiedenen Python-Versionen haben schlicht und einfach verschiedene APIs - die Funktion Foo in python22.dll erwartet ein anderes Strukturlayout also die Funktion gleichen Namens in python23.dll. Anwendungen, die für python22.dll übersetzt wurden, werden also nicht mehr funktionieren und vielleicht abstürzen, wenn sie plötzlich python23.dll benutzen.
DLLs linkt man *dynamisch*, d.h. man kann auch zur Laufzeit ermitteln, ob 'ne Funktion da ist oder nicht. Und structs haben ein Size-Element.
Wo haben structs ein Size-Element? Was ist, wenn eine struct in Version 2.2 ein Feld hat, und in 2.3 dieses nämliche Feld wegoptimiert wurde?
Die Win32-DLLs haben ja auch seit Menschengedenken die gleichen albernen Namen und wachsen mit jedem neuen Release um neue Funktionen.
Ja, da garantiert Microsoft Kompatibilität - neue Funktionen heißen dann einfach CreateWindowExW oder so, während sie früher bloß CreateWindow hießen. Bei MSVC garantiert Microsoft hingegen keine Kompatibilität - die verschiedenen Versionen der C-Bibliothek sind schlicht inkompatibel, und wenn man sie mischt, passieren lauter komische Effekte. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Martin v. Löwis wrote:
Gerson Kurz writes:
DLLs linkt man *dynamisch*, d.h. man kann auch zur Laufzeit ermitteln, ob 'ne Funktion da ist oder nicht. Und structs haben ein Size-Element.
Wo haben structs ein Size-Element? Was ist, wenn eine struct in Version 2.2 ein Feld hat, und in 2.3 dieses nämliche Feld wegoptimiert wurde?
Bei vielen Windows APIs haben Structs ein Size-Element. Das erlaubt Microsoft, diese APIs schleichend durch Service-Packs zu ändern, ohne dass dies äusserlich ohne weiteres erkennbar wäre. Und in Windows wird bekanntlich nie irgendetwas wegoptimiert. Ich wollte gerade noch mehr freundliche Kommentare zu diesem Thema loswerden, aber das ist hier off-topic... -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Warum hast Du nicht einfach PythonWin für Python 2.3 installiert?
Das ist installiert (win32all155). Das ursächliche Problem war ein bug in der Binary Distribution von py2exe-0.4.1.win32-py2.3.exe: run_svc.exe linkt PyWinTypes22.dll (run.exe und runw.exe tun dies nicht), und meiner Faulheit, eine Übersetzungsorigie zu veranstalten. _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Gerson.Kurz@t-online.de (Gerson Kurz) writes:
Warum hast Du nicht einfach PythonWin für Python 2.3 installiert?
Das ist installiert (win32all155). Das ursächliche Problem war ein bug in der Binary Distribution von py2exe-0.4.1.win32-py2.3.exe: run_svc.exe linkt PyWinTypes22.dll (run.exe und runw.exe tun dies nicht), und meiner Faulheit, eine Übersetzungsorigie zu veranstalten.
Es gibt ein gefixtes binary für 2.3. Und in Zukunft braucht man wohl keine Orgie mehr um von den Sourcen zu installieren, zukünftige binäre win32all Distributionen enthalten dann wohl die benötigten Libraries - hat Mark versprochen. Und wenn man dann noch einen Preview auf die Zukunft haben will: Mark hat während meines Urlaubs einiges an einem neuen py2exe (für 2.3 only, benutzt zipimport) implementier, im CVS ist es schon im sandbox Unterverzeichnis verfügbar. Er baut die SpamBayes binaries damit. Thomas _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (4)
-
Georg Mischler -
Gerson.Kurz＠t-online.de -
martin＠v.loewis.de -
Thomas Heller