Making A Program Into A Tsr.

[Peter Smick]

I have a program I'd like to run as a TSR and launch from a network login script file (for Netware, but I don't think that matters). The program I've written runs fine, but when launched from a batch file, it does not close the CMD window automatically (these are XP workstations). I want it to close automatically so my users will stop pestering me about that new black box on their screen.

I can close the CMD window manually and the program stays loaded and working properly, and when I terminate the program from Task Manager, the CMD window closes immediately. If the batch file contains any commands after my program, they won't get run unless and until I manually terminate my program. All of this is telling me that my program is not really running as a TSR.

I am using this structure:

While 1

operative code just reads a few registry keys and overwrites

impermissible modifications made by the user.

sleep (10)

wend

EXIT

Do I need to do a lot more to get this to work as a real TSR program? Any guidelines for writing a true TSR in AutoIt?

Thanks,

Peter Smick

[Jos]

I have a program I'd like to run as a TSR and launch from a network login script file (for Netware, but I don't think that matters). The program I've written runs fine, but when launched from a batch file, it does not close the CMD window automatically (these are XP workstations). I want it to close automatically so my users will stop pestering me about that new black box on their screen.

I can close the CMD window manually and the program stays loaded and working properly, and when I terminate the program from Task Manager, the CMD window closes immediately. If the batch file contains any commands after my program, they won't get run unless and until I manually terminate my program. All of this is telling me that my program is not really running as a TSR.

I am using this structure:

While 1

operative code just reads a few registry keys and overwrites

impermissible modifications made by the user.

sleep (10)

wend

EXIT

Do I need to do a lot more to get this to work as a real TSR program? Any guidelines for writing a true TSR in AutoIt?

Thanks,

Peter Smick

TSR is something from the DOS world to me..

But I guess you want to run an AutoIt3 script from a Login script.

What command do you have in the Novell login script to start the AutoIt3 program ?

Are you shelling a Bat file from te login script?

Edited March 20, 2006 by JdeB

[GaryFrost]

