py2exe service and tool-tray app combined?

[Thomas Heller]

Once again I apologize for posting this py2exe question in the ctypes list. ;-)

In the long run, this will be the wrong forum. I suggest
comp.lang.python (or should a py2exe mailing list be created?).
And I'm cc'ing to python-list.

I need to ship a Windows service in py2exe, but I also want a
tool-tray control application (I'll make with venster or win32gui)

Naturally I want to save space. Can I do this with one .exe?

It's not clear from the project page what gets executed when the
service .exe is run without -debug or -register.

Well, you can try it out. But IIRC, nothing useful will happen. The
service tries to start, but cannot because it cannot connect to the
service manager (or something like that).

Can I have a single .py file that has win32serviceutil.ServiceFramework subclass and the usual

if __name__ == "__main__":

And if I do this, how do I handle -register and -unregister?

I don't think so. But look into the C code run_svc.c to be sure.

Also, if anyone knows, I assume services don't run on 9x, so I want to 'simulate' a
service there by having the same .exe do all the work (and appear as a tooltray app),
so here's another reason for having one .exe

Can it be done?

Not sure. Best would be to change the win32all serviceutil framework.
But I'm not sure it makes sense nowadays - win98 is history.

--

And while I'm bugging the list, one thing I'd like to be able to do is
to split my application files into their own .zip distinct from 'the
python library .zip bolted onto the .exe'.

Well, I have something for you. As time permits, I'm working on a new
py2exe using the zipimport of Python 2.3. Still very much work in
progress, and services are not yet supported, but it's already in CVS in
a sandbox subdirectory.

That is, be able to define a group of .py files or packages that
should go into their own zip file outside the .exe, with that .zip
being inserted into sys.path before the .zip that's built into the
.exe

This py2exe (optionally) allows to create a number of console, gui exe
files, together with exe files implementing localserver and inproc COM
servers. The exe (or dll) files only contain the main script, or a
'boot' script for the com and service. The remaining code is loaded from
a shared zipfile.

This way, when I want to ship an 'upgrade' I most likely only need to
send a small .zip file instead of a gigantic .exe

So while declaring which packages or .py files are 'seperate' would be
a pain, I think this would be very handy for making easy-to-web-update
applications.

Comments?

This reminds me of how applications for Visual Smalltalk were
distributed. We had a small exe of only a could of kilobytes, this was
renamed into something like 'myapp.exe'. The classes neede were packed
into .sll files - smalltalk link libraries. And you had to provide a
'myapp.bnd' file which listed all the .sll files needed by 'myapp.exe'.

If you discovered a bug in an .sll file, you could either buid and
distribute a new version of it, or you could create an additional, new
..sll file containing the fixed methods. And you would make sure to list
this new .sll in the myapp.bnd file, before the buggy one. This way the
size of the upgrade could be kept as small as possible.

Now, isn't this '.bnd' file mechanism also a nice idea for py2exe?

Thomas

 

[JanC]

You don't need a tooltray to create a pseudo service on Win9x.

Not sure. Best would be to change the win32all serviceutil framework.
But I'm not sure it makes sense nowadays - win98 is history.

I know multinational companies that use Win98SE as their standard desktop
OS (one of them upgraded from Win95 last year). As they want to use the
same "environment" in every part of the world and on everything from new P4
desktops to old P2 laptops, Win2K/XP isn't an option...

 

[Brad Clements]

(moved from ctypes list)

I've taken a look at the py2exe source. What I'd like to do is combine the
functionality of run_svc.c with that of run_w.c

So for example, could I simply change run_svc.c

int main (int argc, char **argv)
{
int result;
result = init();
if (result)
return result;

if(1 < argc && !stricmp(argv[1], "-x"))
return start(argc, argv)
else
return PythonService_main(argc, argv);
}


Then link in start.c in addition to PythonService.cpp ?

This way, the generated exe could work as both a service, and a regular
application just by passing -x as the first command line option, or some
other well-defined sentinel.

I don't have the win32 source, so it's not easy for me to try. Anyone know
off-hand if start.c exports items that will collide with PythonService.cpp?