Xref: utzoo comp.sys.ibm.pc:52494 comp.windows.ms:2789
Path: utzoo!attcan!uunet!microsoft!philba
From: philba@microsoft.UUCP (Phil BARRETT)
Newsgroups: comp.sys.ibm.pc,comp.windows.ms
Subject: Re: Problems with Windows/Disk Manager/1024+ cylinder hard drives
Keywords: Windows, Disk Manager, FDISK
Message-ID: <55226@microsoft.UUCP>
Date: 14 Jun 90 06:49:29 GMT
References: <18406@well.sf.ca.us>
Reply-To: philba@microsoft.UUCP (Phil BARRETT)
Distribution: comp
Organization: Microsoft Corp., Redmond WA
Lines: 172

please forgive the cross posting -- the original article contained
enough half-truths and exagerations that I felt it warranted it.

|
|             IS WINDOWS 3.0 A THREAT TO YOUR COMPUTER SYSTEM?

No.

|   In July 1989, Microsoft released a limited-circulation memo which
|stated, in part:
	<details omitted for brevity>
please note this memo was released 10 months prior to win 3.0 intro.

|
|A. INCOMPATIBILITY WITH DISK MANAGER AND OTHER DISK FORMATTERS
|
|   PROBLEM: The first type of difficulty occurs with 80386-based systems
|using: (1) a "permanent swap file" under Windows 3.0 in 386 enhanced
|mode; and (2) using a non-Microsoft disk formatter such as Disk Manager,
|SpeedStor or Vfeature.  Many users have noted the inability to load and
|run certain programs, and non-destructive system lockups.  With the
|exception of very large hard disks, as noted below, no problems occur as
|long as Windows is not running in 386 enhanced mode, or a permanent swap
|file is not in use.
|
|   WORKAROUND: Microsoft has published a workaround on CompuServe to
|address this problem.  Briefly, two things must be done to avoid prob-
|lems while using third-party disk formatters: (1) switch the permanent
|swap file to a temporary swap file (see the Windows 3.0 manual, pp. 525-
|529); and (2) add the line:  virtualhdirq=off  to the SYSTEM.INI file in
|the [386ENH] section.  Note: The temporary swap file is much slower than
|the permanent one, because the latter creates a block of contiguous disk
|space which is written to directly by Windows.
|

This confuses two seperate issues:
	- use of swapfile on non-MS partitioning schemes and 
	- use of ROM BIOS extensions that support > 1023 cylinder disks

The swapfile utility will refuse to create a swapfile on disks with
known incompatible partitioning schemes and non-512 byte sector sizes
so you cant get yourself into this situation unless you deliberately
end-run the check swapfile makes (no, I wont tell you how).  The performance
benefits of a permanent swapfile are not as dramatic as the original article
claims (and either is the loss).

Secondly, there is indeed a problem with software ROM BIOS extensions to 
support >1023 cylinders.  MS product support is aware of this and is giving
out the above workaround ([386enh] virtualhdirq=off in system.ini).
This bug not damage disks because the first disk operation windows does
will hang.  That happens to be a read.   Also, the various manufacturers
of the software ROM BIOS extensions are working on updates to work more 
cleanly with win3.


|
|B. DESTRUCTION OF HARD DISK SYSTEMS WITH MORE THAN 1,024 CYLINDERS
|
|   PROBLEM:  Windows (all versions), like DOS, only recognizes the first
|1,024 cylinders of a hard disk.  But unlike most software, it can write
|directly to disk through BIOS.  This is a major risk for larger hard
|drives, which may be using SWBIOS or similar software-based extenders to
|address cylinders beyond the 1,024th.  A mismatch between the DOS-level
|situation provided by SWBIOS and the BIOS-level situation encountered in
|a direct disk write can be fatal.  One Windows 3.0 beta tester in Port-
|land, Oregon recently had a Conner 150 MB drive trashed by Windows 3.0.
|Many other incidents of similar disasters with large hard disks have
|been reported.
|
|   WORKAROUND:  At present, there is no reliable workaround.

First off, windows (except for a permanent swapfile) does not write to the
disk via the BIOS but rather relies on DOS.   This coupled with the swapfile
utility refusing to create a permanent swapfile on a disk with non-MS 
partitioning schemes is important to understand.

We have been investigating these reports and have found a dearth of people
that have actually had a trashed disk.  The one case that we found turned out
to due to the user having loaded a very old version of dmdrvr (instead of the
version that came with his HD) and when he filled up his partition past 1023
cylinders, kaboom.  He would have had this problem were he just using the
copy command in DOS.  I and Microsoft are intensely interested in hearing
from anyone that has had a problem that sounds like the one described.

Please contact me directly if you or anyone you know have experienced any
problem like this.  My email address follows at the end of the article.

|
|************************************************************************
|If you are unsure about the safety of your system: STOP USING WINDOWS
|IMMEDIATELY IF YOU HAVE A DRIVE WITH MORE THAN 1,024 CYLINDERS!!
|************************************************************************
|   

This is totally irresponsible.  Windows 3.0 works well with non-MS 
partitioning schemes.  The one bug noted above has a very simple workaround
and we have yet to see any cases of hard disk corruption.

|
|DISCUSSION
|
|   Microsoft believes it cannot respond to the growing number of "non-
|standard" disk systems available to Windows users. 

This person has no concept of what MS believes.  We are vitally interested
in meeting the needs of our customers -- to ignore such an important 
component of the marked would be folly. 

|
|   Jeff Wickman of Microsoft stated the company's response on Compu-
|Serve: "Windows has always been developed around standard format-
|ting(<=1024 cylinders) and F-Disk partitioning.  For a larger than 32
|meg partition you can use DOS 4.01 and F-Disk."

Jeff Wickman is not a spokesman for Microsoft and the above statement,
if correctly quoted, is false.  You *can* use the various partitioning
schemes and their associated ROM BIOS extensions.  You will need to use
the above mentioned workaround, however.  Our product support personel
have been educated on the specific issue and hopefully no more errors
of this nature will reoccur.

|
|   Microsoft's Jeff Wickman said, "We knew certain partitioning methods
|caused problems for Windows and we knew everyone had DOS and so they
|also had F-Disk, so we use this as a development standard."  Thus,
|Microsoft's stance on this issue boils down to just another example of
|the "not invented here" syndrome.  But much worse, Microsoft has failed
|to focus on the limitations and dangers of Windows in its general pub-
|licity and documentation.
|

This is not Microsoft's stance on the issue.  We did not develop Windows
strictly around the DOS 4 partitioning scheme.  Support for several third party
partition schemes *was* a consideration.  and, it *does* work.  Our stance
is that any problem that causes hard disk corruption is a very serious one
that we will place at the highest priority. 


<I have omitted a long diatribe aimed at Microsoft filled with numerous
factual errors and ignorant misrepresentations>

|
|FURTHER INFORMATION
|
|   The two main sources of information for this message have been the
|Microsoft Windows forum on CompuServe and the Ontrack Systems BBS
|(612/937-0860).  Ontrack is now intensively testing Disk Manager and
|Windows 3.0 and promises daily bulletins on their findings.
|

Its interesting to note that the daily bulletins have not been forwarded 
on from compuserve.  They would tell a different story than the original
message would have you believe.


|
|7 June 1990
|
|Fred Heutte
|Sunlight Data Systems
|PO Box 40260
|Portland, Oregon  97240
|503/241-0858
|
|CompuServe: 72461,2224
|Usenet: phred@well.sf.ca.us
|
|

Phil Barrett
Microsoft
uunet!microsoft!philba