
SOFTWARE COMPATIBILITY TEST METHODOLOGY

INTRODUCTION

This document is a guide for investigating an application that is not functioning properly on WINVIEW.  It also 
includes a recommended methodology for verifying the basic WINVIEW system installation and NetWare 
integration. Refer to Chapter 18, "Application Server Problem Determination," in the WINVIEW System 
Administrator's Guide.

Use the section titles in this document as a checklist when you encounter compatibility problems with 
WINVIEW.

REVIEW PRELIMINARY REQUIREMENTS

Listed below are several known limitations with WINVIEW. Make sure your problem is not one of them.

DOS Graphics

DOS graphics programs will work on the application server console but not from a workstation. Usually you 
will get a hard error popup message such as "invalid video mode" at a workstation when a graphics video 
mode is attempted. However, sometimes the mode cannot be detected properly and you may get only a blank 
screen.

There are some applications that are primarily text based, but display a graphics logo only upon initial 
startup. In that event, you may be able to support the application by disabling the initial logo display or by 
selecting "Ignore" on the popup you may receive.

DOS Block Device Drivers
	
DOS block device drivers are designed to augment the DOS file system. Since WINVIEW "virtualizes" the DOS 
file system, these device drivers are not supported. Block device drivers are used on a DOS-based PC to access 
devices such as CD-ROM and tape backup drives via a drive letter. An example of a block device driver is 
MSCDEX.EXE, the Microsoft CD-ROM extension. Workarounds for these include obtaining the respective 
OS/2 multitasking device drivers, or installing the device on a NetWare server in a way that supports 
standard network drive redirection.

OS/2 Presentation Manager (PM)

Applications that use the OS/2 Presentation Manager are not supported. The symptom for this is usually a 
message similar to "cannot load PMxxx.DLL." Unfortunately, some OS/2 text-based applications contain 
Presentation Manager dependencies. An example is where the application uses Presentation Manager to 
popup error messages. These applications usually will not load or execute on WINVIEW.

A small set of applications are text based but  have been modified with the addition of a few PM calls to install 
themselves on the PM desktop. If the install program still runs, or the application can be installed manually, 
you may still be able to use it with WINVIEW.

Windows Program Requiring Enhanced Mode VxDs (*.386 Files)

Windows enhanced mode VxDs are not supported. If the application uses VxDs, you will get an error message 
stating that the system "cannot load xxx.386." Check to see if the application will run in standard mode.

If standard mode does not work, check with the application manufacturer. You may have to configure the 
application slightly differently for it to work in standard mode.

ENSURE  APPLICATION WORKS ON DOS/WINDOWS WORKSTATION
(APPLICATION SET UP FOR NETWORK)

Occasionally, an application will not install properly on an application server. If that happens, first install the 
application on a DOS/Windows workstation and ascertain that the application is running properly. You can 
use this configuration to identify requirements the application might have for special device drivers, TSRs, 
DLLs, environment variables, .INI file configurations, etc.

Once the application is running on the workstation, install it again on the application server. If you encounter 
difficulties, try to identify the specific application  function(s) that may be causing the difficulties.

ENSURE  OTHER APPLICATIONS WORK ON WINVIEW (WINVIEW INSTALLED PROPERLY)

Before you invest much time trying to debug the application, make sure WINVIEW has been installed properly 
by setting up an application that is known to work, and verifying that it functions properly. If not, you may 
have a more basic problem than application compatibility.

BEGIN APPLICATION INTEGRATION WALK THROUGH

The best way to investigate why an application is not working begins with checking the system to ensure that 
it is installed properly and to become familiar with the application server configuration.

CHECK WINVIEW INSTALLATION

Check WINVIEW for proper installation.

Error Messages During System Initialization

Normally, errors during initialization will be reported on the console screen and the system will pause. The 
Administrator will be prompted to press ENTER to continue. 

If an error is not very serious, the console will not be paused and it may be necessary to force a pause after 
loading a device driver.

If you receive an error message during system initialization, it may be because the base system is not installed 
properly. To read messages that scroll off the screen too quickly,  place the following line in CONFIG.SYS: 

DEVICE=STOPHERE

Assuming you have kept the default PAUSEONERROR= YES, this statement will cause the system 
initialization routine to pause and display the error message(s). Place this statement in CONFIG.SYS 
immediately following the driver whose message you want to read.

