Title : Configure PC Applications
Name : SIFVX1::CS$DISK:[CS.CSDOC]CONFIGURE_PC_APPLICATIONS.TXT
Author : Date: Comments:
Ian Dingwall 19-JAN-1993 File Created
Ian Dingwall 01-MAR-1993 Added Paradox For Dos V4.01
Ian Dingwall 04-MAR-1993 Added Paradox TUTILITY setup.
V Robinson 17-MAR-1993 Added Qemm V6.02 Install.
V Robinson 17-MAR-1993 Added Reflection LAT V2.0 Install.
V Robinson 20-APR-1993 Added Paradox for Windows Install.
V Robinson 07-MAY-1993 Corrections to Reflection lat install.
Ian Dingwall 18-MAY-1993 Added Windows on network settings.
Ian Dingwall 26-MAY-1993 Added MS PowerPoint for Windows,
Added DEC LK250 keyboard installation,
Added 'Adding/Updating new MS Windows
Application',
Added NETWIN & Its Usage.
This file explains the basics on how to configure various pc applications for
use at the Schlumberger Technologies Instruments site.
o Paradox for DOS, V4.01
o Changes needed to Rlat V2.0 after Installation.
o Installing Qemm V6.02 Memory Manager
o Loading Windows & Windows Applications On A Server
o DEC LK250 Keyboard Installation
o NETWIN & Its Usage
o Adding/Updating new MS Windows Applications
Paradox for DOS, V4.01
============================
Map network drive to the source code location for old V4.0 source code.
MAP L: = SYS:\PUBLIC
As we had already loaded V4.0 I first used filer to delete the subdirectory
structure L:\PUBLIC\PDOX40.
Install the new version of paradox:
A:INSTALL
Source Drive: A:
Network Installation
Network Type Novell
Network Control File Directory P:\PDOX40\PDOXDATA
User Name Schlumberger
Company Name Schlumberger
Serial Number
Country Group English International
Sort Order Dictionary
Paradox 4.01 diretctory L:\PUBLIC\PDOX40
Install Sample Tables Yes
Install Sample Application Yes
Install Workshop Yes
Install Workshop Sample Apps Yes
{Unzips at this point} Installation creates most directories except
P:\PDOX40\PDOXDATA. 20mins.
Create the network locking directory for V4.01.
MKDIR L:\PUBLIC\PDOX40\PDOXDATA
Use SYSCON to add the following rights for group EVERYONE to the directories:
Read+Filescan to SYS:\PUBLIC\PDOX40
Read+Filescan+Write+Create to SYS:\PUBLIC\PDOX40\PDOXDATA
Use NUPDATE to add the extra serial numbers.
L:
CD \PUBLIC\PDOX40
NUPDATE
You can obtain the serial numbers either off the paradox disks or they should
be in the servers pc list file PC0168.TXT. (We loaded a total of 16 licenses as
five have been traded for Paradox for Windows.)
Use the paradox custom configuration facility to alter the default state of
paradox. Most settings use the defaults except those changed below.
L:
CD \PUBLIC\PDOX40
PARADOX
=
Utilities
Custom
Reports Report Settings Page Width 60
Page Length 66
Left Margin 0
Pause Between no
Eject Page LF
Group Repeat Retain
Graph Printer Port PrinterType Model Mode
1 LPT1 Epson FX 120*216dpi
2 LPT2 Postscript
3 LPT3 HP Printer LJII 150*150dpi
Format Data Number Format US Format
Date Format dd.mm.yy
Accept ISO Dates NO
When you save the above, select the option to save to HardDiskas you are
sitting in the shared directory. If you select Network it will NOT save as you
are in the networked directory.
Note: Paradox saves the company name & serial numbers in PARADOX.SOM.
Paradox saves the default settings in PARADOX.CFG
Now lets setup the TUTILITY utility.
L:
CD \PUBLIC\PDOX40
TUTILITY
{SETUP}
{NETWORK} P:\PDOX40\PDOXDATA
{DO_IT!}
This creates a TUTILITY.CFG configuration file. TUTILITY should only be used by
a supervisor equivalent as it needs to have write access to the configuration
file. If you also have passwords on the table then when you rebuild you will
loose any auxiliary passwords. Always use the master password with TUTILITY.
<End>
Changes needed to Rlat V2.0 after Installation.
=======================================================
NOTE - Windows And Reflection for Windows MUST BE LOADED First.
__________________________________________________________________
1. Run Reflection Lat Install Program :- INSTALL
2. Set default reflection for Windows directory to:- RWIN
3. Set Interface settings to :- Card Type:- SMC
" IRQ :- 10
" ADD :- C800
" IO :- 300
When Finished Setup:-
4. Edit Startnet.bat in WRQNET Directory and add /dir:100 to rlat line .
ie:- RLAT /DIR:100
5. Change Autoexec.bat or lat file to load IPX Driver from to WRQNET Directory.
ie:- CD\WRQNET
IPX (not ipxsmc)
6. Edit Autoexec.bat and tidy up and put a CALL infront of the startnet.bat
ie:- CALL C:\WRQNET\STARTNET
7. Copy Autoexec.bat and Config.sys to C:\startup\*.LAT
8. Make up a LAT.BAT in the C:\UTILS directory.
Installing Qemm V6.02 Memory Manager
============================================
IF Loading From SIFN01 File Server Type then Goto 1.
___________________________________________________
OR
IF Loading from Floppy Disk then Insert Floppy and Goto Item 6.
______________________________________________________________
Note - It is best to install QEMM last so that there is no more changes to
to config.sys and autoexec.bat files afterwards.
ALSO if you Put Windows 3 on After Qemm you have to Go To QEMM
Directory and TYPE:- QWINFIX.
1. Login as SUPERVISOR
2. MAP H:=PROJECTS:
3. CD\CS\QEMM\100USER\V6.02
4. MAP ROOT A: = H:
5. A:
6. INSTALL
7. Edit CONFIG.SYS and Change line that reads :-
DEVICE=C:\QEMM\QEMM386.SYS
TO
DEVICE=C:\QEMM\QEMM386.SYS RAM ADAPTERRAM=C800-CBFF
( if using SMC Ethernet card at this address )
OR
DEVICE=C:\QEMM\QEMM386.SYS RAM NOSHADOWRAM ADAPTERRAM=C800-CBFF
( if using SMC Ethernet Card in NEC Powermate SX16 at this address )
8. Edit AUTOEXEC.BAT and remove QEMM from Path Statement.
Loading Windows & Windows Applications On A Server
==================================================
You can install windows in serveral ways.
SETUP Installs a working version of Windows into the drive
& directory you specify.
SETUP /A Explodes all of the files on the installation disks
into the drive & directory you specify. The files
in the target directory can not run windows but
can be used to install other copies of windows
SETUP /N Installs a stripped down version of windows for network
use.
SETUP
-----
Normally you install windows on a local hard disk (C:\WINDOWS) by using the
SETUP command with no options. This is a single standalone copy. Only the user
using that pc can use that version of windows. Using the same SETUP option you
can install into a network directory (G:\WINDOWS) and this can be used like the
local harddisk copy except that only one person at a time can use that
copy of windows.
The reason only one person can use either of these copies at any one time is
that the configuration files used by windows (*.INI & some others) are read at
startup and are overwritten when windows or an application ends. If two people
were to share the networked copies then it is possible for one set up updates
to override the other users updates.
SETUP /A
--------
This option allows the installation disks to be copied into a single directory
so that further 'SETUP xxx' commands can be used without needing the original
installation disks. This can be usefull in a network environment as it can save
time when installing further copies of Windows as disk swops are not longer
nesassary.
For example if you were to use
A:
SETUP /A Run setup from the floppy
G:\NET_WIN location of network install dir
You could then run this network setup.
G:
CD \NET_WIN
SETUP [options]
SETUP /N
--------
It is possible to tell windows to use private copies of the configuration files
while using a single shared copy of the programs.
This is achieved by
o Using the standard SETUP single user option to install a working
copy of Windows into a networked directory, you should install into
the drive:\directory (G:\WINDOWS) that will eventually be shared.
o Installing the installation disks into a network directory
(G:\NET_WIN) by using SETUP /A
o Use the networked installation directory to generate private copies
of the Windows Configuration files.
G:
CD \NET_WIN
SETUP /N
{ install into a private directory for the user }
The list of files currently placed in the private directory by
SETUP /N for MS Windows V3.1 are:
Volume in drive C is PC0179_C
Volume Serial Number is 1764-8375
Directory of C:\IAN
. <DIR> 04-21-93 11:32a
.. <DIR> 04-21-93 11:32a
WIN INI 3296 04-21-93 12:20p
WIN COM 44170 04-21-93 12:17p
BOOTLOG TXT 1181 04-21-93 12:17p
SYSTEM INI 1586 04-21-93 12:20p
CONTROL INI 3609 03-10-92 3:10a
WINVER EXE 3904 03-10-92 3:10a
_DEFAULT PIF 545 04-21-93 12:19p
DOSPRMPT PIF 545 04-21-93 12:19p
AUTOEXEC WIN 4515 04-21-93 12:20p
CONFIG WIN 3876 04-21-93 12:20p
PROGMAN INI 225 04-21-93 12:36p
MAIN GRP 5822 04-21-93 12:36p
WINMINE INI 179 04-21-93 12:36p
ACCESSOR GRP 9447 04-21-93 12:36p
GAMES GRP 1480 04-21-93 12:36p
STARTUP GRP 44 04-21-93 12:36p
ADDPATH BAT 24 04-21-93 12:22p
WINFILE INI 99 04-21-93 12:24p
REG DAT 3367 04-21-93 12:31p
21 file(s) 87914 bytes
13101056 bytes free
BOOTLOG.TXT ????
AUTOEXEC.WIN AUTOEXEC.BAT with appropriate changes to run MS Windows
CONFIG.WIN CONFIG.SYS with appropriate changes to run MS Windows
CONTROL.INI Contains desktop colout scheams. No reference to network
drives or applications.
PROGMAN.INI Determines the program groups available to the user. For Users
to be able to own their own group files these groups must be
in the users personal windows directory.
[Settings]
Window=68 48 580 384 1
display.drv=vga.drv
Order= 2 3 4 1
[Groups]
Group1=F:\DINGWALL\WINDOWS\MAIN.GRP
Group2=F:\DINGWALL\WINDOWS\ACCESSOR.GRP
Group3=F:\DINGWALL\WINDOWS\GAMES.GRP
Group4=F:\DINGWALL\WINDOWS\STARTUP.GRP
SYSTEM.INI Controls the windows device drivers used in the users
environment. The user needs different drivers for each type
of machine used. VGA, S3, keyboard etc... This is definate
candadate for WINLOGIN management. In the initial
state no references to specific directories.
WIN.INI User specific settings. This is the file most windows
utiltiites alter to load new applications. In the initial
state no references to specific directories.
ACCESSOR.GRP These are the group definitions setup for that user. Access
GAMES.GRP to the main applications is gained from the users DOS path
MAIN.GRP settings but when you look at the contents of these files
STARTUP.GRP you can see the network directory from which SETUP /N was run
from is used to pick out the *.EXE file used for icon
management. Looks as though we may have to go through each
icon and redefine the location.??
REG.DAT OLE registration database.
WIN.COM Windows image
WINVER.EXE Windows version
DOSPRMPT.PIF MAIN group DOS prompt PIF file.
_DEFAULT.PIF Default PIF File.
To run this networked 'SETUP /N' configuration you need to have have either:
o The dos PATH command set to
SET PATH=C:\userdir;G:\network_dir
eg: SET PATH=F:\DINGWALL\WINDOWS;G:\WINDOWS;C:\DOS
^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^
user specific dir net dir
Actually Setting up a Shared Windows on the Server
--------------------------------------------------
On the novell file server we assume that after the installation is complete all
of MS windows & associated applications are held on drive G:
G:\
\WINDOWS
\WINWORD
\EXCEL
\RWIN
\......
This means users only need to access a single disk for all windows
applications. If we use a MAP ROOTed drive then we can place the windows
applications anywhere on the server, or even move them if required.
Initially to load the software we login with supervisor or equivalent access to
create the root G:\ directory and load the applications, but we then set this
directory structure to Read only so any user can run the applications without
altering the shared network files.
Create Basic Directory
----------------------
o Login as supervisor
o Create the G: drive
MAP ROOT G: = TESTFS:
G:
MKDIR NET_WIN
MAP ROOT G: = TESTFS:\NET_WIN
o Give the group EVERYONE Read & Filescan access to TESTFS:\NET_WIN
using SYSCON or the GRANT command.
At this point you can use the
MAP ROOT G: = TESTFS:\NET_WIN
G:
to access this G: drive.
Installing Basic Windows & Applications
---------------------------------------
Now we have a network drive & directory lets just throw on the basic windows
applications. After this stage we will go through each windows application to
setup their general settings, those most common for the site, and finally we
will explain what settings to adjust for shared network usage. Thus for Windows
and each application you will have the following sections:
Basic
-----
General Settings
----------------
Shared Network Settings
-----------------------
So lets get down to work. Each section assumes you have mapped G: to the
correct location with Supervisor privalage:
Windows V3.1 Basic
- - - - - - - - --
Install Windows from the master disks using our serial number xxxxxxxxxxxxxxx
A:
SETUP
'Custom Setup'
G:\WINDOWS
Machine settings:
Computer: MS-DOS
Display : VGA
Mouse : Microsoft, or IBM PS/2
Keyboard: Enhanced 101 or 102 key US or NON US
Keyboard Layout: British
Language: English (American)
Network : Novell Netware (shell 3.26 or above)
Who Ownes the Software:
Name : Schlumberger
Company : Schlumberger
You should always use these names rather than Joe Bloggs, Marketing, so we can
move the software license/code/disks from one user to another.
We will not install any printer drivers at this time but we will tell windows
to install all other software components (help, tutorials etc..) as these will
be used by all users.
When you are prompted about a swap file tell windows to disable it
(Swapfile=None). This is because we want to use this copy of windows as a
shared version. We can reactivate on a person by person basis if requried.
When you are asked if you want to save the nesassary configuration changes to
toye PC startup files select NO as these will be made manually on everyone's
PC.
Windows V3.1 General Settings
- - - - - - - - - - - - - - -
Here we will ensure the user is using the correct keyboard settings, has access
to the correct printers, we install a basic background bitmap (you will know
what this is eventually) and set a basic colour scheame. The settings setup
here will be used by everyone as a default.
By this time you should be able enter and exit windows by typing:
G:
CD \WINDOWS
WIN
{ do any windows stuff }
<Alt-F>
Exit
We will now go inside windows to setup these defaults:
The following settings require you to go into the Windows Control Panel bu
selecting the following icons:
'Main group'
'Control Panel'
o Colour : Colour Scheams = Ocean
Desktop : Pattern = None
Screensaver = Mystify
Wallpaper = Schlum.bmp ( * see below * )
International: Country = Unitied Kingdom
Language = English (American)
Keyboard Layout= British
Measurement = Metric
Network : NWShare Handles= ON
386 Enhanced : Virtul Memory, Type = None
The SCHLUM.BMP bit map was generated by MIS and is stored in the
SIFVX1::CS$DISK:[CS.PCINFO]SCHLUM.BMP file. Copy this to the
G:\WINDOWS directory befire you cans select it.
o Printers:
Install the following (or what you have on your site)
Apple LaserWrite II NTX
Digital DEC Laser 2250
Digital LN03R Scriptprinter
Epson DFX5000 for FDFX 8000
Epson LQ-2550
Epson FX 850
HP LaserJet
HP LaserJet II
HP LaserJet III
Canon Bubble-Jet BJ-10e
Canon Bubble-Jet BJ-130e
Generic / Text Only
For all printers select A4 page size.
For Text printers select wide carridge.
For Postscript printers select 'reset each page'. This is an
advanced option check box. This allows the printers to print
complex graphics with a small amount of memory in the printer.
Normally we connect:
Epson on LPT1
Text on LPT1
Postscript on LPT2
HP on LPT3
o Sound:
We can get the PC's to make certain sounds with the PC speaker by
using a speaker driver called SPEAKER.DRV contained in a zipped
file SPEAK.ZIP available from the FTP site FTP.CICA.INDIANA.EDU.
I actually obtained it from the Microsoft Software Library forum
of compuserve as SPEAK.EXE. To install I exploded out the driver
SPEAKER.DRV by running SPEAK.EXE then use the commands:
'Main' group
'Control Panel'
'Drivers'
'Add'
'Unlisted or Updated Driver'
{point to SPEADER.DRV}
Windows V3.1 Shared Network Settings
- - - - - - - - - - - - - - - - - --
Read the instructions in the section 'Adding/Updating new MS Windows
Applications' and the section 'NETWIN & Its Usage'. If the default for NETWIN
are not defined then define them otherwise use NETWIN to access the shared
windows applciations.
At this point the user should be able to get into and out of windows once
logged onto the network. Any changes to the windows environment are local to
the user.
If a user is going to use the same PC all the time and it has a local hard disk
then we can generate either a permanent or tempoary swopfile. This has the
effect of increasing the available memory to windows.
o Once inside windows go to the Control Panel
386 Enhanced
Virtual Memory
Create
{Select space on C: or D: drive)
Reboot windows.
The drives specified above are on local hard disks, not network
drives.
If you have a diskless PC it is possible to have a tempoary swap file on a
network drive but we do not use this option as it normally means the local PC
does not have sufficient PHYSICAL memory for the users applications. If
activated all swaped memory will go over the network, thus slogging it. If in
the future you need to activate this then use the following sequence:
o Go to the users specific windows directory
F:
CD \username\WINDOWS
o Edit SYSTEM.INI to add the following line in [368Enh] section
PagingFile=F:\username\WINDOWS\SWAPFILE
o Restart windows.
MS Word for Windows Basic
- - - - - - - - - - - - -
Install MS Word for Windows from the master disks using our serial
number xxxxxxxxxxxxxxxxxxxxxxxxxx, MS serial number xxxxxxxxxxxxxxxxx
o Start windows
G:
CD \WINDOWS
WIN
o From the Program Manager select
'File'
'Run'
{Place disk 1 in A: drive}
'A:\SETUP'
to get yourself into the installation program.
o Select 'Custom'
o Place the word for windows application files in
G:\WINWORD
o Follow the instructions & feed in the appropriate disks.
o Do not update AUTOEXEC.BAT or CONFIG.SYS
MS Word for Windows General Settings
- - - - - - - - - - - - - - - - - --
See the network settings below on setting the user name, used for annotations.
Some of the other network settings may also be appropriate for you to set in a
single user environment.
One of the most important settings you need to modify is the size and
orentation of the paper. Work for Windows does not use the size setup for the
current printer, instead it uses
Format
Page Setup
Size & Orentation
Paper Size button
You should now select the correct paper size used on most printers on site. In
our case we use A4 (21*29.7cm). You then need to select:
Save As Default button
which will save this in the document template that is used as default when
creating new documents. This file is called NORMAL.DOT normally held in the
Dot-path=xxxx directory (G:\WINWORD installation directory by default). Once
saved to this document template (the GLOBAL template) any new documents created
will use the correct paper size.
If you are configuring a single user system which will be used as the basic
shared network application then ensure you are logged in with sufficient
privalage to write to the network directory otherwise NORMAL.DOT will not be
updated.
MS Word for Windows Shared Network Settings
- - - - - - - - - - - - - - - - - - - - - -
It is possible to use MS word for Windows on a network BUT you have to setup
some settings so that word knows,who the user is, where to save tempoary
files, default documentation settings etc...
Most of the settings can be changed from inside Word For Windows itself.
o Start the network copy of windows
o Start Word for Windows by selecting its icon.
o You can change the options by selecting:
Tools
Options
We are going to change several area's.
1) Username, used for annotations.
2) User specific spelling dictionary.
3) Network file locations.
o Use the
'User info'
name icon on the left hand side then change to username & initials
to the correct value.
o Each user must have a custom spelling dictionary defined otherwise
they will not be able to add new words. These spelling dictionaries
can go in the users personal area or group area's. To add a new
spelling dictionary use the
'Spelling'
'Custom Dictionary' ADD button
Normally for network users place their personal custom dictionary in
the
F:\username\CUSTOM.DIC
file. You can use any name, IAN.DIC, TAYLOR.DIC etc...
To create a project specific custom dictionary use the same option
as above but save the custom dictionary file in a shared project
area.
o To delete a cusom dictionary you need to use the
WIN.INI icon
inside Tools/Options and then select the
'MS Proofing Tools'
application then change or delete the custom dictionary
Custom Dict 1=F:\username\CUSTOM.DIC
o Network File Locations. Word for windows relies on verious settings
held in the [Microsoft Word 2.0] section of the WIN.INI file to
determine where to locate programs, where to store files etc.. Here
are the basic settings needed to run Word for Windows from a network
drive.
The following settings can be modified from inside Word for Windows
by selecting
WIN.INI icon
from the Tools/Options menu.
Application [Microsoft Word 2.0]
HPDSKJET=+1 Used for HP printer support
AUTOSAVE-path=F:\username Where tmp file are stored
INI-path=F:\username Where WINWORD.INI which holds
the users name is stored.
programdir=G:\WINWORD Word for Windows programs
NovellNet=Yes On a novell network
Doc-path=f:\username Which directory to display by
default when 'File/Open' is
selected.
where 'username' is the login directory of the user...
If the user want to store additional document templates which are
presented to the user on 'File/New' then you have to add the
following lines to Tools/Options/WIN.INI
Application [Microsoft Word 2.0]
Dot-path1=G:\WINWORD
Dot-path2=F:\username
etc...
This can be used to provide global templated for users in specific
project groups.
MS Excel for Windows Basic
- - - - - - - - - - - - --
Install MS Excel for Windows from the master disks using our serial
number xxxxxxxxxxxxxxxxxxx
o Start windows
G:
CD \WINDOWS
WIN
o From the Program Manager select
'File'
'Run'
{Place disk 1 in A: drive}
'A:\SETUP'
to get yourself into the installation program.
o Select 'Custom'
o Place the Excel for windows application files in
G:\EXCEL
o Follow the instructions & feed in the appropriate disks.
o Do not update AUTOEXEC.BAT or CONFIG.SYS
o Enable support for Lotus 123
MS Excel for Windows General Settings
- - - - - - - - - - - - - - - - - - -
There are no general settings..
MS Excel for Windows Shared Network Settings
- - - - - - - - - - - - - - - - - - - - - --
MS EXCEL v4.0 stores its configuration settings in a file called EXCEL4.INI
held in the user specific windows network directory:
F:\username\WINDOWS\EXCEL4.INI
You can use the windows NOTEPAD editor to change/add several settings to the
application section
[Microsoft Excel]
OpenDir=F:\username Which directory to display by
default when 'File/Open' is
selected.
There are other settings available for more advanced users, reed the file
G:\EXCEL\EXCELINI.TXT.
Reflection 2 for Windows Basic
- - - - - - - - - - - - - - --
Install REFLECTION 2 FOR Windows V4.0 from the master disks using our serial
number xxxxxxxxxxxxxxx.
For further installation information see the Reflection 2 Quick Start Guide.
o Start windows
G:
CD \WINDOWS
WIN
o From the Program Manager select
'File'
'Run'
{Place disk 1 in A: drive}
'A:\SETUP'
to get yourself into the installation program.
o Select 'Custom'
o Place the reflection for windows application files in
G:\RWIN
o Select the
'Standard PC Keyboard'
even though you have an LK520 keyboard. This will be set later.
o Follow the instructions & feed in the appropriate disks. You will
have to restart windows at the end of the installation.
Note: When I installed the software it would not install unless I manually
created the G:\RWIN directory. Once created all was well when SETUP was
run.
Reflection 2 for Windows General Settings
- - - - - - - - - - - - - - - - - - - - -
Reflection can use different file transfer protocols to transfer files to/from
the pc.
OLD-WRQ VAXLINK
WRQ VAXLINK2
You normally copy these programs to the VAX using a bootstrap routine but as we
have been using reflection for several years we already have these on the vax
in a common PUBLIC_INFO area. As newer version of these applications become
available, normally distributed on new reflection diskettes, we upload them
into the common area.
We now need to tell reflection how to access these common VAXLINKx copies which
are normally achieved using a transfer setup option.
o Start reflection
o Select
'File'
'Transfer Setup'
o Select
'Protocol' OLD-WRQ
'Host Startup Sequence' VAXLINK
o Select
'Protocol' WRQ
'Host Startup Sequence' VAXLINK2
o Select
'ASCII Options'
Set the following options ON and all others OFF
'Translation to Host'
CR/LF = record seperator
Read Ctrl-Z as end of file
'Translation from Host'
Record seperator CR/LF
Write Ctrl-Z at end of file.
The ACSII option settings ensure tabs are NOT converted to spaces
during file transferes and any spaces at the end of the file are also
copied.
o If the Pc is to be used by the user to dial into the site you should
set the file transfer option to OLD-WRQ. The new WRQ software has a
problem with our dial_in X.25 network.
Select
'File'
'Transfer Setup'
'Protocol' OLD-WRQ
o Lets save these settings. From the main reflection menu select.
'File'
'Save'
Now the file transfer is setup lets configure the general terminal settings to
set the VTxxx types etc...
o Select
'Terminal'
'General'
'UPS set' DEC Supplimental
'NRC set' British
'Mode' VT320-8
'Terminal ID' VT320
'Cursor Keys' Normal
'Keypad' Application
'Display'
{Leave defaults}
'Keyboard'
'Backspace' Delete
'Margin Bell' OFF
'Warning Bell' ON {Beep on MAIL}
'Local Echo' OFF
o Lets save these settings. From the main reflection menu select.
'File'
'Save'
Now lets attach to the VAX and test the communication link.
o Select
'Connection'
'New'
'Connection Type' COM1, COM2, COM3 or LAT
'Pacing Transmit' Xon/Xoff
'Pacing Receive' Xon/Xoff
o Once complete use the 'Save Template As' button to save using a
name you recognise.
o Lets save these settings. From the main reflection menu select.
'File'
'Save'
You can now connect to this VAX type using
o Select
'Connection'
'Open'
{Select a name off of the list}
Using the instructions above you can setup & save multiple templates connecting
through different protocols to different machines. On the network copy of
Reflection, held in G:\RWIN, I setup several connections:
COM1(9600) RS232 LINE
LAT(SIFVX1)
LAT(SIFVX2)
LAT(SIFVX4)
LAT(SIFVX5)
LAT(SIFVX6)
LAT(SIFVX7)
LAT(SIFVX8)
so the user can select (OPEN) to any of these connections no matter what
commonications hardware/software they use on their pc. These settings are saved
in the SETTINGS.R2W file which is placed in the G:\RWIN directory.
Reflection emulates a DEC VTxxx keyboard using your keyboard. We have created
a set of keyboard translation masks for use with the different pc keyboards.
These masks are held in SIFVX1::CS$DISK:[CS.PCINFO] in the files
Name DOS Reflect Windows reflect
T5200 .KBM .RCL
DELL102 .KBM .RCL
PC .KBM .RCL
LTE286 .KBM .RCL
LK250 .RCL
They can be obtained from the Computer department and need to be placed in the
C:\RWIN directory. If you have access to the CS directory structure then use
'File'
'Transfer'
Set 'Host File Names' to CS$DISK:[CS.PCINFO]
Press 'Show Host Files' button
Select the local C:\RWIN directory
Transfer the DELL102.RCL file to the pc by selecting it and
using the 'Transfer' to local button or drag and drop the
file over the \RWIN directory.
Once the desired keyboard template file is in the C:\RWIN directory use the
following commands to buildthem into the current configuration:
'File'
'Open'
Change 'List File of Type' to '*.RCL'
Select DELL102.RCL which will run the file and incorperate
the selected keyboard changes.
o Lets save these settings. From the main reflection menu select.
'File'
'Save'
Now we need to update the pc configuration file with the serial number of the
Reflection for Windows. To obtai the serial number use:
'Help'
'About Reflection'
from reflections main menu.
Reflection 2 for Windows Shared Network Settings
- - - - - - - - - - - - - - - - - - - - - - - --
Reflection for Windows stores its main configuration settings in two places,
a REFLECT.INI file held in the windows system directory and in a file called
SETTINGS.R2W.
When you change the terminal characteristics / file transfer charcteristics
these are stored in REFLECT.INI. If you change the connection information,
colour, or the default button pallet then this is stored in SETTINGS.R2W.
By default the shared copy of Reflection for Windows uses the shared copy of
SETTINGS.R2W and a private copy of REFLECT.INI. If a user needs to change their
colour or button paletts then they use
'File'
'Save As'
F:\username\SETTINGS.R2W
to save the settings, but to use these settings at startup you need to change
how reflection starts up.
In the Windows program manager highlite the Reflection ICON then select
'File'
'Properties'
then change the
G:\RWIN.EXE to
G:\RWIN.EXE F:\username\SETTINGS.R2W
Paradox for Windows Basic
- - - - - - - - - - - - -
Install Paradox for Windows V1.0 from the master disks
o Start windows
G:
CD \WINDOWS
WIN
o From the Program Manager select
'File'
'Run'
{Place disk 1 in A: drive}
'A:\INSTALL'
to get yourself into the installation program.
o Your Name : Schlumberger
Company Name: Schlumberger
Sno : { as per Sno on disk }
Install from: A:\
Install to : G:\PDOXWIN
ODAPI : G:\WINDOWS\SYSTEM
o Do NOT load the fablous fonts. These are extra fonts for windows
supplied as extra's with Paradox for Windows.
Paradox for Windows General Settings
- - - - - - - - - - - - - - - - - -
We need to tell paradox for windows where the network control file is located
(P:\PDOX40\PDOXDATA) and what type of paradox database files to create
(International). These settings are held in a file called ODAPI.CFG. ODAPI.CFG
is located by a statement in WIN.INI which can be modified using the 'Local
Settings Utility'.
By default this ODAPI.CFG has been placed in the C:\WINDOWS\SYSTEM directory.
The following example assumes you are configuring for a local disk or the
inital configuration on the network drive, just swop G: for C:
o Open the 'Local Settings utility' from the Paradox group and change
Working Directory: C:\WINDOWS
Private Directory: C:\WINDOWS
ODAPI File : C:\WINDOWS\SYSTEM\ODAPI.CFG
o Open the 'Configuration Utility' from the Paradox group and change
Network Control File Directory: P:\PDOX40\PDOXDATA
System Language Driver : Paradox 'intl'
Paradox Language Driver : Paradox 'intl'
dBASE Language Driver : EnUS dBASE 437
At this stage if you are configuring for a local PC then you have completed the
exercise. If you are installing Paradox for Windows in the server then lets
take a copy of this ODAPI.CFG and place in G:\BLANKWS so that users using
NETWIN (see above) can have their own personal copy.
Paradox for Windows Shared Network Settings
- - - - - - - - - - - - - - - - - - - - - -
We need to tell paradox for windows where the network control file is located
(P:\PDOX40\PDOXDATA) and what type of paradox database files to create
(International). These settings are held in a file called ODAPI.CFG. ODAPI.CFG
is located by a statement in WIN.INI which can be modified using the 'Local
Settings Utility'.
o Open the 'Local Settings utility' from the Paradox group and change
Working Directory: F:\username
Private Directory: F:\username
ODAPI File : F:\username\WINDOWS\ODAPI.CFG
Replace the 'username' string with your username. If you are using the NETWIN,
see above) command file to use the shared MS Windows application, then you may
also have to change the WINDOWS directory part if you save your local specific
windows settings in a different subdirectory, eg: F:\DINGWALL\SPECIAL\ODAPI.CFG.
o Open the 'Configuration Utility' from the Paradox group and change
Network Control File Directory: P:\PDOX40\PDOXDATA
System Language Driver : Paradox 'intl'
Paradox Language Driver : Paradox 'intl'
dBASE Language Driver : EnUS dBASE 437
If when you open the 'Configuration Utiltiy' and you do not see the control
directory as being 'P:\PDOX40\PDOXDATA' then you have NOT pointed to the
correct directory for the ODAPI.CFG file.
At this stage you should be able to go into Paradox for Windows and access any
files on the system.
Take special note of the "ODAPI File : F:\username\WINDOWS\ODAPI.CFG"
line. This is used to point to the ODAPI configuration file which contains the
reference to the network control file. It is also used by paradox for windows
to store the 'Alias' information. This means that in a network environment each
user MUST have their own unique copy of this file. If a user maintains
different windows environment (see our NETWIN [environment]) then each
environment must have its own ODAPI.CFG file.
MS PowerPoint for Windows Basic
- - - - - - - - - - - - - - - -
Install MS PowerPoint for Windows from the master disks using our serial
number xxxxxxxxxxxxxxxxxxx
o Start windows
G:
CD \WINDOWS
WIN
o From the Program Manager select
'File'
'Run'
{Place disk 1 in A: drive}
'A:\SETUP'
to get yourself into the installation program.
o Place the PowerPoint for windows application files in
G:\POWERPNT
o Select Custom setup & verify you are happy with the selected option.
In the case of PowerPoint V3.0 the defaults load all files (13M).
o Slect the 'Install Now' button.
o Follow the instructions & feed in the appropriate disks.
The installation time took about 1 hr.
MS PowerPoint for Windows General Settings
- - - - - - - - - - - - - - - - - - - - --
There are no general settings..
MS Powerpoint for Windows Shared Network Settings
- - - - - - - - - - - - - - - - - - - - - - - - -
MS PowerPoint v3.0 stores its configuration settings in a file called
POWERPNT.INI held in the user specific windows network directory:
F:\username\WINDOWS\POWERPNT.INI
These settings contain information on current working directories, template
directories, etc... Mostly settings in this file is self maintaining when you
move around inside PowerPoint, but it is important that powerpoint is told
where this file is located.
A line in WIN.INI points to the location of POWERPNT.INI.
[Microsoft PowerPoint 3]
DefaultDirectory=F:\dingwall\windows
You can use the windows NOTEPAD editor to change this setting to you local
specific windows directory. A default POWERPNT.INI file should have been
created in this directory by NETWIN.
If you get an error message like:
'Sorry, cannot find POWERPNT.INI. You should run Powerpoint Setup.' then you
know your line in WIN.INI is not set correctly. The default POWERPNT.INI came
from G:\BLANKWS.
DEC LK250 Keyboard Installation
===============================
When you install any keyboard you normally have to provide a keyboard driver at
several levels:
DOS
MS WINDOWS
Applications
The drivers for the DEC LK250 keyboard are available from the DEC Pathworks for
DOS Client file service disk. When a driver is mentioned below you will need to
search for these drivers on that disk (see the CONFIGURING_DEC_PATHWORKS.TXT on
how to make a connection) as with each revision DEC may move the drivers into
different directories.
DOS
---
In the PC's AUTOEXEC.BAT you substitute the normal KEYB program with KEYBRD and
DECKEYB. You use the appropriate keyboard type, STDUK.KEY.
The following lines of code start the keyboard software used to correctly map
the Digital LK250 keyboard symbols sing the DEC LK250 keyboard attached to this
PC. KEYBRD & DECKEYB are software programs obtained from the DEC PCSA V4.1
Client software. They do not come with the keyboard. Without this software some
of the keys on the keyboard will not produce the same character on screen when
pressed.
C:
CD \DECNET
KEYBRD.EXE
DECKEYB.COM STDUK.KEY
CD \
MS Windows
----------
For the MS Windows keyboard driver to fuction correctly, including in a DOS
box, you have to install the LK250 drivers as per the DOS instructions.
We use the manual installation of the LK250 keyboard drivers. which means we
must locate the following files:
LK250.DRV
XLAT437.BIN
DECUK250.DLL
VKD250.386
and place in your C:\WINDOWS\SYSTEM directory, or if multiple people are to
user these drivers from the shared windows directory, in G:\WINDOWS\SYSTEM. You
should note that there are different files DECUS250.DLL, DECUK250.DLL, etc...
so copy all appropriate files. (In our case we only have the UK version
installed in the shared directory.)
The following changes need to be made to your SYSTEM.INI file, using the
NOTEPAD editor & then a restart of windows.
LK250 Settings Original Keyboard Settings
------------------------------------- --------------------------
[Boot]
Keyboard.drv=LK250.DRV KEYBOARD.DRV
[Keyboard]
subtype=50 {blank}
type=k 4
oemansi.bin=XLAT437.BIN {blank}
keyboard.dll=DECUK250.DLL kbduk.dll
[boot.description]
keyboard.typ=Digital LK250 Keyboard Enhanced 101 or 102
[386Enh]
keyboard=vkd250.386 *vkd
Applications
------------
The DEC windows drivers either emulate a 84 keypad keyboard at the dos prompt
or provide a full function keyboard to windows. What I mean by a full function
keybaord is that if you press a key on the keyboard you will see the symbol
apearing on the screen of the key being pressed. Normally for DOS character
cell applications everything works as normal.
Some applications can be told the exact keyboard type so that when used in
conjunction with some form of Terminal Emulation package the keyboard acts just
like a normal VT200/VT320/etc keyboard.
As we use a teminal emulator to the VAX, called Reflection for DOS and
Reflection for Windows. See the section 'Reflection 2 for Windows General
Settings' on how to setup & use the LK250 keyboard using this emulator.
Other emulators also have a setup that can be used to define a LK250 keyboard
is being used. Normally you select this keyboard type then save the
configuration in a setup file. You then use this setup file by calling the
emulator application followed by the settings file name.
R2 R2.CFG Reflection 2 for DOS
R2WIN SETTINGS.R2W Reflection for Windows
VT320 SIFVX1.320 Dec's windows emulator
NETWIN & Its Usage
==================
NETWIN is a local command that a user can type to start the shared version of
MS Windows V3.1 (or above in the future) and various shared applications like
,MS Excel, MS Work for Windows, MS Powerpoint, Borland Paradox for Windows
and Walker Richard & Quin's Reflection 2 for Windows.
By using shared copies of these applications we hope to benifit from:
o Disk space savings of appliation code on the network
& users local hard disks.
o Common configuration settings.
o Common Applications & versions.
o Reduced company wide upgrade times.
o Global license counting.
o Hardware version stability.
MS Windows has been setup using the common sharing techniques used for the
instalation option SETUP /N, which has been described in detail elsewhere in
this dcument. This allows individul users to have their own copies of the basic
windows files (local specific settings) while sharing common applications code &
drivers. Because local specific settings can be altered by each user, each user
can taylor their preceived environment to their needs while sharing common
applications code.
In the future it is hoped that as new applications are brought on line into the
shared area's individual user can imeadiatly use these new facilities. See the
section on 'Adding/Updating new MS Windows Applications'.
As basic applications are in a shared area we implement global license
counting. Either the application will encumpose their own license mechanism or
we can use third party license counters on application programs. At our site we
hope to move from a non licenseing system in several stages. Currently we
assume the user has the right to use the application if they have the
installation diskette (setup disk). We install the application onto the server
with no license counting but with the agreement of the software vendor that we
can operate in this mode (unless the license count is built in of course) for a
transition period, about 1 month. We convert each user to use the shared
applications, while at the same time removing any applications from the users
local hard disks. Any installation disks then go into the server pool, after a
sutable upgrade fee has been paid to move the application version to that of
the server version. At the end of the transition period we fix the license
count each application to equal the number of installation disks trawled from
users. We are then running a concurrent licensing system for these shared
applciations. If we want to upgrade then we can talk bulk upgrades with
application suppliers.
Each new version of software places more stress on hardware. Using a global
upgrade approch we intend to use pear pressure to upgrade hardware to an
acceptable level which can run the current shared version of the application.
An acceptable level can either be set from the user point of view, being able
to use existing hardware with no upgraded, or from a system point of view where
either the application can not run at all on the hardware or to make it work
required great feats of ingenuity to run this time but it is known that a
further version of the software will not work. We would probably apply the
80-20 rule seeking the 20% to upgrade.
To actualy use these shared windows application we use the NETWIN command. This
has been made available to all users by placing it in the file servers' public
utility directory, to which all users have access.
NETWIN [directory]
The optional directory tells NETWIN to use an alternative local user specific
windows configuration setup.
To use a shared copy of MS windows applications a user needs to have two
different directories, one for his/her own specific settings and another for
the shared settings/applications.
At this site we use:
F:\username:\WINDOWS
to store the user specific settings and:
G:\
| WINDOWS
| EXCEL
| WINWORD
| etc..
to store common files. The user specific settings files can be written to by
users while the shared settings (whole G: drive) is set read only. The user
specific settings are normally those to altered by applications or used by
applications for such things as default directories. They also tend to be files
that are written to by applications on exit.
By default the user specific settings are placed into a directory pointed to by
serveral variables:
NDR network drive F
NDI network directory \DINGWALL
Thus the NETWIN routine knows the users login network drive and directory:
F:\DINGWALL
Normally these variables are set in the users netware login script by using:
DOS SET NDR="F"
DOS SET NDI="\DINGWALL"
If these variables are not set when this command file is run an error message
will be displayed to the user.
The last part of the user specific directory (default WINDOWS) is supplied as a
parameter to this command file.
NETWIN F:\DINGWALL\WINDOWS
NETWIN WINDOWS F:\DINGWALL\WINDOWS
NETWIN SPECIAL F:\DINGWALL\SPECIAL
NETWIN XADAPTER F:\DINGWALL\XADAPTER
This allows each user to hold special configuration setups to be used on
special hardware configurations or system setups. When a user runs this command
file for the first time or when (s)he uses a different special configuration
directory for the first time, a set of defaults are copied into that user
specific directory from G:\BLANKWS. These defaults are maintained when new
applications are added to the shared area. The user is then told to contact MIS
for application configuration instructions which are in fact the application's
Shared Network Settings which are described in this document.
Under normal running conditions the user specific windows directory is located,
then the shared network application area location is attached to the G: drive
as we have prebuilt all applications to use the G: drive. Then we check to see
if the user has the TEMP veriable set as most windows applications need
this to opperate correctly. Normally TEMP is set on the PC to point to a local
hard disk. In the off chance that it is not set we point it to
F:\username\TEMP, creating the directory if required. You should note that the
user needs >5M of free disk space to opperate correctly (calculated from the
largest postscript file sent to a printer). The users applications search PATH
is then stored so we can add the shared WINDOWS network directory while being
able to restore it after we exit MS Windows.
To start windows we just reference the user specific copy of WIN.COM using the
full directory path. This allows the user to return to the same directory from
which they started NETWIN from. By specifying the user specifc windows
directory MS windows uses the initialisation files in that directory, which can
be altered by the user without effecting other users. Any files MS windows
finds missing from the user specific directory MS windows searches the search
PATH, hence it finds the shared MS windows copy (which is read only) and hence
uses all the shared drivers and applciations.
Once into MS Windows, applications are able to find their code & utilities
because they have been installed to expect their files on the G: drive. See the
icon's "properties" to see these locations. After MS Windows exits we restore
the users original PATH and then disconnect from the shared applications drive
G:. This stops errors on finding COMMAND.COM if the user logs out if we had
left G:\WINDOWS on the users path.
For an example of what NETWIN looks like see 'Appendix A, Example of
NETWIN.BAT'.
Adding/Updating new MS Windows Applications
===========================================
The following outline some techniques used to add new Windows application into
the shared area.
When installing software the installation program normally asks for source and
target directories, from which it installs applcation code & updates startup
parameters. In the case of Microsoft Windows V3.x normally the code go into the
target directory & the startup parameters, which are written into various
files, always reference back to the target directory name.
We always use a single target for all MS applications, the DOS drive G:. This
is because we only ever have to sacrifise one drive letter from DOS's normal 26
drive letters (A-Z). As each MS Windows applications installs into a
subdirectory on the target drive with one G:\ designation we have access to all
current & future shared application.
I will try to explain some problems then take you through a setup which avoids
these problems. The main problems with setting up a shared windows application
area are:
o Target directories in *.INI files
o Target directories in *.GRP files
o Target directories in REG.DAT
o Target directories in other configuration files
o User default directory settings
MS Windows uses the *.INI files to store application default settings which
point to utility tools, fonts, spell checker's. Normally they point to the
shared area for common files & you edit others to point to user specific
settings, as defined in the 'Shared Network Settings' for each application in
this document. If you get these settings wrong during installation time when
the user uses the shared applciations they will be pointed at the wrong
location.
*.GRP's point to program groups. These group files contain information like
what icons are in what group, which program an icon runs and what icon graphic
should be displayed. You can use the program Manager's File/Properties to view
edit these settings. Normally for core MS windows appelets (write/notepad
etc..) you do not specify a directory with the program
NOTEPAD not G:\WINDOWS\NOTEPAD
while with non windows core applications you do specify the the full directory
G:\EXCEL\EXECL
Normally if installed correctly you get no problems. The thing you may be trip
up on is the lcoation of the ICON graphic image. If you install the application
into a directory that is not the target then if the user changes the icon you
get the default program manager icon and not one referenced to the application.
REG.DAT contains some imbedding OLE data, which includes the target drive name
& directory for the application being installed. If you get something wrong
then use REGEDIT to fix the problem.
When loading the initial basic shared windows system on the server I followed
the steps outlined in 'Loading Windows & Windows Applications On A Server'
detailed in this document. At the end I had all basic application installed on
the server (Word, Excel, Reflection, Paradox etc..) all configured for the G:
drive as though this was a single user system which just happended to be loaded
on the G: drive.
We use the G: drive at this stage because this is the final shared drive the
users will connect to, by using NETWIN, the shared applciations. Also by using
the same drive designation we correctly configure the contents of *.INI
defaults and *.GRP settings including icon file locations.
You can also at this stage setup application defaults, which are outlined in
the applciations 'General Settings' in this document.
Once you have completed this stage you have generated various defaults.
Probably the next thing you should do is examine the contents of all *.INI
files looking for all references to the G: drive so you can understand what is
going on. Several applciations document these settings in help files or online
help. Further sources of information are third party books.
Some applications store settings in *.INI files which by default are located in
their target install directory. You should examine and understand these aswell,
but more on those later.
Building BLANKWS
- - - - - - - --
You have effectivly built the shared area. Lets now generate a default set of
files that can be copied to a user user local specific directory (or in MS
speak the target SETUP /N directory). It is usefull to maintain a seperate
directory in which default conditions are maintained so lets build it.
o Follow the instructions to generate a SETUP /A directory.
o Create a target G:\BLANKWS directory then use SETUP /N to
populate this directory with the user specific windows settings.
o Copy the default conditions into this directory.
XCOPY G:\WINDOWS\*.INI G:\BLANKWS
XCOPY G:\WINDOWS\*.GRP G:\BLANKWS
XCOPY G:\WINDOWS\REG.DAT G:\BLANKWS
Now we have a default user specific setup files that NETWIN can copy into user
environments.
Testing Shared Windows Applciations
- - - - - - - - - - - - - - - - - -
To test you have a valid shared area setup you can use the following
instructions to access this shared area.
Before we do so you should ensure that G:\ drive location is set to read-only
so general users and you while testing can NOT write to the shared area's. This
should pick up any applications that are writing to configuration files in the
shared area, which in my case I have would move to G:\BLANKWS and alter
settings in the appropriate *.INI file.
o On novell we set this shared area to Read + Filescan for
the group EVERYONE.
o Create a windows directory for the user in their account:
F:
CD \username
MKDIR WINDOWS
o Copy in the basic windows configuration
CD \username\WINDOWS
XCOPY G:\BLANKWS\*.*
o So this will work in the users directory lets patch PROGMAN.INI
to pick the *.INI (application specific initialisation files) and
*.GRP (group file icons & group contents).
We need to change G:\WINDOWS\xxxxx to
F:\username\WINDOWS\xxxx
This can be achieved using the DOS 5 editior or EDLIN.
o Logout of the privalaged account & login with a non privalaged
account. If your novell account is a supervisor equivalent then
think about geting the SUPER utiltiy tool which allows you to
turn this supervisor equivalence on/off.
o Now we should be able to access this version of windows by using
PATH=G:\WINDOWS;***rest of current path****
F:
CD \username\WINDOWS
WIN
When everything is setup correctly this will be done automatically
for us using a NETWIN.BAT command file in SYS:PUBLIC
For development purposes lets do this manually.
Move around each application looking for things that do not work correctly
which should point to a configuration error. To correct the error either place
the application specific INI file, for example POWERPNT.INI, in BLANKWS and
hence F:\username\WINDOWS or edit the application default directories etc as
per the application 'Shared Network Settings' as specified in this document.
The general idea is to generate a set of *.INI & other files in BLANKWS which
are to act as default for new configuration. Any application specific
instructions can then be applied by the user (or MIS department for that user)
when the shared windows environment is entered for the first time.
In our case the default *.INI files contain references to:
F:\username\WINDOWS
so the user need only ammend 'username' to point to their local settings.
Once the default settings have been reached I copy these file into G:\BLANKWS
and G:\WINDOWS.
Updating/Adding Applications
- - - - - - - - - - - - - --
Installation programs seam to do several things:
o Add/update new drivers/programs in the \WINDOWS... directories
o Add/Update new drivers/programs in the \applciation.. directories
o Alter *.INI files
The first two affect the contents of the shared windows area while the last
effect the default BLANKWS configuration and hence the user local specific
settings.
You could just install over the shared windows area using a privalaged account,
but as I am not confident in the Installation's programmer's ability to
understand all configuration options and settings I prefer to install into a
copy and compare files updated/added/deleted then manually move these into the
shared area.
I also would not install one version of a product over the directcoy of a
previous revison. There have been countless times that this is said to be ok
but infact does not work. Always start from a fresh bais.
You can always get to a fresh bais by:
o Installing windows into a directory, by using the SETUP
instructions. You could use a copy of the shared
G:\WINDOWS\... directory structure if the application
product has not been installed previously.
o Take a backup of the test area. This resets the archive bit
which can be used later to find out what files have been
added/deleted/changed.
o Installing the new product
You should install or copy into a test system G:\ directory so you do not
contaminate the global shared area.
Once you have installed the new product you need to:
o Compare *.INI files
o Look for configuration files that are candidates to go into
BLANKWS, hence the final user local specific directories.
o Application defaults.
o New/changed/deleted drivers.
Armed with the above information you can manually copy the updated drivers into
the shared windows area, perform all the updates etc.. to the default *.INI
files and add the new program groups. (All by hand.)
Note: I hope to work out methods of coping with the following problems:
o Automatically setting up the values of NDI & NDR at user login time
by writing a program that can automatically set these values. I have
tried to write an application in 'C' to alter the users Master
Environment Variable space ( CURDRIVE & CURDIR ) to set these
variables from inside the novell master login script but have been
unsucessfull in producing reliable programs that work on all my pc's.
o Writing an INI file editor to alter the content. For instance the
G:\BLANKWS have had all appropriate lines set to F:\username\....
which are then altered for each user. The main file is PROGMAN.INI
which needs to be altered otherwise the user does not get the
basic group files.
I know there are INI file modifiers around but I need to find one
to which I can get the source code. This is because if the author
does stop support we can continue to use the product. Probably in
reality there will be another product around. With the source code
we at least have the option of internal support.
o Users using shared applciations while using their own copies of
WINDOWS core from their local drives. It is possible to install
MS Windows on a local hard disk and then use the application search
to locate the shared application. This normally locates the main
executable image file and pops it up as an icon on the desktop.
The main problem area's seen to date are that the user's local
specific settings configuration files (*.INI) are NOT updated for
the application. This may mean that site defaults are not in place.
Another effect seams to be with error messages being generated when
running several tutorials (Excel V4.0 & others).
o Understand and document the was windows searches for drivers, dll's
INI's.
o Locate windows applications that try and write into shared read only
areas but do not report a read only error message. This can be
confusing to the user when they think a setting has been saved but
infact has not.
o Locate for each application the list of configuration settings in
the *.INI files. Most settings are not documented in a single
location for applications. Without this information setting up &
using in a shared environment is difficult. There does not seam
to be any real way to locate these. Look in online help,
readme files, manuals & third party books. It is important to
stress in all technical conversions with the application vendors
that this information is important.
o Investigate the use of INI file manager systems like WINLogin or
Saber Menu's. I have NOT used these techniques initially as most of
the problems relating to installing windows on a server is in
understanding on an application by application basis what control
files (*.INI) are being used by that application and the settings
used in these control files. Some applications also have other
datafiles to control defaults, some can be shared, some not.
If you do not have an in-depth understanding of what settings are
being ammended, what drivers are being added and where all these
files are located, you will not have sufficient knowledge on how to
operate a network windows environment.
I tend to like the idea of having a central copy of defaults being
presented to a user when windows is started, then when windows exists
a central manager remembers any changes made for that user. This
should be able to cope with different hardware options presenting
the user with the best fit for the specific hardware being used. It
should also be able to present the user with different desk top
configurations so that this caters for users using one set of
windows setups for day to day specific business applications and
another for personal settings. By business applciations this may mean
a windows setup setup to provide a specific business need like
having the order control/ purchasing/ finance applications etc..
without having loads and loads of icons or groups on the
screen. In the short term the NETWIN command files uses different
directories to hold these taylored configurations.
Maybe in the future some enterprising company will write a device
driver interface that intercepts all access to *.INI files, *.GRP
and application specific database files and pulls these settings
directly from a shared database(s), thus removing the need for
multiple small files per user or local specifc environment.
o It would be nice if the vendors of the software would store the
version number of the application that has setup these configuration
options such that in the future an upgrade can automatically weed out
the obsolete settings the first time it is run.
o It sould be nice if vendors of the software provided utility tools
to ammend all *.INI files etc of users local specific settings if
the application has been installed in a shared area.
Check the use of the setup application generation tool to write this
ourselves.
Appendix A, Example of NETWIN.BAT
=================================
@ECHO OFF
rem !
rem !
rem ! Title : General User Network Windows Startup
rem ! Name : SIFN01/SYS:PUBLIC\NETWIN.BAT
rem ! Author: Date: Comments:
rem ! Ian Dingwall 26-MAy-1993 File created.
rem !
rem ! Calling Interface
rem ! =================
rem !
rem ! This routine has to be in the users current search path, normally
rem ! in the SYS:PUBLIC\ directory. Once available you use:
rem !
rem ! C:\ NETWIN [directory]
rem !
rem ! to start the shared MS Windows Applications. The optional directory
rem ! tells NETWIN to use an alternative user windows configuration setup.
rem ! (See functional outline.)
rem !
rem ! Functional Outline
rem ! ==================
rem !
rem !
rem ! To use a shared copy of MS windows applications a user needs to have two
rem ! different directories, one for his/her own specific settings and another
rem ! for the shared settings/applications.
rem !
rem ! At this site we use:
rem !
rem ! F:\username:\WINDOWS
rem !
rem ! to store the user specific settings and:
rem !
rem ! G:\
rem ! | WINDOWS
rem ! | EXCEL
rem ! | WINWORD
rem ! | etc..
rem !
rem ! to store common files. The user specific settings files can be written to
rem ! by users while the shared settings (whole G: drive) is set read only.
rem !
rem ! The user specific settings are normally those to altered by applications
rem ! or used by applications for such things as default directories. They also
rem ! tend to be files that are written to by applications on exit.
rem !
rem ! By default the user specific settings are placed into a directory pointed
rem ! to by serveral variables:
rem !
rem ! NDR network drive F
rem ! NDI network directory \DINGWALL
rem !
rem ! Thus this routine knows the users login network drive and directory:
rem !
rem ! F:\DINGWALL
rem !
rem ! Normally these variables are set in the users netware login script by
rem ! using:
rem !
rem ! DOS SET NDR=F
rem ! DOS SET NDI=\DINGWALL
rem !
rem ! If these variables are not set when this command file is run an
rem ! error message will be displayed to the user.
rem !
rem ! The last part of the user specific directory (default WINDOWS) is
rem ! supplied as a parameter to this command file.
rem !
rem ! NETWIN F:\DINGWALL\WINDOWS
rem ! NETWIN WINDOWS F:\DINGWALL\WINDOWS
rem ! NETWIN SPECIAL F:\DINGWALL\SPECIAL
rem ! NETWIN XADAPTER F:\DINGWALL\XADAPTER
rem !
rem ! This allows each user to hold special configuration setups to be used on
rem ! special hardware configurations or system setups.
rem !
rem ! When a user runs this command file for the first time or when (s)he uses a
rem ! different special configuration directory for the first time, a set
rem ! of defaults are copied into that user specific directory from G:\BLANKWS.
rem ! These defaults are maintained when new applications are added to the
rem ! shared area. The user is then told to contact MIS for application
rem ! configuration instructions.
rem !
rem !
rem ! Under normal running conditions the user specific windows directory is
rem ! located, then the shared network application area location is attached to
rem ! the G: drive as we have prebuilt all applications to use the G: drive.
rem ! Then we check to see if the user has the TEMP veriable set as most windows
rem ! applications need this to opperate correctly. Normally TEMP is set on
rem ! the PC to point to a local hard disk. In the off chance that it is
rem ! not set we point it to F:\username\TEMP, creating the directory if
rem ! required. You should note that the user needs >5M of free disk space to
rem ! opperate correctly (calculated from the largest postscript file sent to
rem ! a printer).
rem !
rem ! The users applications search PATH is then stored so we can add the
rem ! shared WINDOWS network directory while being able to restore it after
rem ! we exit MS Windows.
rem !
rem ! To start windows we just reference the user specific copy of WIN.COM
rem ! using the full directory path. This allows the user to return to the same
rem ! directory from which they started NETWIN from. By specifying the user
rem ! specifc windows directory MS windows uses the initialisation files in
rem ! that directory, which can be altered by the user without effecting other
rem ! users. Any files MS windows finds missing from the user specific
rem ! directory MS windows searches the search PATH, hence it finds the shared
rem ! MS windows copy (which is read only) and hence uses all the shared
rem ! drivers and applciations. Once into MS Windows, applications are able to
rem ! find their code & utilities because they have been installed to expect
rem ! their files on the G: drive. See the icon's "properties" to see these
rem ! locations.
rem !
rem ! After MS Windows exits we restore the users original PATH and then
rem ! disconnect from the shared applications drive G:. This stops errors on
rem ! finding COMMAND.COM if the user logs out if we had left G:\WINDOWS on the
rem ! users path.
rem !
rem !
rem ! Source Code Instructions
rem ! ========================
rem !
rem !
rem ! See if the user supplied a working directory for windows below their
rem ! own personal account structure. If not lets use WINDOWS.
rem !
SET WDIR=%1%
IF "%WDIR%" == "" SET WDIR=WINDOWS
rem !
rem !
rem ! If the user does not have the variables required to locate the network
rem ! windows personal directory then complain to the user.
rem !
rem !
IF "%NDR%" == "" GOTO Missing
IF "%NDI%" == "" GOTO Missing
GOTO Have_variables
:Missing
rem !
rem ! Lets complain.
rem !
ECHO ******************************************************
ECHO **** The variables NDR, network drive eg: NDR=F ****
ECHO **** NDI, network directory eg: NDI=\DINGWALL ****
ECHO **** have not been defined in your login ****
ECHO **** script. Plese define.... ****
ECHO ******************************************************
PAUSE
GOTO Exit
rem !
:Have_variables
rem !
rem !
rem ! Ensure the TEMP veriable is defined and pointing to a directory.
rem !
IF "%TEMP%" == "" GOTO No_temp
GOTO Have_temp
:No_temp
rem !
rem ! Ensure the directory is created.
rem !
MKDIR %NDR%:%NDI%\TEMP
SET TEMP=%NDR%:%NDI%\TEMP
rem !
:Have_temp
rem !
rem !
rem ! Attach to the network directory on which the shared windows programs
rem ! are stored. If this area is moved on the file server just change here.
rem !
MAP ROOT G: = TESTFS:\IAN
rem !
rem !
rem ! Check to see the users copyies of the windows *.ini files are there.
rem !
IF EXIST %NDR%:%NDI%\%WDIR%\WIN.COM GOTO Win_there
rem !
rem !
rem ! Lets complain.
rem !
ECHO *********************************************************
ECHO **** You have not used the network version of ****
ECHO **** windows before. When you press return to ****
ECHO **** continue several default files will be ****
ECHO **** placed in your %NDR%:%NDI%\%WDIR% directory ****
ECHO **** ****
ECHO **** Refer to MIS on how to setup the applications ****
ECHO *********************************************************
PAUSE
MKDIR %NDR%:%NDI%\%WDIR%
XCOPY G:\BLANKWS\*.* %NDR%:%NDI%\%WDIR% /V
rem !
:Win_there
rem !
rem ! Take a copy of the users path so it can be restored.
rem !
SET OPATH=%PATH%
rem !
rem ! By adding the G: drive to the path novell makes it a Search drive
rem ! This allows windows to use the shared copies of files from the shared
rem ! directory.
rem !
PATH=G:\WINDOWS;%PATH%
rem !
rem !
rem ! Start windows specifying the full drive specification so the users
rem ! default directory is not moved.
rem !
%NDR%:%NDI%\%WDIR%\WIN
rem !
rem !
rem ! Restore the users original path. This means the G: drive is no longer
rem ! a search path.
rem !
PATH=%OPATH%
SET OPATH=
rem !
rem !
rem ! Remove the directory the user wants windows run in.
rem !
SET WDIR=
rem !
:Close_win
rem !
rem ! Remove the network shared windows directory.
rem !
MAP DEL G:
rem !
rem !
rem ! Exit from this routine.
rem ! =======================
rem !
CLS
:Exit
rem !
rem !{end}
<end>