Tom's Guide | Tom's Hardware | Tom's Games
![]() |
![]() |
![]() |
Is there a way that I can get PC DOS to read and write and possibly FDISK FAT 32 disks?
I need to install it to a Thinkpad 560 I just bought, and it has a 4gb hdd. I kinda thought it would be neato to have it running FAT 32, considering we are dealing with many many small files (voice training for automated systems).
I know MS-DOS 7.1 has capability to read these, and also LFN's which I would be interested in as well.
However, I am quite partial to the IBM PC DOS 2000 product. I kinda think it's neat to have a genuine IBM running genuine IBM software...
PC-DOS 2000 also includes much better applications than MS-DOS did (I don't know what is in 7.1 though), like IBM Antivirus 2.5, Central Point Backup, Stacker 4.0, etc.
So is there a file that I simply need to install into PC-DOS that will upgrade it to 7.1 functionality.

All versions of PC-DOS are native FAT16 with 8.3 'Short File Names'
I have heard that DRFAT32 - A Fat32 & LFN Driver by Caldera which is a undocumented utility for DR-DOS 7.03 may work with MS-DOS 6x (No point when you have 7.10) and PC-DOS 7.0 (2000 is in fact only PC-DOS 7.0 Rev 1 anyway)
DRFAT32.EXE is available from:
http://sta.c64.org/lfnemu.htmlI have not yet tested it myself however!

PC-DOS 2000 will NEVER support FAT32 natively. And there is no very suitable FAT32 driver for DOS by now (And yes, there is a driver called DRFAT32, however, which is very unstable and unusable, and has a bunch of bugs and limitations after I tested it for a couple of times).
So, to support FAT16X/FAT32/FAT32X/LBA drivers natively and stably under DOS, MS-DOS 7.10, ROM-DOS 7.10 or similar is required.

Mick C,
"I have heard that DRFAT32 - A Fat32 & LFN Driver by Caldera
In fact, DRFAT32 does NOT support LFN! And you can't access any long file names on the FAT32 drives mounted by DRFAT32 even if another LFN driver for DOS is loaded earlier or later.

PCDOS 7.1 revision 0 which underpins Norton Ghost 2003 does support FAT32 but not LFN, but there are utilities available to read LFN's......................

>> PCDOS 7.1 revision 0 which underpins Norton Ghost 2003 does support FAT32 but not LFN
Quotation from Mick C's eariler post:
"PCDOS version 7.1 revision 0 (FAT32 support), as used by Symantec Norton Ghost was never intended as a standalone OS so it comes as no surprise to me that it has problems with WfWG 3.11! It was written purely as a Bootdisk to access FAT32 Drives to run Norton Ghost. I am sure IBM could amend it to work correctly if they really wanted to!"
Also, don't use the disk utils included in PC-DOS 7 or MS-DOS 6 or earlier, because they could destroy LFNs and will probably not work with large drives.

Note that there is a *major* bug in PC-DOS 7.10 kernel: It only supports ExtendedX partition(LBA), but NOT the standard Extended partition(CHS)!
Some results on my harddrives under different DOSes are:
Hard Drive 1:
Total size: 6.4GBC: (1GB, FAT16 Pri)
D: (4.4GB, FAT32)
E: (1GB, FAT16).Note: Drive D: and E: are in Extended partition(CHS).
MS-DOS 6.22 can see 2GB (C: and E:)
MS-DOS 7.10 can see the whole 6.4GB (C:, D: and E:)
PC-DOS 2000 can see 2GB (C: and E:)
PC-DOS 7.10 can only see 1GB (C: *only*)Hard Drive 2:
Total size: 30GBC: (2GB, FAT16 Pri)
D: (24GB, FAT32)
E: (2GB, FAT16)
F: (2GB, FAT16)Note: Drive D:, E: and F: are in ExtendedX partition(LBA). For compatibility with DOS6, I had to make Drive C: FAT16.
MS-DOS 6.22 can only see 2GB (C: *only*)
MS-DOS 7.00 can see 6GB (C:, E: and F:)
MS-DOS 7.10 can see the whole 30GB (C:, D:, E: and F:)
PC-DOS 2000 can see 2GB (C: only)
PC-DOS 7.10 can see the whole 30GB now, but with some problems with Drive D:.Hard Drive 3:
Total size: 800MBC: (500MB, FAT16 Pri)
D: (300MB, FAT16)MS-DOS 6.22 can only see 500MB (C: *only*)
MS-DOS 7.10 can see the whole 800MB (C: and D:)
PC-DOS 2000 can only see 500MB (C: only)
PC-DOS 7.10 can see the whole 800MB (C: and D:)

Wengier As I wrote I have heard DRFAT32 But not tested it myself! The description FAT32 & LFN Driver was given by Caldera not me... Now I have read your comments I will not bother to try it...As I say with MS-DOS 7.10 Why Bother
DRFAT32 is 2 files DRFAT32.SYS for Config.Sys and DRFAT32.exe for Autoexec.Bat You would still have to use the MS-DOS 7.10 FDISK to prepare for a Harddrive larger than 2GigaBytes anyway!
PC-DOS 7.10 is one of the custom DOS versions I would never recommend to anyone. Other versions to avoid are DR-DOS 7.04 & 7.05 (Used by OnTrack) OK for intended purposes but dangerous as Stand Alone OS.
It would seem that DRFAT32 needs to be added to the list!

Mick C,
I think you misunderstood my point.
"The description FAT32 & LFN Driver was given by Caldera not me.."
I did NOT say you made this mistake, but just stated the fact. It's propably Joe Forster (the maintainer of that page) but not Caldera who made this mistake! The desciption of DRFAT32 by Caldera Inc. is: "INT 13h Interface for FAT32 Redirector", not a LFN driver.
"As I say with MS-DOS 7.10
Why did you say with MS-DOS 7.10 here? I didn't even mention MS-DOS 7.10 in my posts above except for the truth "to support FAT16X/FAT32/FAT32X/LBA drivers natively and stably under DOS, MS-DOS 7.10, ROM-DOS 7.10 or similar(FreeDOS Kernel 2029+, for example) is required." In other words, DRFAT32 can't add native and stable FAT32 support to DOS. Even in my testing result(Response #6), I was mainly focusing on the results of PC-DOS 2000/7.10, but not MS-DOS 6.22/7.10!
To tell the truth, I love GNU GPLed FreeDOS the best of all the existing diffenent types of DOSes. But why I recommended MS-DOS 7.10 recently? (Note that I never mentioned "the standalone and complete version of MS-DOS 7.10" in my posts above of THIS THREAD since he is talking about PC-DOS, NOT MS-DOS!) One of the main reasons to this question is: I don't like to hear anyone who says "DOS can't support FAT32, large disks, or LFN" simply because it's NOT true! If they actually tested/tried MS-DOS 7.10, they could know that all of these CAN be done BY DOS (not only M$'s)! I'm glad to see that FreeDOS developpers are currently working hard on them, however, the fact is that PC-DOS 2000 can NEVER support FAT32/LFN natively while DRFAT32 is very buggy, unstable and unuseable. I have hoped IBM could release a complete and bugfixed version of PC-DOS 7.1 with native FAT32 & LFN support ever since I tested its boot disk for the very first time. However, they didn't do so for some unknown reasons.
The point is: after testing/trying MS-DOS 7.10, people can know that M$-DOS 7.1 (or in general, "DOS") can do all of these, but then would ask: why can't other DOSes do the same things? If they can (which is my real hope), then WHY BOTHER M$-DOS?? Best wishes to the upcoming FreeDOS 1.0!
LONG LIVE DOS!!

You misunderstand what I say here.
Since MS-DOS 7.10 has FAT32 AND LFN Native support - Why Bother trying to get other versions of DOS (i.e. DR-DOS or PC-DOS) to work with drivers or fixes? (Other than perhaps manufactures updated versions)
I posted about DRFAT32 as a remote possibility to add FAT32 support to PC-DOS 2000 (In reply to the original query)Also to see if readers had tried it. You made your remarks which I accepted.
'With MS-DOS 7.10 (already having this support) 'Why Bother' even try to fix PC-DOS 2000 is what I am saying.
As far as I am concerned, There is only one MS-DOS 7.10 - It makes no difference to me if it is provided with MS Windows 98 or your Installable Disk Set. It is one and the same version!

Mick C,
"Since MS-DOS 7.10 has FAT32 AND LFN Native support - Why Bother trying to get other versions of DOS (i.e. DR-DOS or PC-DOS) to work with drivers or fixes?
Oh, sorry, I was replying your post in a hurry without reading it carefully.
Yes, you are absolutely right, since MS-DOS 7.10 has native FAT32 & LFN support, why bother trying to get other DOSes?
However, if and ONLY IF any DOS (especilly FreeDOS) other than MS-DOS 7.10 has all the features and compatiblity that MS-DOS 7.10 has now, then as I said above, I may have to give M$-DOS up because of the possible copyright problem.
"As far as I am concerned, There is only one MS-DOS 7.10 - It makes no difference to me if it is provided with MS Windows 98 or your Installable Disk Set."
Yes, I have TRIED MY BEST to use all the original DOS files provided with Win98 to make the Installable Set. In fact, I could use/add other files & tools like in the several super DOS boot disks I made, but I didn't do that to "MS-DOS 7.10 Full Version" since I want to make it look "formal" (by this I need to say that the *recent goal* is just making it standalone, installable and well-configured). So only a few files are changed, for example, many extra codes and the embeded WinLOGO in IO.SYS are removed. That's why they look so same so far. However, this may or may not change in the future, totally depending on the feedbacks and requirements of the users. I will add more information about this on the MS-DOS 7.10 download page soon:

And besides just making it standalone, installable and well-configured, we are trying to make it easy-to-use and friendly (not only the installer), too. Now only a few files are changed and a few other files/utils are added into the installation disks/CD though, the different Add-an Disks which are already available for the DOS Installer contain a large number of different tools/programs which can be installed automatically during the DOS installation process.
P.S.: Win9x has its own startup logo, and why can't DOS have its own startup logo as well? So we decided to make it. You can see the new DOS startup logo here(which has been added into this standalone MS-DOS 7.10):

"why bother with PC DOS 2000"?
1. PC DOS has much better tools included than MS-DOS
2. PC DOS is not marked with the word Microsoft anywhere. (old versions had a M$ and IBM copyright, 2000 has only a IBM copyright)
3. I grew up with IBM's DOS product, and prefer it
4. I have a lot of time on my hands
5. I think it cool to dual boot Windows 2000 and IBM PC DOS 2000 on an IBM computer, made around the late-90's
6. there is no number 6
7. IBM sounds better than Microsoft

900t,
"3. I grew up with IBM's DOS product, and prefer it"
As I have said already, I hope that IBM could release a version of PC-DOS with native and stable FAT32 & LFN support too, however they never did for some unknown reasons. So don't dream about IBM any more.
"2. PC DOS is not marked with the word Microsoft anywhere. (old versions had a M$ and IBM copyright, 2000 has only a IBM copyright)
4. I have a lot of time on my hands
6. there is no number 6
7. IBM sounds better than Microsoft"These actually mean the same thing. If you just want to see the word "IBM" instead of "M$" in DOS, then why not modify the string yourself since "you have a lot of time on your hands"?

Up to MS-DOS & PC-DOS version 5.xx Microsoft and IBM jointly developed DOS and there are many similarities between them and later versions.
Then IBM parted company and developed PC-DOS on its own. All the 'Better Tools' in PC-DOS are in fact developed by different companies for IBM. Very little was done 'In House'
IBM Anti virus was by Symantec(I think)
Central Point provided Backup
Stacker provided Disk Compression
PCMCIA support by Phoenix TechnologiesMost of these add-ons work with MS-DOS anyway!
You can read IBM's comparison between PC-DOS & MS-DOS here:
http://www-3.ibm.com/software/os/dos/psm952a.html
It is with the lack of FAT32 and Large Disk Support that IBM's PC-DOS now falls behind Microsoft's MS-DOS
I am not a great lover of Mi¢ro$ofts marketing strategies but use thier products as a necessary evil! What name is presented to me when I switch on does not bother me at all.
I answered your main query in Post 2 to the best of my knowledge, and later posts pointed out it is next to impossible to up-date PC-DOS to handle FAT32 Drives.
I for one will now close this thread as I feel it has run its course.

"Most of these add-ons work with MS-DOS anyway!"
Yes! By replacing some necessary files from PC-DOS 2000, I have successfully added native Euro Symbol support to MS-DOS 7.10. Also, the PCMCIA support and more these add-ons work great with MS-DOS 7.10 as well!

back to the original post
"However, I am quite partial to the IBM PC DOS 2000 product. I kinda think it's neat to have a genuine IBM running genuine IBM software..."-900T
maybe you should consider running IBM os/2 warp 2,3 or 4 It will run DOS and Windows 3.11 programs (i think win3.1 has to be manually installed in warp3) and you have HPFS and FAT16 support and there is also a fat32 driver that can be installed. ;-)
Wengier I like the new dos startup logo

The best place to lookout for it now is ebay
I dont think you can get it new anymore but there are still a few newish updates for it (like servicepacks)

Clarification about PC DOS versions:
PC DOS 7.0 was done in-house by IBM in 1994 and contains many optimizations, memory saving features, code cleanup, and a couple of new utilities like DYNALOAD.
PC DOS 2000 (a.k.a. PC DOS 7.0 revision 1) was done in 1998 and only adds Euro symbol support and year 2000 support for older BIOSes which didn't increment the CMOS century byte from 19 to 20.
PC DOS 7.1 is a kernel-only release (IBMBIO.COM, IBMDOS.COM, COMMAND.COM) which was done for Symantec for Norton Ghost and supports FAT32 though the support has some bugs.
By the way LFN support is NOT native in Windows 9x real-mode MS-DOS 7.x or 8.0, this support is only present when the Windows protected-mode kernel is loaded.

dosguru,
"By the way LFN support is NOT native in Windows 9x real-mode MS-DOS 7.x or 8.0, this support is only present when the Windows protected-mode kernel is loaded."
I have to say this is not really correct, only partically true for some MS-DOS 7.x. Don't you know that almost all external commands of MS-DOS 7.x have been revised to support LFN? Have you ever tried MS-DOS 7.10 Full Installation Set or looked at the following screenshots:

Yeah I know exactly what I'm talking about. The Int 21h API which supports LFNs is only available in the protected-more Windows kernel so those functions do nothing under the base real-mode DOS.

"The Int 21h API which supports LFNs is only available in the protected-more Windows kernel"
So, this is no longer true. A well working LFN API provider (similar to the HMA/XMS provider HIMEM.SYS or the UMB/EMS provider EMM386.EXE) for DOS has been included in MS-DOS 7.10 Full Installation Set, so these LFN functions will work natively and perfectly under pure MS-DOS 7.10 from now on.

Well that's an external program and not part of the real-mode DOS kernel. The real-mode Win9x DOS kernel does NOT have LFN support, only FAT32 support.

If you say in that way, then DOS kernel doesn't natively support HMA/XMS/EMS/UMB memory either, because a external program (e.g. EMM386.EXE) is required to provide such memory. Anyway, with these drivers/API providers, MS-DOS 7.x can support them natively and stably since it knows how to handle them once these API are present.

You really don't know what you're talking about. DOS versions since DOS 5.0 have support for XMS functionality (DOS=HIGH and DOS=UMB). The kernel makes the XMS calls to attempt to allocate the HMA and UMBs which are part of the XMS definition. HIMEM.SYS or a similar XMM provides the actual extended memory support. EMS is an older specification which was created to alleviate the 640K memory barrier and can be used on very old system (i.e. 8086s) with an expanded memory board like the old Intel Above Board. A virtual-86 mode EMM like EMM386.exe provides EMS support on modern systems
LFN support is via a TSR which has the necessary Int 21h API functions or via the protected-mode Windows kernel which intercepts the Int 21h API functions and handles them.

I know what you mean, but that is NOT the point!! As you said above, "HIMEM.SYS or a similar XMM provides the actual extended memory support.". So, NO HIMEM.SYS, THEN NO XMS, even if DOS knows how to handle XMS(i.e. The kernel makes the XMS calls to attempt to allocate the HMA and UMBs which are part of the XMS definition. But if XMS is not provided by HIMEM.SYS yet, then the XMS calls from the kernel will NOT function at all)! HIMEM.SYS is actually an external driver (although it was included in DOS5+), as well as a LFN API provider for DOS.
Don't argue any more, as I feel this thread has run its course as well as Mick C.

P.S. Undoubtedly, XMS/UMB provider and LFN API provider are not same. But since they are kind of similar, I made that example just to illustrate my point more easiler. So please don't misunderstand that. If you have tried ROM-DOS 7.10 (whose kernel includes LFN API already), you will know more about this.

![]() |
![]() |
![]() |

This post is quite old and has been locked from receiving new replies. Please create a new posting instead.
| Ads by Google |