If you are getting error messages in programs that are started automatically by the system STARTUP.CMD, 
you can review the messages in the file \OS2\CTX\OPS\ CTXBOOT.LOG. For example, TCP/IP for WINVIEW 
uses STARTUP.CMD to initialize TCP/IP support.



Check Ability to Login

Verify that you can login as userID "citrix" (or a current  Administrator userID).

NOTE: Remember that the "citrix" login is valid for ten days after installation unless you explicitly delete or 
extend the expiration date. Make sure you have a valid login.

If you can login,  most likely the system is installed and functioning. You can use the application server even if 
the network subsystem is not yet operational.

Review Hardware Configuration and CONFIG.SYS

Review CONFIG.SYS in the root directory of the boot drive. Check for the following:

 	Are the correct base device drivers listed in the BASEDEV statements?
 	Are the CONFIG.SYS sections for NetWare and TCP/IP included and properly enabled?
 	Is the correct network interface card driver specified?
 	Is the correct multiport adapter board driver specified? Are the parameters correct?
 	Are the correct video drivers for the console loaded (VGA vs SVGA)?

CHECK NETWARE NETWORK SUBSYSTEM

Follow the steps below to ensure the network subsystem is functioning properly.

Start OS/2 Session, Run SLIST

SLIST is an OS/2 text-based NetWare utility that is shipped with WINVIEW. It is in the path if the NetWare 
subsystem has been installed properly. If this utility works on Ethernet networks, you can be reasonably sure 
the network requester is functioning properly.

SLIST works properly on Token Ring networks even if source routing has not been properly enabled. If SLIST 
does not function properly, you may see only a subset of your file servers, or you may be able to see some but 
not log into them.

Review NET.CFG

If SLIST does not work, review NET.CFG in the \NETWARE subdirectory. Compare each entry with the 
examples in Chapter 5 of the WINVIEW for Networks Command Reference. Check the Link Driver section for 
incorrect NIC settings or frame types.

NOTE: Use the QUERY NETWORK utility to display  information about the NetWare requester.

Try Using a LANLINK Workstation for Your Investigation

If the IPX virtual workstation connections load successfully, you should move from the console to a LANLINK 
workstation to continue your investigation.

At this point, it's time to start testing how the network works with the application server virtual DOS  
environment. Before you start testing the network in this environment, you need to test the base DOS 
functionality.



CHECK ABILITY TO START A DOS SESSION

From the "citrix" user "Start Programs" menu select "DOS Command Prompt." Use this as a way to check the 
system's ability to create DOS sessions.

Video OK

If all you get is a blank screen when you start the DOS session, it could mean you have the incorrect console 
video drivers specified in CONFIG.SYS. Check CONFIG.SYS to make sure the correct drivers are specified.

You should use a color VGA monitor on the console or all workstations will have monochrome attributes by 
default. This may cause DOS sessions started at workstations to display data incorrectly or display no data at 
all.

If you have an SVGA adapter installed in the application server and the screen is blank when starting a DOS 
session, try replacing the CONFIG.SYS statement:

DEVICE=C:\OS2\MDOS\VVGA.SYS

with

DEVICE=C:\OS2\MDOS\VSVGA.SYS

assuming C is the WINVIEW boot drive.

DOS Character Device Drivers Load (ANSI.SYS,..)

DOS device drivers and DOS character device drivers load when the DOS session is first created. All DOS 
sessions will load DOS device drivers specified in the base CONFIG.SYS. Only DOS device drivers common 
across all users and applications (e.g.; ANSI.SYS) should be specified in the system CONFIG.SYS. Device 
drivers that need to be loaded for specific users or applications should be specified in a unique Program Start 
File (PSF) and an associated DOS Properties File (DPF) managed by the CONFIG APPLICATION utility. 

AUTOEXEC.BAT Runs (Check Environment Variables)

After the DOS session is created and the device drivers are loaded, AUTOEXEC.BAT executes.

NOTE: Type SET at the DOS command prompt to verify that AUTOEXEC.BAT has executed. If it has not, it 
could be due to one of more of the following conditions:

 	AUTOEXEC.BAT does not exist
 	AUTOEXEC.BAT is not reachable or has an invalid statement and terminates
 	COMMAND.COM was invoked without the /P option
	
If the AUTOEXEC.BAT runs properly, the environment displayed with the SET utility will have at least ten 
lines, including a complete PATH statement and a fully qualified path within the COMSPEC and HOME 
environment variables.

