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. 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 . 04-21-93 11:32a .. 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 } 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}