Instructions for interfacing the 'network disk' version of APPX
for Windows with the UniQue print spooler can be found here.
2.8) Can I intercept a print file before it is sent to the printer, and do
something to it (like add font setup codes)?
Yes. By default, APPX sends its print files to winprint.exe.
However, by setting the environment variable APPX_PRT_SCRIPT to
the name of an alternate print file processing program (or .bat
file), it is possible to customize print file handling. This
variable MUST be set on the server, and its new value will not
be in effect for any APPX sessions until the server machine is
rebooted.
For example, if you set APPX_PRT_SCRIPT=mycustom.exe, and are
printing a file named 'prntfile', APPX will invoke your custom
print file processor with the command line:
mycustom.exe -config=prntfile.cfg prntfile
Inside mycustom.exe, you can inspect the file name, the contents
of the file itself, and/or the contents of the config file, to
programmatically add printer-specific font switching or other
control codes. You can then copy the modified file back to its
original name and from inside mycustom.exe, invoke the command:
winprint.exe -config=prntfile.cfg prntfile
on it to cause APPX to print the file, or do something else if
you prefer.
2.9) I get Dr. Watson errors when running APPX. Help?
When APPX gets certain kinds of errors, it crashes. There is
code in the APPX engine to write out a stack trace whenever a
"trappable" crash occurs. However, if Dr. Watson is enabled
on your system (as it is on most), the crash will cause Dr.
Watson to be invoked, rather than write out the stack trace.
APPX Software often needs the stack trace to diagnose software
failures. Therefore, if you are working with ASI to debug an
error that causes an APPX crash, please turn off Dr. Watson at
least temporarily, in order to permit APPX to write out the
stack trace.
2.10) How can I tell what versions of UniQue and OpenNT/Interix
I am running?
The version of OpenNT can be gotten from the registry key:
\HKEY_LOCAL_MACHINE\SOFTWARE\Softway Systems\Interix
(As of 3/14/1999, the newest version is 2.2.400).
The following
Command will show the UniQue Version number:
\OpenNT\usr\spool\uprint\ulp -h
(As of 3/14/1999, the newest version is 3.31_25).
2.11) It takes a long time to start APPX from a client PC using the
Win32 or Java client, but after it finally lets us login,
performance is OK. Help?
Name resolution failures generally take a bit more than 2.5 minutes
(means you have a problem with name resolution on either the client
or server) or a bit more than 5 minutes (means both sides have a
name resolution problem), give or take a minute. [ 2.5 minutes is
approximately the time it takes for a DNS query to time out. ]
To diagnose if you have a name resolution issue, you DO NOT need
fancy network monitors and experts and the like. All you need is
"ping", the hostname and IP address of your APPX Server and (if
running the APPX Server on NT) the hostname and IP address of your
Primary Domain Controller (and any Backup Domain Controllers that
exist). You can get a machine's IP address by running "ipconfig"
at the command prompt and picking the internal network interface
(that is, not the one that starts 224, or 127, or the one labeled
dialup adapter!). Do the following tests:
1. Check that the client can resolve the APPX Server's host name.
Sit down at a client that is taking a long time to connect to
APPX. ping your APPX server (the one specified in the login
box when you start up APPX) by NAME and by IP address. If the
ping by IP address comes back in a second or two, and the
ping by name takes a while, the client has a name resolution
problem. This typically means that the DNS servers specified
on the client machine do not know about the server (often the
case in situations like the above where only Internet DNS is
used, and one is on an internal network; also can be the case
if there is a local DNS server but the APPX server machine is
new and its name hasn't been added to it yet; also can be the
case if the list of DNS servers on the client is incomplete.)
If after fixing the problem on the client side, it's still
slow, but has gotten a bit faster, proceed to step 2.
2. Check that the APPX Server can resolve its own host name.
Sit down at the APPX server that is running WinAppxD or appxd.
Ping the server by its IP address. Ping the server by its name.
If the ping by IP address comes back in a second or two, but
the ping by name takes longer, the server has a name resolution
problem. See the typical reasons for this above. If after
fixing this (or not finding a problem here), it's still slow,
proceed to step 3.
3. Check that the APPX Server can resolve the PDC's host name
(and BDC host names), if you are running APPX Server on a
Windows NT box.
If you've eliminated problems 1 and 2, either by fixing them
and verifying that pings by name and IP address now take about
the same amount of time, or by doing the above tests and not
seeing a dramatic difference between ping times, the problem
is slightly different. In this case, you are probably running
APPX on an NT server (rather than a UNIX box) and the Primary
Domain Controller is probably a different machine than your
APPX Server. And what's happening is that the APPX server
is having name resolution problems finding the PDC, when it
tries to log the user into NT behind-the-scenes. Sometimes
this indicates a DNS problem, other times it indicates a WINS
problem (yes, NT uses two different name resolution services,
depending on how it's set up). To see if it's a DNS issue,
sit at the APPX server and ping the PDC by name and IP address.
If the ping by name is much slower than the ping by IP address,
by now, you probably have know what the trouble is -- DNS doesn't
know about your PDC. If you're not using DNS, make sure the PDC
is in the HOSTS file on your APPX server. If you are using DNS,
make sure your DNS tables include a record for the PDC's name
and IP address, and the names and addresses of all BDCs defined
on your network. If that didn't solve the performance problem,
you're all out of DNS problems, and have to look at WINS, which
is a Microsoft-specific name resolution service. You might run
into WINS performance issues if your network is set up to use
WINS (don't immediately discount this -- some are!) and the Windows
name of the PDC machine isn't the same as its TCP/IP hostname.
Typically, the problem would be that the APPX server doesn't
have a WINS server specified (or has the wrong WINS server name
specified). One way to see if you have a WINS issue might
be to sit at the APPX server, login as Administrator, open up a
Command box, and do the command "net view \\PDCNAME" (where PDCNAME
is the name of your domain's Primary Domain Controller box). If
it takes a while for it to come back (longer than a few seconds),
check your WINS configuration.
I don't want to use DNS. How do I put static IP address information
into my machines' "HOSTS" files?
All APPX clients and the APPX Server should have a hosts file, if you
have decided to go this route. At a minimum, this file needs to look
like:
142.42.42.1 appxserverhostname
142.42.42.2 pdchostname
That is, two lines. The first is the IP address of the machine running
winappxd, followed by at least one space, then the name of that machine.
The second is the IP address of your network's Primary Domain Controller
for the domain that validates logins, followed by at least one space,
then the name of the PDC. If you have BDC's, you would want to include
a line for each of them as well.
The HOSTS file lives in different places, depending on whether you
are running Win9x or Windows NT.
In Win9x: \windows\hosts
In NT: \winnt\system32\hosts
(Of course, if you've installed Windows into a different directory,
you'll want to change the first part of those paths above.)
This SHOULD improve your response time dramatically, and is useful
for small networks as well as a temporary fix to get a site up and
running without having to wait several days for an appointment with
a network techie to set up DNS on your LAN if the site's network
administration is done by an outside party.
2.12) Automatically update Presentation Clients to the most recent version!
Here's a nice low-budget way to "distribute" APPX from a central
server to client workstations, making sure that clients always run
the most up-to-date version.
The following batch file can be loaded on your APPX NT server, and
run by each client wanting to initiate a thin client session.
Under this scheme, clients always execute a local copy of appx.exe -c
as recommended, but when the appx.exe client is upgraded, it is not
necessary to distribute the new executables out to all the clients!
echo off
xcopy \\rocky_bdc\appx\appx.exe %temp% /d
start %temp%\appx.exe -c
The /d switch on the xcopy command only executes the copy if no
destination file exists or if the date/time on the source is later
than on the destination.
The start command then executes the local copy of the executable.
This works Win 95/98 and NT Workstation clients.
Thanks to Steve Glore of Consolidated Meat Group in Australia
<glores@meat.aust.com>!