The system looks for and gives priority to an AUTOEXEC.BAT in the user's home directory; otherwise it will 
use the one in the \OS2\MDOS directory unless COMMAND.COM has been invoked without the /P option.

CHECK DOS SESSION

Check the key aspects of the DOS session compared with a typical DOS LAN workstation.

Check Environment Variable Space (MEM /DEBUG)

Use the MEM utility to verify the memory configuration for this DOS session. MEM, MEM /C and MEM 
/DEBUG all display relevant information. You should also be able to verify at this point that the virtual IPX 
(VIPX) driver that connects the DOS driver to the  NetWare requester and IPX/SPX protocol stack is properly 
loaded. If the protocol stack is properly loaded, MEM /DEBUG typed at a command prompt will show the device 
driver as VIPXXXX$.

If the typical DOS workstation seems to require a large amount of environment space, you may want to 
increase the default value set in the SHELL= statement of CONFIG.SYS. To activate this change, reboot the 
application server before continuing.

Some environment variables may change size when the paths to certain directories become longer. For 
example, one application could not handle the extended length of the TEMP variable on WINVIEW due to the 
inclusion of the path to the user's home directory (resulting in a SYS3176 error).

Check Conventional, EMS, XMS, and DPMI Memory Available

Compare the amount of memory available with what you would require for proper application execution on a 
standard DOS LAN workstation. For example, if you typically require a 4MB workstation with extended 
memory (XMS) enabled to run the application properly, make sure you have at least 4MB of XMS in your DOS 
session.

If DOS expanded memory (EMS) allocation is specified but none shows up when you run MEM, you may 
have a memory conflict with a memory mapped I/O board such as a Token Ring network interface card.

You can usually overcome this by specifying to include the memory region for the EMS frame in the DOS 
properties associated with the DOS session. Example:

Other: Include regions . . .[D0000-DFFFF  ]

This would make D0000-DFFFF available for EMS.

DOS protected mode interface (DPMI) memory allows DOS programs to use the protected-mode features of 
the 80286 and later processors without compromising built-in system protections. It is the memory used by 
Windows.

Check PSF/DPF DOS Properties as Appropriate

Use CONFIG APPLICATION to manage memory resources and other aspects of the DOS session. Particularly 
for DOS applications, you should be aware of any special DOS property settings required to run the 
application in a DOS session under OS/2.

In general, these OS/2 requirements will also be relevant for execution within WINVIEW; e.g.,  special DOS 
version simulation settings required by Lotus 123 (refer to the Lotus 123 README for details).

Do not modify the default PSFs and DPFs provided with WINVIEW so you can use them for comparison and to 
help debug problems. Make copies of these files and modify them for your testing.

CHECK NETWARE RESOURCES

Once the DOS session is set up properly, verify that the rest of the network subsystem supporting 
DOS/Windows sessions is functioning properly.

Begin Without Integrated Security

The best approach is to first verify that you can manually start a DOS session, load the network shell, and 
login to the network. This approach will help you more quickly identify such problems as incompatibilities 
occurring during network login script processing.

Start DOS Session with Known PSF/DPF

One easy way to manually login to NetWare from the WINVIEW server is to start a DOS command prompt 
from the "citrix" userID program selector menu. If you want to use a custom PSF, add an entry to the program 
selector menu that calls this PSF.

Manual Load of NETX-Check Default Connection

Before Version 2.3 OF WINVIEW for Networks, the NETX shipped with WINVIEW was the most compatible 
NetWare shell available. Beginning with WINVIEW for Networks Version 2.3, VSHELL has been greatly 
enhanced and is now the preferred NetWare shell.

However, NETX is still a little easier to load manually and can be used for this test. Load NETX from the 
\NETWARE subdirectory. If the VIPX driver has been loaded properly and the network subsystem is 
functioning, NETX should be able to establish a default connection to the login directory of a file server.

A preferred server for the entire WINVIEW system can be specified in the \NETWARE\NET.CFG file. The 
default connection drive letter assignment is based on the LASTDRIVE= parameter as specified in the base 
system CONFIG.SYS, or as overridden by the DOS properties associated with the PSF file used to start the 
DOS session. Use the QUERY DRIVES utility to display the drive letter assignments for the session.

With the current release of WINVIEW, loading NETX manually should result in changing the current directory 
to the default NetWare LOGIN directory.

MANUAL LOGIN AS NETWARE USER WITH NETWARE LOGIN PROGRAM

