THIS FILE IS OBSOLETE! Please obtain files:
	w95inst7.zip	Powerpoint v7 illustrated detailed guide
	w95insps.zip	same, Postscript version
	msoff95.txt	how to install MS Office 95
	drived.txt	internal note on temp server space
These files pertain to the original issue of Win95, not the OEM or other
editions.
---------------------------------------------------------------------------
							18 July 1995
						Last update 10 Aug 1995
		(C)Copyright 1995, Joe R. Doupnik and consultants 
		of the Engineering Student Computer Laboratory
		Utah State University
		Logan, Utah 84322

	Below is a summary of the steps taken at Utah State University
to create a boot floppy to run Win95 from a read-only NetWare file
server. The clients have no hard disks, only a nice RAM drive C in this
case. The version of Windows 95 is build 950 R6.

	Install Win95 on a station with a hard drive. Call it Admin, 
for the system administrator. After it is operating well run NETSETUP
in the NETTOOLS subdirectory. This step will create a working Win95
installation source directory on the file server of your choice.
	The netsetup menu asks for the UNC path where material will
be written. Use  \\server\vol\dir  and in these examples "dir" was
named win95. It will ask if you wish to create a default user profile,
and the answer will be YES. The profile will be text file MSBATCH.INF,
stored in \win95, and its contents are shown below. Hand edit lines
to match this example in the [NETWORK] section.

File \win95\msbatch.inf -
------------
[SETUP]
Express=0
InstallType=3				<<< means Custom, it's ok
Verify=0
CCP=0
ProductID=950R6
ProductType=1
Uninstall=0

[NETWORK]
WorkstationSetup=1
DisplayWorkstationSetup=0
HDBoot=0			<<< defaults to 1: hard drive install
RPLSetup=0			<<< defaults to 1. 0 0 means floppy install.
SaveSUBOOT=1			<<< add this line to preserve floppy image
display=1			<<< show us progress during setup

[NameAndOrg]			
Name="Engineering Student Lab"	<<< Optional, to save typing later
Org="Utah State Univ"		<<< ditto

------------
	At the end of the menu box for netsetup it says to create another 
profile for floppy boot stations. This step fails if msbatch.inf is write
protected, and overall the step seems to be a repeat of the previous
msbatch.inf one. However, one of these two creates file netsetup.pol
(for Policy) in \win95; it's a HSR file and we rename it to get it out
of the way. Overall, I think the end of menu step should be omitted.
	At this point you have Win95 files on the server in \win95,
ready to be used to create clients. The directory structure looks like
this:

 Directory of P:\WIN95
SUWIN        <DIR>		<<< really a hidden directory
SYSTEM       <DIR>
COMMAND      <DIR>
INF          <DIR>
PROGRA~1     <DIR>
FONTS        <DIR>
CONFIG       <DIR>
MEDIA        <DIR>
CURSORS      <DIR>
SHELLNEW     <DIR>
USER         <DIR>		<<< locally created, where user Win95 goes


	Now the client installation part, which is where the difficulties
reside.
	We need to create a "home" directory holding that user's Windows
material. In the examples here it happens to be \win95\USER but anywhere
will do nicely. Copy MSBATCH.INF to that directory from \win95.
	Prepare a network DOS boot diskette and log into the server with
it. It may contain memory management and VLMs, as mine do. But it MAY NOT
lead to existance of a drive C:. If Win95 gets ANY hint of a drive C: it
will use it as a hard disk installation point and you are dead. It can
be restored after we get finished. Login as user GUEST or whomever; I
used GUEST.
	The system manager should have given this user all rights to
\win95\user and only RF rights to \win95 itself. We will change all
rights to RF after we are done.

	CD to the \win95\user directory. Give DOS command

	f:\win95\setup msbatch.inf /T:f:\win95\user\temp

Now, the /T: item says use that directory as a scratch work area, and 
believe me it is required. We created a temp subdir under user to make 
life simpler. We MUST use phrase msbatch.inf for setup so it does a floppy
install rather than a hard disk install. Note that we have fixed msbatch.inf
as shown above.
	Setup will ask where to place the final Win95 user-ized material,
