Markus Stenzel wrote:
Product : Experimental BitTorrent Client (c)Bram Cohen
Modified: Eike Frost http://ei.kefro.st/projects/btclient/
License : MIT
Source : Available (3.1-CVS-4, 3.2-1, 3.2.1b-1, 3.2.1b-2)
The Experimental BitTorrent is a GUI upgrade of the well known
BitTorrent file swarming application (c)Bram Cohen and released under
the MIT license.
Eike Frost modified the software to allow "bandwidth capping" to be
selected from the GUI to allow ACK messages to pass the upstream during
normal operation thus increasing overall efficiency.
However all versions mentioned above in the line starting with "Source"
_DO NOT_ run on Linux. 3.1-CVS-3, 3.2-1 and 3.2.1b-1 produce error
messages due to a few bugs handling the command line parameters.
The 3.2.1b-2 client DOES work on Linux but is running slowly and works
for single files only. When working with "batch torrents" it routinely
hangs during operation (even if it's not touched after it's launch)
The author Eike Frost doesn't offer the pre-3.1-CVS-3 source.
The windows version we have installed on Win32 is a pre 3-1-CVS-4
version. Now guess what.. ;))
> Technically it is possible, but it's not trivial, and seems like
> a pretty bizarre thing to do if the author didn't intend it to
> be used on Linux in the first place. (Which we can infer from the
> choice of distribution method.)
I hope the additional background info might make you giving a few little
hints? *hopes*
So basically the problem is that the versions for which source is available
do not work, but you have a version which works, so you'd like to try getting
it running under Linux. (?)
If that's so, maybe you can isolate the problem to a single file? Extracting
a single .pyc file from the .exe might be relatively easy, even if you had
to basically do it manually.
The packaging process used might be useful to know: was it py2exe, or the
Macmillan Installer?
Note, in case you weren't aware, that you won't actually get back the
*source*, such that you could easily modify it and recompile. You'll
get back the compiled (bytecode) file, which you could put into a .pyc
file and run in place of the "bad" .py file which you have... at least
in theory.
Retrieving the source itself is even more involved. It requires
decompiling (see "decompyle"), although if you go that route you should
get back something very close to the original. Maybe even enough for you
to do a "diff" and patch the latest version to work again?
Sounds like a lot of work though. Wouldn't it be easier to work with
the author to fix the problem in the supported versions, and use them?
-Peter