Run the NetWare DOS Login program from the login directory on the file server just as you would from a 
DOS workstation after it has booted and loaded NETX.  Your DOS system and user login scripts should 
execute.

If the system runs a strange login script, you may be running the NetWare OS/2 Login program found in the 
WINVIEW \NETWARE subdirectory. This executes the NetWare OS/2 login script, which is different from the 
DOS login script. Change your current directory to make sure you are running the DOS Login program in the 
login directory on the file server.

ANALYZE MAP

After the NetWare Login Script executes and you are successfully logged in to the network, use the NetWare 
MAP command to survey your mapped drives and search drives. Use your DOS workstation for comparison.



Mapped Drives Should be the Same as on the DOS Workstation

Look for differences in drive letter assignments or missing drives. These are some of the most common causes 
of LAN application problems. Often batch files have been written that start the application and assume certain 
mapped drive letter assignments. If these change when a user logs in from an application server, applications 
may not function properly.

Network Search Drives Should be the Same (With Additional WINVIEW Paths)

The default WINVIEW path is usually different from the path on the DOS workstation. This will cause your 
network search drive assignments to be different. Make sure all the search drives your applications need get 
assigned, and verify that any differences in the number of assignments or ordering will not affect your 
applications. Here are some example problems:

 	LASTDRIVE for the WINVIEW session is set too high and there is not enough room for all the search drives.

 	With WINVIEW workstation drive mapping enabled, the WINVIEW boot drive letter is changed and gets 
mapped over by the login script, removing access to the WINVIEW system files.

 	The login script assumes C:\ should be placed in the path. This will erroneously point to the application 
server system directory where users don't have access or to drive C of the remote client via workstation 
drive mapping, causing unexpected files to be used on the application server.

LOCATION OF NET.CFG

The original NetWare OS/2 requester placed NET.CFG in the root directory of the boot drive. Make sure your 
application is not trying use a NET.CFG in this directory (the WINVIEW EVENTS utility may help identify this 
problem).

The default for the current NetWare OS/2 and WINVIEW requester is for  NET.CFG to be in the \NETWARE 
subdirectory. On WINVIEW, a user-specific NET.CFG can be contained in the user's home directory, but this is 
of limited usefulness when using integrated security.

Novell LAN Workplace for OS/2 TCP/IP support is an example of an application that has this NET.CFG 
problem.  All TCP/IP support should be migrated to TCP/IP for WINVIEW.

ANALYZE DOS ENVIRONMENT VARIABLES

Now that the NetWare resources have been mapped properly, check the remainder of the DOS environment.

SET Command

Use the SET command again to check your environment.  Ensure that any environment variables set in your 
login scripts have been set properly.

Check COMSPEC

COMSPEC points to the active COMMAND.COM command processor. A COMSPEC error can cause 
application execution problems. The application may  execute for a while and fail during execution or upon 
exit.

Often networks are configured to assume all workstations have COMSPEC set to C:\ or C:\DOS. These 
settings will not work with WINVIEW.

Some networks set COMSPEC to a COMMAND.COM on a file server. This will cause problems. You must use 
the COMMAND.COM distributed in the WINVIEW \OS2\MDOS directory. The WINVIEW COMMAND.COM is 
not interchangeable with the DOS version.

In WINVIEW for Networks Version 2.3, an integrated security feature has been added that checks COMSPEC 
after login script processing is completed and changes it back to the WINVIEW default if it was modified. This 
feature works only when integrated security is enabled, and only when the changes occur during login script 
processing (it will not fix a batch file problem).

Some networks are configured to map a drive letter to DOS using login script variables (%MACHINE, %OS, 
%OS_VERSION). On the application server, these values are set to %MACHINE=IBM_PC, %OS=CITRIX, and 
%OS_VERSION=V2.3. In this case you can avoid a system login script change by creating a subdirectory on 
the file server with a name based on the unique values for the variables returned by WINVIEW. You can then 
copy the COMMAND.COM from the WINVIEW \OS2\MDOS directory  to this path on the file server.

NOTE: While this technique can help avoid a system login script change, placing COMMAND.COM on the file 
server will increase network traffic and should be avoided if possible.

Check Environment Variables Used by Application/Batch Files

This is a good time to check the environment variables on your DOS workstation and make sure they are all 
available in the WINVIEW DOS session.

TRY INTEGRATED SECURITY

