Path: utzoo!attcan!uunet!bu.edu!snorkelwacker!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!tgp
From: tgp@sei.cmu.edu (Tod Pike)
Newsgroups: comp.windows.ms
Subject: Problems with Daybook + fix
Keywords: daybook
Message-ID: <7842@fy.sei.cmu.edu>
Date: 12 Jul 90 14:39:19 GMT
Distribution: na
Organization: Carnegie-Mellon University (Software Engineering Institute), Pgh, PA
Lines: 43


  I recently got my Windows 3.0 upgrade, and had a problem installing the
Daybook software that I'd like to pass along to the net, in case someone else
runs into it.

  The very verbose (sarcasm alert!) instructions that come with Daybook tell
you to get into windows 3.0 and run the setup program from the floppy.  When I
did this, the floppy could not be read.  Even outside of windows, trying to
access the floppy failed (with INT 24 failure).  Floppy 2 of the set was fine.

  Well, after going through the windows 800 number, being referred to the 
windows technical support non-800 number, and spending minutes working my way
through the automated support system, I got an answer:  It turns out that
quite a few people have run into this.  Apparently there is an interaction
with the DOS 4.0X "share" program which prevents the floppy from being read.
MicroSoft recommends the following actions:

	1) rename "share.exe" to "share.bak"
	2) edit your autoexec.bat to remove all "add"'s, "ren"'s and other
	 funny disk things.  (They specified exactly what things to remove,
	 but I didn't use any of the others, so I didn't write them down).
	3) reboot
	4) follow the install instructions
	5) put everything back the way they were before
	6) reboot and you're finished

  After I followed the instructions, I still got a disk error on the label
read, but after responding "fail" to the error from the DOS level, it read
the disk OK, and the windows install worked fine.  Note that the Daybook
install program modifies autoexec.bat, so you'll have to modify the save
copy by hand rather than just rename it back.

  Now, I'm curious....what did Asymetrix do to this disk to cause the problem?
Some kind of bizzare copy-protection scheme?  Anyone from MicroSoft (or
Asymetrix) out there got the official story?

			Tod Pike

-- 
Internet: tgp@sei.cmu.edu
Mail:     Carnegie Mellon University
	  Software Engineering Institute
	  Pittsburgh, PA. 15213-3980