I know work in still underway to allow hijack to directly launch programs. Today, the biggest problem is that an application has to be running to bind to hijack, even if that application is not going to be used all the time. So, what about developing a small program that simply reads a list of other programs installed, then binds to hijack presenting options to run any of these programs. Lets go ahead and call it launcher for ease of discussion. When a user enters hijack and selects a program to run, launcher is triggered, and then runs the application requested.

Ideally, Launcher could also be smart enough to reattach to hijack once a program quits, thus allowing programs to run, then leave memory when not needed.

I suppose this all depends on how close hijack program launching is.

Not to rain on your parade, but...

Just what we need.. ANOTHER layer to install before a program will run...

It could be integrated into one of the existing layers.

Rain, rain, go away....

Gee, Tom, you mean like this? Forget extra layers, forget ALL of the layers except the kernel, of course. We're about 70% of the way towards a kernel that can load menu options, have those menu options run programs, etc. IANAKH but I am going to play with Kim Covil's exec patch and try to get the other 30% done anyway, unless someone beats me to it.

You guys need to pay more attention to this forum.

Gee, Tom, you mean like this?

Oops, yeah. Didn't realise it had come so far recently. Thats my fault for posting this first before I checked the unread threads. (I've had the idea for a while, just forgot to post it until today).

Well since D.Net is starting on RC5-72, I guess I should look into getting the client on the empeg again.

Although as yet I've had trouble getting any RC5-72 packets down. Not sure why.

Yep. The Launcher program you mean?

It's not actually compatible with normal Hijack applications however. You need to change the application slightly to work with Launcher. It's not hard to do however.

- Trevor

Although as yet I've had trouble getting any RC5-72 packets down. Not sure why.

Two reasons I can think of. If your going through an older personal proxy, it might not have RC5-72 blocks.

Second, if you simply upgraded your client executable without redoing your ini file. The default dns names of the RC5-72 network are a bit different. The old network had v27 somewhere in the name, the new one has v29.

I've got a few of my machines updated so far, but am holding out for better performing cores before I update some distant clients of mine.

Cheers - that makes sense. Having to go round them all! Akk, why did I remove the remotecows program anyway?