Now that you know the basic NetWare login sequence functions, login using the WINVIEW integrated security 
feature with the default group set so that it starts a DOS PSF and leaves you at a DOS command prompt. 
Review the DOS environment as before. At this point, if you have a problem, you know it is specific to the 
integrated security autologin features and you can focus on the differences between this and the manual 
methods.

A good technique for troubleshooting integrated security problems is to run the WINVIEW LOGIN program 
from an OS/2 command prompt under the "citrix" userID  and use the verbose mode switch (/V). For 
example:

[C:\USR\citrix]login bobw /v

The verbose mode execution of the WINVIEW login program will display integrated security and autologin 
parameters such as the default group, first user program, home directory, etc. that can help you diagnose 
problems.

TRY VSHELL AS REQUIRED

If all your testing has been with NETX up to this point, you should now test a session started with a PSF 
where network resources are set to GLOBAL. This will USE VSHELL instead of NETX. Switching from NETX 
to VSHELL is a common way to clear up problems associated with starting a DOS application from the 
Windows Program Manager. VSHELL is also smaller than NETX and leaves more conventional memory 
available for your DOS applications.

VSHELL support in WINVIEW for Networks Version 2.3 has been enhanced so that new DOS sessions inherit the 
drive map, search drive, and environment variables as they exist in the initial parent session immediately after 
the login script is executed. For Windows users, this "snapshot" of the environment is made again just before 
Windows is started. If you have run programs or batch files that change these settings after you login, these 
changes most likely will not be inherited by subsequent DOS sessions and must be reissued.

ANALYZE APPLICATION REQUIREMENTS

If all previous steps have been accomplished and all anomalies resolved, you can now focus directly on 
specific application configuration issues. Here are some common ones to look for.

Location and Paths Used for Batch Files to Start Applications

WINVIEW checks for the existence of the specified "First User Program" before creating the DOS session. If you 
have specified a program or batch file on a mapped drive on the network as your first user program, the login 
will fail because the user is not logged in at the time WINVIEW checks for the file's existence. One alternative is 
to make COMMAND.COM the first user program and have it start the batch file with the /C or /K option.

The NetWare auto-login programs LOGIN.EXE and NWLOGIN.EXE can read a configuration file, 
NWLOGIN.CFG. NWLOGIN.CFG is an ASCII text file that can be created by the System Administrator using a 
text editor. This file must reside in the \OS2\CTX directory on the boot drive of the application server.

The NWLOGIN.CFG file contains configuration information that LOGIN.EXE and NWLOGIN.EXE read when 
initializing a user login. These configuration parameters can include where the user's home directory resides, 
as well as other optional information.

If you need to do batch file processing after network login and login script processing, create a file called 
NWAFTER.BAT. As with the AUTOEXEC.BAT, a global file for all users can be placed in the \OS2\MDOS 
irectory, or a user-specific one can be placed in the user's home directory. The NWAFTER.BAT can be used to 
"clean up" certain problems created by the system login sequence without having to modify the NetWare 
system login script.

NOTE: Several features have been added to WINVIEW that help the system integrator modify the results of the 
NetWare login sequence without having to modify the system login script. This helps minimize the risk of 
affecting the normal operation of other network users. These features often give you several ways to 
accomplish the same objective, particularly in cases where the system integrator has the LAN configuration 
knowledge and the supervisor rights to change the system login script.

Location of Application Requirements (Mapped Drives, Local Drives)

Many network installations use batch files to start applications. Review these batch files and ensure they don't 
make assumptions about drive mappings or user workstation directory structure that are different when 
running on an application server.

Location of User-Specific Files, Temporary Work Space, Data

Within an application, configuration settings often are contained in user profile or .INI files. Review these 
settings to see if they make assumptions about the locations of files or working directories that may be 
different when running on an application server.

Memory Management Requirements (EMS, XMS, DPMI)

These settings should be reviewed as part of making sure the DOS session was created properly. Double check 
the requirements for the specific application and make sure sufficient memory resources have been allocated.

Remember, the sum of all memory resources for all sessions used by a user must not exceed the maximum 
virtual memory allowed by the user or default group profile. Usually when increasing the memory allocation 
for a DOS property, you must also increase the virtual memory limit with the CONFIG USER utility.

Special Application Resource Needs Environment Variables in AUTOEXEC.BAT