you could always do a Run(@COMSPEC & ' /c your.exe",'', @SW_HIDE)

which will hide the command window

[Peter Smick]

TSR is something from the DOS world to me..

But I guess you want to run an AutoIt3 script from a Login script.

What command do you have in the Novell login script to start the AutoIt3 program ?

Are you shelling a Bat file from te login script?

Yes. The login script launches a master batch file called LOGIN.BAT which CALLs other batch files one of which runs my program. I have also tried putting my command in the LOGIN.BAT file directly (without a CALL to another batch file) with the same result. I can also run commands directly in the Netware login script, and when I put my program in there, it causes all login script processing to halt until my program is terminated from the Task Manager. So that's no good.

Next, I'll try just running the program as a startup scheduled task and see if that works better.

Thanks,

Peter.

[Jos]

Yes. The login script launches a master batch file called LOGIN.BAT which CALLs other batch files one of which runs my program. I have also tried putting my command in the LOGIN.BAT file directly (without a CALL to another batch file) with the same result. I can also run commands directly in the Netware login script, and when I put my program in there, it causes all login script processing to halt until my program is terminated from the Task Manager. So that's no good.

Next, I'll try just running the program as a startup scheduled task and see if that works better.

Thanks,

Peter.

Ok... and which Command window doesn't close ? is that the batch file that shells your AutoIt3Script ?

[GaryFrost]

Yes. The login script launches a master batch file called LOGIN.BAT which CALLs other batch files one of which runs my program. I have also tried putting my command in the LOGIN.BAT file directly (without a CALL to another batch file) with the same result. I can also run commands directly in the Netware login script, and when I put my program in there, it causes all login script processing to halt until my program is terminated from the Task Manager. So that's no good.

Next, I'll try just running the program as a startup scheduled task and see if that works better.

Thanks,

Peter.

What we did was to start the other program with from the logon batch using start so that the logon batch isn't halted by the script.

[Peter Smick]

...

Next, I'll try just running the program as a startup scheduled task and see if that works better.

Nope. That technique also halts user login as soon as the program loads, and login won't continue until the program is terminated. Rats.

[Peter Smick]

What we did was to start the other program with from the logon batch using start so that the logon batch isn't halted by the script.

I'm not familiar with "start". What is that?

[Jos]

I'm not familiar with "start". What is that?

just type HELP START in a CMD window ... its a simple way of shelling another program without waiting for its completion ...

[Peter Smick]

Ok... and which Command window doesn't close ? is that the batch file that shells your AutoIt3Script ?

It's hard for me to tell for sure. Here is how things look to be: LOGIN.BAT is the one that calls all the other batch files, and those other batch files all show their results in the single CMD window which opens with LOGIN.BAT, and that window closes properly only if my program is not launched. I never see any other CMD windows opening.

[Peter Smick]

just type HELP START in a CMD window ... its a simple way of shelling another program without waiting for its completion ...

Hey, Hey, Hey,

That one worked like a charm. Thank you muchly.

Peter.

[GaryFrost]

Hey, Hey, Hey,

That one worked like a charm. Thank you muchly.

Peter.

yw

[Peter Smick]

yw

Well. Maybe I'm asking for too much now: The program launches and runs OK, and the window closes nicely, BUT the program file stored on the network is held open on the network as though it is still in use.

If I want to modify the program, I have to find all users who have it open and close the file for each of them before I can make changes. I have gotten around this issue by copying the program at login to the user's own directory and running it from there. That way the master version is never in use and I can modify it when I need to. At next login, they'll get the revised version.

But this workaround seems clunky and also leads back to my original question. A real TSR would not behave this way, I don't think. It would load and get out of the way and the EXE file would not be held open.

Referencing something earlier in this thread: Yeah, TSR goes back to my DOS days too. Is the term "TSR" no longer in use in the modern Windows environment? If so, what replaces the term and the concept?

Anyhow, I have a workable solution, but it ain't pretty.

[GaryFrost]

Well. Maybe I'm asking for too much now: The program launches and runs OK, and the window closes nicely, BUT the program file stored on the network is held open on the network as though it is still in use.

If I want to modify the program, I have to find all users who have it open and close the file for each of them before I can make changes. I have gotten around this issue by copying the program at login to the user's own directory and running it from there. That way the master version is never in use and I can modify it when I need to. At next login, they'll get the revised version.

But this workaround seems clunky and also leads back to my original question. A real TSR would not behave this way, I don't think. It would load and get out of the way and the EXE file would not be held open.

Referencing something earlier in this thread: Yeah, TSR goes back to my DOS days too. Is the term "TSR" no longer in use in the modern Windows environment? If so, what replaces the term and the concept?

Anyhow, I have a workable solution, but it ain't pretty.

I think your confused on what TSR is

Abbreviation of terminate and stay resident. Refers to DOS programs that can be memory resident (remaining in memory at all times once they are loaded). Calendars, calculators, spell checkers, thesauruses, and notepads are often set up as TSRs so that you can instantly access them from within another program. TSRs are sometimes called pop-up programs because they can pop up in applications.

When you install a TSR, you define a special key sequence (usually a control character) that will invoke the TSR program. You can then press this hot key from within any application to run the TSR program. Many programs can be installed as a TSR, but TSRs reduce the amount of memory available to other programs. In addition, not all TSRs interact well with each other. You may have difficulties, therefore, if you try to keep too many TSRs in main memory at once.

TSRs are unnecessary with multitasking operating systems such as Windows, OS/2, and the Mac OS.

[Peter Smick]

I think your confused on what TSR is

Certainly my terminology may be outdated. But what modern term describes a Windows program which loads into memory and continues to perform its function without any further reference to, or need for having access to the EXE file that launched it? For example, I can go into my Task Manager and pick any number of currently running programs and then locate the corresponding EXE file and modify, rename or delete it without causing problems for the instance running in memory. This is the behavior I'm looking for, and probably just don't know the right name for it.

Peter.

[DaveF]

Compile your registry monitor script (mon-reg.exe) , make another script (mrcaller.exe) that will FileInstall the first to the local machine and Run it, and call the second script from the user's login script. This will free the mon-reg.exe file on the network for update and alteration.

Also, if you use the form:

@mrcaller.exe

...in the login script the NetWare login process won't halt for the execution of the task.

I'm guessing you don't run ZENWorks?

[ExSlyder]

I guess the first question would be, what does the program actually do? Does it qualify to act as a service? (The Windows Pseudo-Equivalent of a TSR). There is an application included in the Windows Server Resource Kits (Which you can download from Microsoft) and the specific program is called Instsrv - http://support.microsoft.com/default.aspx?...kb;en-us;137890 - Which will load an application as a service. But what bothers me, is that you stated that when the program is loaded by a user, it keeps the file open on the server, which tells me that if the program itself is staying resident, it requires that connection. I can't help you too much there, as at that point it's something with the coding of the actual application. But it could also be related to the way that Novell shares file handles as opposed to the way windows would. Do you have a windows server you could try having the program on and have your users call it from that location?

Thanks,

Joe

[Jos]

I guess the first question would be, what does the program actually do? Does it qualify to act as a service? (The Windows Pseudo-Equivalent of a TSR). There is an application included in the Windows Server Resource Kits (Which you can download from Microsoft) and the specific program is called Instsrv - http://support.microsoft.com/default.aspx?...kb;en-us;137890 - Which will load an application as a service. But what bothers me, is that you stated that when the program is loaded by a user, it keeps the file open on the server, which tells me that if the program itself is staying resident, it requires that connection. I can't help you too much there, as at that point it's something with the coding of the actual application. But it could also be related to the way that Novell shares file handles as opposed to the way windows would. Do you have a windows server you could try having the program on and have your users call it from that location?

Thanks,

Joe

Any compelling reason to resurrect a 2 years old thread without having a question about it?

Jos