From owner-freebsd-hackers  Sat Apr 26 16:25:27 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id QAA16287
          for hackers-outgoing; Sat, 26 Apr 1997 16:25:27 -0700 (PDT)
Received: from kalypso.cybercom.net (kalypso.cybercom.net [206.28.134.5])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16282
          for <hackers@freebsd.org>; Sat, 26 Apr 1997 16:25:24 -0700 (PDT)
Received: from atlanta (mfd-dial1-17.cybercom.net [206.28.134.49]) by kalypso.cybercom.net (8.8.5/8.8.5) with SMTP id TAA16403; Sat, 26 Apr 1997 19:24:03 -0400 (EDT)
Message-Id: <1.5.4.32.19970426232352.007060a4@cybercom.net>
X-Sender: ksmm@cybercom.net
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 26 Apr 1997 19:23:52 -0400
To: Terry Lambert <terry@lambert.org>
From: The Classiest Man Alive <ksmm@cybercom.net>
Subject: Re: VFAT 32 support in msdosfs
Cc: joa@kuebart.stuttgart.netsurf.de, hackers@freebsd.org
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

At 12:41 PM 4/26/97 -0700, Terry Lambert wrote:
>>>Note: From what I've heared, Windows95 that supports VFAT isn't even shipped
>>>any more. So this will probably be dying out soon.. :-)
>> 
>> Where'd you hear that?  Doesn't seem like Microsoft to just break the chain
>> of backward compatibility like that.
>
>These machines are capable of reading long-name-in-volume-label FAT
>drives ("VFAT").  But the partitions they use by default, and the
>partition table format, and the MBR and the io.sys/io.dos/msdos.dos
>where the INT 21 interface is instantiated *all* expect VFAT32.  I'm
>not sure that an OEMSR2 INT 21 is capable of identifying and booting
>from a "VFAT" drive at all.
>

Windows 95 OEM SR2 certainly can boot from a VFAT drive.  That's my point.
VFAT32 may be coming into widespread use, but I don't think it's time for us
(or Microsoft) to start dropping support for VFAT.

K.S.