Check for other changes to the environment that an application installation procedure made to your typical 
LAN workstation. Look for things such as special device drivers, file handles, or expanded environment space 
specified in CONFIG.SYS. Also check the AUTOEXEC.BAT for TSRs that get loaded or environment variables 
that need to be set.

Windows Enhanced Mode vs. Standard Mode

Some Windows applications behave differently in the two different modes of Windows. However, many of 
the motivations for using enhanced mode on a single user workstation do not apply with WINVIEW. These 
include true DOS multitasking and virtual memory management, both of which are supported by Citrix 
Windows in standard mode. For these reasons, standard mode is the default Windows execution mode for 
WINVIEW.

If your Windows application fails for an unidentifiable reason, try switching from standard to enhanced 
mode. Use the WINENH.PSF supplied with WINVIEW instead of WIN.PSF.

If you started your testing in enhanced mode and your Windows application returns an error message such as 
"cannot load xxxxx.386," the application is probably trying to load a Windows VxD (Virtual Windows Device 
Driver). Since VxDs are not supported on WINVIEW, try switching to standard mode. Windows does not 
support VxDs in standard mode, so many applications will function properly without VxDs when loaded in 
standard mode.

NetWare NetBIOS Emulation Support

NetWare NetBIOS emulation for DOS and Windows programs is not supported on WINVIEW, but NetBIOS can 
be used in several ways in a WINVIEW system.

Some application programs use NetBIOS to synchronize multiple user access to program resources such as file 
and record locking. For WINVIEW systems not connected to a network, NetBIOS emulation within the 
WINVIEW system is provided to make the application believe it is running on a NetBIOS network. This support 
works only in a stand-alone WINVIEW configuration not attached to a network.

Some WINVIEW systems are attached to NetBIOS networks such as Microsoft LAN Manager. In a configuration 
of this type where the LAN Manager OS/2 requester is installed on WINVIEW, properly configured DOS 
workstations can use NetBIOS with LANLINK to connect to the application server.

NOTE: There are limitations to using WINVIEW with LAN Manager because WINVIEW is optimized primarily 
to run with Novell NetWare.



There is an NDIS-based network subsystem from IBM (referred to as NTS/2 and LAPS) that can be configured 
to support NetBIOS for certain DOS and Windows applications on WINVIEW. This product has a PM-based 
installation program and is difficult to integrate with WINVIEW because it must first be installed on a single 
user OS/2 machine and then copied to WINVIEW.

The entire subsystem layout and configuration parameters are based on the IBM LAN Server and will not be 
familiar to the typical NetWare integrator. This configuration works only when communicating with other 
native NetBIOS servers   not NetWare NetBIOS emulation servers. While several WINVIEW installations are 
using this support, it is not recommended unless you are already running this configuration on other OS/2 
systems on your LAN.

In summary, several NetBIOS configurations are supported with WINVIEW. Some work well, some are 
complex to install but may work, and others like the NetWare NetBIOS emulation for DOS and Windows 
applications are not supported.

TCP/IP SUBSYSTEM

Prior to WINVIEW for Networks Version 2.3, Citrix supported several TCP/IP subsystems. These subsystems 
had a variety of limitations. To overcome these limitations, Citrix now markets a TCP/IP subsystem that has 
been optimized and tested for use with WINVIEW. This is the TCP/IP subsystem that should be used.

NOTE: Refer to the TCP/IP for WINVIEW System Administrator's Guide and Command Reference for additional 
information on TCP/IP for WINVIEW.

INTEGRATE WITH WINVIEW REQUIREMENTS

If you are still having problems, here are some other potential reasons.

Windows Executables in \WINCRED

Some applications incorrectly assume a certain path to the Windows system directory. The client/server 
version of Windows shipped with WINVIEW is in the \WINCRED directory. This version of Windows must be 
executed when running on an application server. It is safest to remove any single user versions of Windows 
from the path when running applications on WINVIEW.

Some applications install files in the Windows system directory. If this occurs, you need to make sure these 
files get copied to the \WINCRED directory.

Always start Windows on WINVIEW using CWIN instead of WIN. If you need to leave the Windows system 
directory in the path, always place it in the path after the \WINCRED directory. 

.INI Files in the Path

Many Windows applications store configuration information in .INI files. If you have not set up your 
application server users to share a common .INI directory already set up on the network, you will need to 
rerun the application setup program from WINVIEW so that the users' .INI files are added and updated 
properly. Use your typical workstation to compare the .INI files for LAN vs. application server users to 
identify differences.

