LOGRUN

Novell NetWare Login Utility for Menuing
By Dave Frailey


INTRODUCTION

A lot of network administrators like to have a menu program run automatically
after a user logs in. The natural place to ensure this happens is in the
system login script. However, what a lot of administrators don't realize is
that the login script is actually executed by the LOGIN program, ON THE REMOTE
COMPUTER, when a user logs in. The LOGIN program requires and allocates about
80k of memory to perform this function. The problem with the system login
script just going out and running your favorite menuing software is that the
LOGIN program has 80k of memory tied up at this point. What's even worse is
if the login script loads a Terminate and Stay Resident (TSR) program which
then permamently "sandwiches" LOGIN.EXE's memory, rendering it useless even
after everything is said and done, because memory is allocated in contiguous
blocks.

Novell's theory on how to have the login script run your menuing software is
to specify the name of your menu program with the EXIT login script command.
What the EXIT command actually does though is only stuff the name of the menu
program into the keyboard queue. Assuming that LOGIN.EXE was run from the Dos
command prompt this works fine when the name of the menu program is then read
out of the keyboard type-ahead queue by the command interpreter.

But what happens if LOGIN.EXE isn't run from the Dos command line?

Well when LOGIN.EXE encounters the EXIT login script command, it doesn't know
any better and goes ahead and stuffs the keyboard with the name of the menu
program, and control then returns to the process that ran LOGIN. This might
not be a rosy picture if the the characters comprising the name of the menu
program were also the same sequence of keys to delete a file....

The only solid way to run a program after Novell's LOGIN.EXE program terminates
is to trap control of the computer at the point where LOGIN.EXE is about to
return control to the previous program, and then run the program you want run.

The answer to this situation is LOGRUN. What LOGRUN does is install itself
temporarily as a TSR, directly above the memory in use by LOGIN.EXE. LOGRUN
also chains itself into the MS-Dos Function Request Dispatcher interrupt vector
so it can determine when LOGIN.EXE is about to exit. After LOGRUN is installed,
it sits dormantly, waiting for LOGIN.EXE to exit. In the mean time the login
script can go on and do any number of things, including running other external
programs. When LOGIN.EXE is about to exit, LOGRUN takes control, releases
its own memory, releases almost all of LOGIN.EXE's memory (except that needed
to hold the resident part of LOGRUN (about 1k)), and closes any files left
open by LOGIN.EXE. LOGRUN then shifts itself down to the start of LOGIN.EXE's
memory and executes whatever program names were given to it. When the first
program specified terminates, an optional second program will execute.

Command Syntax:

LOGRUN [/d][path]program.ext [parameters] [|[path]program.ext [parameters]]


A novell login script might look something like this:

#SYS:PUBLIC\LOGRUN sys:public\menu.exe %LOGIN_NAME

- or -

#SYS:PUBLIC\LOGRUN sys:public\menu.exe %LOGIN_NAME | sys:public\logout.exe

In the first example, LOGRUN will invoke Novell's menuing utility, passing it
the user's login name as the name of the menu file to use. In the second
example the same thing happens, but additionally the user is logged out
automatically when the menu utility terminates.

Note that LOGRUN must be told both the filename AND THE EXTENSION of the
program it is supposed to run when LOGIN.EXE terminates. Parameters normally
given to the program would then follow the program's name.

If the /D switch is given (which must be the first parameter encountered),
LOGRUN will not load and stay resident if a copy of dCOM is already loaded.
This allows you to have some users (who use dCOM normally as their front end)
invoke the network menuing macro from a local macro key, but for other users
not using dCOM, load dCOM and invoke your menuing macros from the login script.

LOGRUN is free software, compliments of the author. If you use it, I'd like
to hear from you. LOGRUN is copyrighted by the author, all rights reserved.



Dave Frailey
January 1992

DAC Micro Systems
40941 176th St E
Lancaster, CA 93535

Voice: 800-776-1322
BBS: 805-264-1219


Other software by the same author:

dCOM 4.0 - The Directory Commander

This is the most powerful Dos Shell and menuing system you can run on
a Novell network. It is fully NetWare aware with a full range of
security features. Its macro language (which is the underlying platform
of its menuing system) supports such powerful options as being able
to loop around any type of bindery object (similar to being able to
use a batch file FOR command against the bindery), display pop-up
selection menus using multiple mask combinations on any bindery type,
access just about any item of Dos or Novell system information with
system variables, set and access up to 64k of temporary or permanent
user variables, and so on.... All Novell login script commands are
functionally supported and execute between 10 and 100 times faster.
Conditional (nestable) IF/THEN/ELSEIF/ENDIF blocks and nestable DO,
or DO WHILE blocks let you write macros using expressions normally
only found in high-level languages - or you can use the macros as
simply as in the MS-Dos batch language.

The file handler side of dCOM can copy entire directory structures
between volumes and retain directory trustees. Additionally, it also
includes a multi-windowed text editor, print spooler, alarms/events,
and much more.

The power in dCOM can't begin to be described even if I continued to
use several more pages of this document. It is written 100% in
assembler. On 386 machines with upper memory, or on 286 machines with
the high memory area available, it uses less than 4k of conventional
memory.


XGATE 1.3 - A high powered SMTP to MHS gateway

This is a high-quality, intuitive, seamless MHS to SMTP gateway. It
requires virtually no administration (no aliasing, look-up tables,
etc...). Addressing from both sides is kept as simple as possible.
One XGATE installation can service any number of MHS hosts.

XGATE is also written in 100% assembly language.


The current shareware versions of both of these packages can be downloaded
by calling the dCOM Support BBS, and on other BBS' or Compuserve.