The problem with a screen saver is that you have to somehow suspend its operation when someone moves the mouse. If you have some way to remotely suspend and continue these scripts, why not just run them (and suspend them) from the scheduler that's already built into NT?
If you have the memory, you could also start up the processes using the IDLE priority class and just leave them going. Users wouldn't notice any interference, other than the memory would be reduced. | [reply] |
Another alternative would be to use perl2exe to so-called compile your perl program into an executable.
I hear a lot of "so, what good does that do in this case"
The fact is that Windows (at least NT and 2k) will run an exe as a screen saver, as long as the exe has been renamed to a .scr extension.
Really, give it a try, rename a copy of cmd.exe to ssmyscreen.scr and hit the screensaver tab of display properties. This is actually pretty scary behaviour. Just for fun one time, rename login.scr to login.old and cmd.exe to login.scr, logout and wait ;-> | [reply] |
In principle you could build your perl project into an activeX object with the ActiveState toolkit and then include that in a VD or VC++ project (sample code for VB screen savers are pretty common). | [reply] |
It seems to me that Perl is not the language for a massive number crunching problem. Why not have Perl parse out the values and then feed a C or FORTRAN subroutine to do the crunching? It might speed it up so much you don't need to go to so much trouble.
I like the idea of just running it at a very low priority. Don't bother with the screensaver; just let it start pulling when the computer has nothing better to do.
—John | [reply] |