CWIN.INI and CSYSTEM.INI

One of the techniques used by WINVIEW to provide seamless integration with existing LAN Windows users 
involves utilizing unique .INI files for the WINVIEW-specific information.

There are values in the WIN.INI and SYSTEM.INI files that need to be different when executing on an 
application server versus executing at a LAN workstation. To accomplish this, WINVIEW does not change any 
existing .INI files but builds its own extensions that take precedence when executing on the application server. 
These are called CWIN.INI and CSYSTEM.INI. Check these files to see if they are overriding settings that are 
needed by your application (e.g.; forcing PROGMAN.EXE instead of the shell you use). Also, check to see if 
settings for your application are not in .INI files where moving or copying the settings might make a 
difference. WIN.INI and SYSTEM.INI are used if entries are not found in CWIN.INI and CSYSTEM.INI.

Application DLLs are in the Path

Many Windows applications are implemented as a collection of Windows DLLs. Make sure that any changes 
in the path or mapped drives give you complete access to all the DLLs needed to run an application. In 
addition, make sure that your application does not replace DLLs shipped with WINVIEW (such as 
NWIPXSPX.DLL).  You must run the DLLs shipped with WINVIEW for the application server and your 
applications to function properly.

User Home Directory

A very common problem when first testing an application server is that an application may be configured to 
assume the user's home or working directory is located on drive C. An application server user is set up similar 
to a diskless LAN workstation, where the home directory is actually a path and not the root directory of drive 
C. Make sure the application can accommodate this type of configuration.

In some instances, you may need to use the NetWare MAP ROOT command to substitute a drive letter for the 
home directory path. In fact, this is a good way to remove user-specific path information from profile and .INI 
files so that user profile information can be copied from one user to another.
	
NOTE: Use MAP ROOT to remove all user-specific paths from a user's environment:

MAP ROOT U:=SYS:\USR\%USERNAME%

In this case U is used in common batch/.INI files for all users to refer to the user's HOME directory.

Security Issues

By default, WINVIEW integrated security users have only USER level security rights on the application server 
system. Running the application with a userID that has WINVIEW Administrator rights is one way to determine 
if an application compatibility problem is security related. If this makes a difference in the way the application 
is behaving, use the WINVIEW EVENTS utility to identify which resources a USER level user is being denied 
access to. You can use the CONFIG ACCESS utility to grant specific file/directory/API access rights to users if 
that is the proper solution.

Start From the Beginning

If you have been unsuccessful trying to integrate with an existing Windows user already set up on the LAN, 
start over. Act as though you are adding a new user to the LAN, but use the application server as the user's 
workstation. Run the WINVIEW Windows setup for this user initially, and then run the application-specific 
setup program on the application server. This can sometimes help identify differences (that are not readily 
apparent) in the workstation install/configuration. (Setting up a control/test user in this way is usually a 
good idea in any case.)



This is also true if you are upgrading an application server to a new level. Sometimes changes or 
enhancements are made to the system that will not take effect unless you recreate the user and run the 
Windows setup again on the updated system.

For example, if you add TCP/IP for WINVIEW to an existing WINVIEW system, the default AUTOEXEC.BAT is 
modified to load the drivers necessary to access the TCP/IP protocol stack.

Existing users already set up to run Windows have individual AUTOEXEC.BAT files that will not inherit the 
changes to the default files. In this case you can manually edit each user's AUTOEXEC.BAT.

Starting DOS Applications from PIF

If you are using a Windows PIF to launch a DOS application, DOS properties cannot be specified. Try creating 
a special PSF file for the application to see if specific DOS properties are needed to run the application. If 
necessary, you can launch a specific PSF file instead of a PIF file from a Windows icon.

If Problems Persist

Consult with someone who is very familiar with the application for information about similar failures on 
DOS/Windows workstations.

Check with the application vendor technical support team who might have knowledge of similar failures on 
DOS/Windows as well as OS/2 workstations. Ask if there are special requirements for this DOS/Windows 
application when running in an OS/2 session.

NOTE: If you are advised that the application is not supported under OS/2, that doesn't mean it won't work 
on WINVIEW. WINVIEW has been enhanced to run DOS and Windows applications that do not run well under 
OS/2.

If, after following the solutions in this chapter, you still need assistance, please contact your Citrix authorized 
reseller. Refer to Appendix O for a list of authorized resellers.


 


 