and my answer was f:\win95\USER. Do not let it step on your real Windows 3
directory at this stage. Any directory will do, but it must have full
NW priv's during installation.
	Setup may ask for Custom or fast install, say Custom to retain
some control. 
	It will ask about scanning for all Plug And Play devices or to 
choose individual ones. Take the recommended "scan for all" choice because 
selecting individual ones most often ends in a hung machine during the PNP 
examination process; go figure. PNP is a very large problem, so be prepared
to try and try again.
	At the end of PNP scanning setup will show the current selections.
You can be cautious and use the most generic video etc at this point, or
be brave and be prepared to try again later. If PNP crashes the machine
then yank what you can from the client and repeat; leave frills for after
Win95 is running. These details are recorded in the Win95 registry, hidden
files SYSTEM.DAT and USER.DAT.
	Setup may complain about not enough disk space; ignore it. But
preallocate about 100MB for this installation process just to be safe.
	When the chance arrives to select networking components pass it
by. I use VLMs, and at the moment I bring them up at DOS 7 level during
a bootup. That means they are started in autoexec.bat. MS networking is
not what it's cracked up to be and I leave it alone. Thus we clear out
all networking choices in setup; no boards, no clients, no nutt'in. More
comments on this at the very end of the note.
	Leave the regular DOS boot floppy in the machine during these
steps because it will be read and used to form the Win95 boot image.
Setup will notify you near the end to insert a floppy to hold that image.
In the meanwhile the image is put together in \win95\USER\SUBOOT, and we
want to keep that stuff. Just before preparing the final boot disk image
setup will read the regular DOS floppy, copy autoexec.bat to ~\suboot,
copy all user files there, will not copy config.sys, will edit autoexec.bat
to remove NetWare shell components.
	Now setup writes the boot floppy image to a handy spare floppy.
Mark it. Take it aside and do some editing before proceeding; leave setup
waiting for you.

	In config.sys supplement the single FILES=100 line with

	device=himem.sys		(or your preferred memory manager)
	device=emm386.sys
	devicehigh=ramdrive 9000 512 256 /a	( a 9MB drive C: ram drive)
	devicehigh=ansi.sys			( for nicer DOS screens)
	shell=a:\command.com /p /e:800  	( for environment space)

	In autoexec.bat restore your NW VLM lines. In my case I also copy
command.com to that C: RAM drive, so we also say:

	@echo off
	echo <ESC>[1;37;44m			( bold white on blue screen)
	copy command.com c: >nul
	set comspec=c:\command.com		( fast access)
	normal DOS SET's go here
	your VLM shell stuff goes here
	F:					( your normal network drive)
	login GUEST				( do network login NOW)
	MAP INS S2:=F:\WIN95			( must have this for Win95)
	MAP INS S3:=F:\WIN95\COMMAND		( must have this for DOS)
	MAP INS S4:=F:\WIN95\USER		( optional but nice)
	SETMDIR /r:F:\WIN95\USER		( IMPORTANT LAST LINE)
	@echo on

	The SETMDIR item tells the startup Win95 image where to find
the main Registry of secrets. The miniregistry has already been read
from floppy to reveal that machine's hardware scoop, and the main reg
is needed to assign rights, get screen details, whatnot. This line must
follow a network login so that we can point at the user's area on the
file server. The registries (mini and full) have these f:\win95...
paths embedded within them; ditto for our hardware details.

	Back on the server, locate text file \win95\user\suboot\MSDOS.SYS.
Yes, it's a short text file. Edit it to say:

	[Paths]
	WinDir=f:\win95\user		(where user's Win95 debris is found)
	WinBootDir=A:\
	HostWinBootDrv=A
{Note added later. WinBooDir=C:\ is a better choice for RAM disk based
machines. It means the place where the registry files will be stored
after installation, and thus stops creating backups of them on the file
server Win95\USER directory.
HostWinBootDrv=A points to the device files loaded in config.sys. To remove
this item use  device=ifshlp.sys  in config.sys.}

	[Options]
	BootMulti=0			( was 1, no boot manager needed)
	BootGUI=0			( was 1, 0 stops at DOS level)
	Network=0
{Note added later. You may wish to add line logo=0 here to supress display
of the sky picture.}

	Also edit system.ini in the \win95\user directory and add two
lines to the enhanced section:

[386Enh]
PagingFile=c:\win386.swp	(swap file shares RAM drive memory)
SystemROMBreakPoint=false	(anti-stealth feature for QEMM)

	Now finish setup and reboot the machine with the new floppy.
A long time will elapse as the machine does yet another PNP scan of the
client. Be patient, it usually isn't broken, it may take 10 minutes.
Finally the sky picture vanishes and we get a DOS screen with the login
information. Had we left BootGUI=1 then no DOS screen; your choice.
	Type WIN. Eventually the green Win95 screen appears and the last 
phase of installation commences. Just stand back and watch. Leave the 
floppy in the drive, write enabled for now. If you get icons on the green 
screen you may cheer quietly; you've succeeded. But only quietly because 
Win95 is waiting for you to change any hardware item at all for it to become
a re-installation monster again. Changing hardware awakens the PNP monster 
and the registry revision stuff; be prepared to start over.
	Now, use SYSCON and leave only RF priv's in \win95 and descendents.
The new floppy is the boot floppy. The server is back to read-only for
clients.
	Upon a cold boot with the new floppy the system stops at DOS
level to do whatever you wish at the DOS prompt. Typing WIN brings up
the GUI interface. Shutting down the system hangs my machine for many
minutes until finally the C: DOS prompt appears again; it has not shutdown.
I use the Red Switch to depart.
	You can create special config.sys and autoexec.bat files for the
DOS shell. To create an MSDOS icon use the right mouse button on the green
screen, choose "shortcut" and the item is f:\win95\command\command.com.

	Here is what remains in the saved startup boot directory. IO.SYS
plus Command.com is DOS 7, many files are carried over from our regular
DOS client diskette, many files are Win95. These files plus your edits
plus the master boot record are the final boot floppy; keep them safe.

 Directory of P:\WIN95\USER\SUBOOT
437_UNI  001           727 04-04-94  12:22p
850_UNI  001           727 04-04-94  12:22p
ANSI     SYS         9,065 02-13-94   6:21a
AUTO     VLM         4,527 11-08-94   1:29p
AUTOEXEC BAK           452 04-13-95   9:15p	(original autoexec.bat)
AUTOEXEC BAT           868 07-17-95   3:52p	(Win95 edited rendition)
BIND     VLM         4,680 11-08-94   1:28p
PROTOCOL INI           121 07-17-95   3:59p
CONFIG   BAK           268 04-14-95  12:58p	(original regular config.sys)
CONFIG   SYS            11 07-17-95   3:52p	(just files=100)
CONN     VLM        10,833 11-08-94   1:28p
DOSRQSTR MSG         9,600 10-21-94   5:32p
FIO      VLM        18,234 11-08-94   1:29p
GENERAL  VLM         4,525 11-08-94   1:30p
IO       SYS       223,148 07-17-95   3:45p	(DOS 7)
IPXNCP   VLM        10,083 11-08-94   1:28p
IPXODI   COM        39,353 10-31-94   4:35p
IPXODI   MES         1,754 01-22-93   9:47a
IPXODI   MSG         4,089 09-15-94   4:02p
LOADHI   COM        21,629 11-13-91   6:02a
LOADHI   SYS        18,652 11-13-91   6:02a
LSL      COM        18,313 10-11-94  10:03a
MSDOS    SYS           115 07-17-95   8:22p
NDS      VLM         8,500 11-08-94   1:28p
NE2000   COM        21,188 11-23-93  11:31a
NET      001         1,841 10-05-94   5:13p
NET      CFG         1,921 04-13-95   9:51p
NET      WIN         1,921 04-18-95   5:03p
NETX     VLM        16,921 11-08-94   1:29p
NMR      VLM         9,842 11-08-94   1:29p
NWP      VLM         6,628 11-08-94   1:28p
ODIPKT30 COM         2,956 04-24-94   9:01a
PRINT    VLM         7,973 11-08-94   1:29p
QEMM386  SYS        89,831 11-13-91   6:02a
QEMMREG  COM           414 11-13-91   6:02a
RAMDRIVE SYS         5,873 02-13-94   6:21a
REDIR    VLM        14,777 11-08-94   1:29p
SECURITY VLM         7,978 11-08-94   1:29p
TRAN     VLM         1,545 11-08-94   1:28p
UNI_437  001         2,904 04-04-94  12:22p
UNI_850  001         2,776 04-04-94  12:22p
UNI_COL  001         1,752 04-04-94  12:22p
UNI_MON  001         4,312 04-04-94  12:22p
VLM      EXE        37,611 11-08-94   1:28p
WINHIRAM VXD        10,838 08-23-91   6:00a
WINPKT   COM         3,617 12-08-91  12:09a
WINSTLTH VXD        10,841 08-23-91   6:00a
ASPI2HLP SYS         1,105 07-11-95   9:50a	(cdrom stuff, discard)
CMD640X  SYS        24,626 07-11-95   9:50a	(ditto)
CMD640X2 SYS        20,901 07-11-95   9:50a	(ditto)
DBLBUFF  SYS         2,100 07-11-95   9:50a
HIMEM    SYS        32,935 07-11-95   9:50a
IFSHLP   SYS         3,708 07-11-95   9:50a
SETMDIR  EXE        57,209 07-11-95   9:50a	(registry pointer)
SETVER   EXE        18,939 07-17-95   3:52p	(trash)
SYSTEM   DAT        16,384 07-17-95   3:52p	(Registry)
COMMAND  COM        92,870 07-17-95   3:45p	(DOS 7)
       59 file(s)        947,311 bytes

	Finally, in this particular installation we have been unable to
use IRQ 2 for our NE-2000 boot ROMs. Windows grabs it and won't let go.
This may change if we tell Win95 to use the "NW 4" shells, but I don't
know for sure at this time. Also NW queues aren't available unless we
do the "NW 4" shell installation program from Novell; they add files to
our f:\win95\user directory (system.ini in particular) and f:\win95\system.
	If this discussion is a little terse and vague in places it is
because we are groggy from the effort. Hands-on experience is the best
teacher here, so have at it. Please don't ask me all kinds of Win95
questions; that's Microsoft's job. 
	Joe Doupnik
	Utah State Univ
	jrd@cc.usu.edu
-----------------------
Subj:	Win95, floppy boot client, an addendum

	If you recall, last time I ended the Win95 floppy client installation
process with a problem of not being able to use IRQ 2 for the Ethernet board.
That's been solved, and below is the method and speculation on the reason.
	When doing the initial installation don't leave the network section
empty. This will create three lines: client, lan adapter, protocol. Configure
the lan adapter for IRQ 2, port whatever. Then delete the client and protocol
lines, leaving just a lan adapter talking to nothing. Complete the installation
and ignore the message that the network portion is only partly completed.
	After the boot floppy has been created, go back and remove that lan
adapter. Then create a new floppy with regular VLMs.
	What is happening is we are fooling Win95 into freeing up IRQ 2
for that lan adapter, even though we will yank it later on. That's my
guess. We could have used regedit to modify the registries (on floppy,
on server) but that is a very awkward method. So, Win95 does try to own
everything not welded to the floor.
{Note added later. One can also open the local machine icon under System
and reserve IRQ 2 for non-Windows uses. IRQ 2 equals IRQ 9 here.}
	We've done this for one lab now and it solves our IRQ 2 difficulty.
We needed that value for easy of use of Ethernet boot ROMS, and now we have
it. We finished the installation by using the DOS/Windows Update Kit to
install VLMs. Everything seems to work rather well (as well as a beta Win95
permits). Printing works to NW queues, etc. DOS users have ODI (and ODIPKT
+ WINPKT) running and QEMM gives us lots of memory at DOS level. Mind you, 
this is all just testing since we would not go into production mode with a 
beta Win95 even if it is build 950 R6 (i.e., what Aug 24 purchasers will 
receive).
-----
	A caution. I left off filename extensions in the config.sys
example of my long Win95 message the other day. Please insert the proper 
extensions. Sorry about the slip when typing mostly from memory.
	Joe D.

P.S. About that VLM install program. It won't find a conventional Win 3.x
directory and will complain. Not to worry. Tell it to use \win95\user as 
it's "Windows" directory and new material will go into \win95\user\SYSTEM
just as it should.
{Note added later. To work properly copy the contents of \win95\user\system
to \win95\system. Yes, that's Win95 territory.}
-----------------------------------------------

Addendum 2, remote booting final details

	The final part of successful booting concerns remote boot ROMs
in lan adapters. The environments considered here both have a local RAM
drive C: created in config.sys, but they differ by a workstation having
(or not) floppy drives installed. The file server is considered to be
read-only to clients.

	The boot roms in use in my labs happen to be the "old-Novell" 
for NE-2000 boards. They use only Ethernet_802.3 frames for booting
and have none of the more modern RPL*.* file support available. To
create an image of a boot floppy we use Novell's DOSGEN program applied
to a real boot floppy. On the file server the sys:login directory holds
net$dos.sys (the floppy image) and the same autoexec.bat file as in
the image. No rpl.nlm is usable with my boot roms. To construct the
image we create an autoexec.bat file as shown below, which includes
Novell's RPLODI.COM helper loaded before the board driver. After running
DOSGEN we run the result through Novell's RPLFIX.COM:
	DOSGEN A: NET$DOS.SYS
	RPLFIX NET$DOS.SYS
	COPY NET$DOS.SYS F:\LOGIN

	Different boot roms will require different steps. The matter is
discussed fully in Novell file RPLTK2.EXE located in directory 
netwire\novlib\01 on ftp.novell.com and official mirrors.

@echo off 
echo 
set NWLANGUAGE=ENGLISH
copy command.com c:\  
copy net.cfg c:\  
set comspec=c:\command.com
loadhi /r:1 lsl.com /c=c:\net.cfg  
rplodi.com
loadhi /r:1 ne2000.com
loadhi /r:1 ipxodi /d
netx.exe /ps=edu-usu-engrlab  
bootrom\loadhi /r:1 bootrom\odipkt30 0 99  
bootrom\loadhi /r:1 bootrom\winpkt 0x60 0x63 
REM Don't depend on f:\login as default network location
f:
login guest
REM The material below can be done in NW login scripts, but we are using
REM both Win95 and Win 3.1 at the moment and do not want to clobber the
REM production DOS + Win 3.1 environment.
map ins s2:=f:\win95
map ins s3:=f:\win95\command
map ins s4:=f:\win95\user
copy f:\win95\user\system.dat c:\
copy f:\win95\user\user.dat c:\
@echo on

	Now to the tricky parts.
	We prefer to use QEMM/386 for memory management, and VLMs for
the upper part of the NetWare shell. We have a read-only file server,
yet Win95 insists upon first copying SYSTEM.DAT and USER.DAT files to
*.DA0 backups and then updating the *.DAT files as the user resizes
screens etc.
	With an RPL boot we found that the boot process would load VLMs
and then halt with a DOS message saying Drive A: was unavailable, Abort/
Retry/Fail. This would occur only if a floppy drive (A or B) were available
to the machine. The drive light would come on and the message would be
presented. Answering A killed the boot process, R repeated the message,
F allowed the boot process to complete successfully. My interpretation is
the adjustments to UMB done by VLMs is sensed by Win95 (IO.SYS) and a
dummy access to Drive A: results even though nothing at all is read
from the floppy. Inserting any floppy at all will prevent the halt; loading
VLMs into conventional memory (/Mc on the vlm.exe line) will not. To
overcome this problem we took a step backward and used NETX from NETX33.EXE
(netwire\novfiles). No more Drive A: sensing and no fault.
	In addition, we found that Stealth Mode in QEMM interfered with
the remote boot process in some subtle way such that the process halted
when the NW shell is loaded (that is, when control transfers from the
fake Drive A: boot image to the real Drive F: via the network connection).
Turning off Stealth Mode (ST:letter) solved that problem. Using DOS'
memory management avoids the problem too (has no stealth mode).

	At this point a user can successfully remote boot a client and
run Win95. But Win95 will present complaint boxes about being unable
to write to system files on the file server. 
	Win95 keeps user details in two principle files: SYSTEM.DAT
and USER.DAT, for hardware and user-level items respectively. These
are found in the user's directory area, \win95\USER in the examples
above, and they are marked System, Hidden, ReadOnly. Every time a manager
updates Win95 those files are remarked SHR, and the manager should remove
those attributes. Microsoft provides program SETMDIR to point at those files,
such as
	setmdir /r:f:\win95\user
before win.com can be successfully executed.

{Note added later. Setmdir can be very useful indeed handling different
machines with minimal file server disk space per machine. As indicated
above and below, the SYSTEM.DAT and USER.DAT components of the registry
are read as Windows enters GUI mode, and one can point to local dynamic
throw-away copies for diskless clients or to a master copy when the system
manager installs new software. It is often possible to copy the master to
the user's area and then let Plug&Play work several times to insert the
user's machine info again. Alternatively, \win95\regedit at the DOS level
can convert registry to text file and back again, permitting us to edit
details with an ordinary editor. Merging new program material is thus
not such a big hassle if we simply insert a new piece of registry text.
	In other words, the registry lists drivers needing loading etc
per machine, and the pool of all drivers sits in the main \win95 subdirs.
This differs from Win 3.x where sundry video choices all clobber *.FON
files and we can't readily draw from a pool of drivers.}

	We copy SYSTEM.DAT and USER.DAT to Drive C: during the bootup 
process.
{Note added later. To text file MSDOS.SYS add line  HostBootDir=C:\ }
	 Since Drive C: is also the default drive (comspec is set there)
we do not need to run setmdir. To copy the files they must have the SHR 
attributes removed by the system manager. Those attributes need not be 
reapplied. When WIN.COM is run then those files are copied to *.DA0 backups
and work continues on the current *.DAT images. You can delete the backups, 
but they are created at later time than winstart.bat (optional Windows 
startup helper) is run. Since Drive C: RAM disk is local writable then
there are no complaints from Win95 when it modifies the local *.DAT files. 
The Windows temporary swap file resides there too.

	Extra hints: dynamic DOS environments.
	Pure DOS programs can be run within Win95, by either invoking
a DOS box or by creating an icon and clicking on it (much the same).
DOS programs requiring setups before running can be handled nicely by
using a DOS .BAT file to do the setup, then invoke the program, and
cleanup afterward. Create an icon ("shortcut" in Win95-speak) and
point it at the .BAT file. WordPerfect/DOS v6.0 wants to run in full
screen mode, and does so nicely if we provide that attribute in the
shortcut properties.
	Windows programs which require special setups (say Netscape plus 
Novell's LWP/DOS TCP/IP stack, or Autocad or Pspice) can use exactly the 
same .BAT trick. Create a .BAT file; tie it to an icon. In the .BAT file do
DOS work such as loading TCPIP.EXE from LWP/DOS, invoke the Windows program
executable, and cleanup afterward. Yes, that Windows program runs GUI style.
You can select to close the implicit DOS box as the GUI exits; check the
preferences item for that DOS box/icon.
{Note added later. Sigh, only some Windows programs will start this way.
Older ones with a less smart startup routine remain GUI-only. The only
way to tell is to try.}

	If you are installing WordPerfect 6.1 for Windows be aware that
one file OLE2CONV.DLL will create an error message saying the WP install
program can't write it to \win95\system. Ignore the message since a better
version exists already from the Win95 installation (and win95\system is
readonly).
	A little practice with creating "shortcuts" will produce an icon 
on the desktop for each application. Details are left as an exercise for 
the reader.

	Joe D.
------------
Note added April 1996.
	Many people have reported installation failure just before Win95
asks for a fresh floppy to be made and just after the drum roll sequence.
The error is a SU <numbers> message, file not found. The problem seems to
be Win95 can't find ANY vendor related file and quits. The cure is simple:
when the hardware selection process completes Win95 displays what it found
and asks for corrections. Make corrections to degrade all found components
to the simplest possible level such that no vendor specific items appear.
A video display adapter is the most common fault-generator so tell Win95
you have a simple 640x480 VGA board. After installation completes 
successfully you can reconfigure to the real hardware (that just updates
user.dat and system.dat registry files, so keep the old ones as a backstop).
	Once again, don't have a hint of a drive C: item during this
installation process. Remove disk controller boards or whatever it takes
to make your machine appear to have just floppy drives A: and maybe B:.
	Joe D.