Sign in to follow this  
Followers 0
ppgrainbow

Testing MS-DOS limitations

26 posts in this topic

Here's what I found about MS-DOS and here are the fact that I've learned so far. Some of the information regarding FDISK hard disk limitations is not documented elsewhere.

Memory limitations

MS-DOS 4 and 5 include the HIMEM.SYS XMS 2.x driver which will not allow the OS itself to address more than 16 MB of system memory. This is the case when those operating systems came out. If the HIMEM.SYS XMS 3.x is used from MS-DOS 6 through MS-DOS 6.22, then the system memory ceiling would be raised from 16 MB to 64 MB.

MS-DOS 6 through 6.22 include the HIMEM.SYS XMS 3.x driver which raises the system memory ceiling from 16 MB to 64 MB. 64 MB or 65,536 KB is very common, because MS-DOS 6.x used a unsigned 16-bit value to store the physical amount of memory in kilobytes. If more than 64 MB of system memory is reported to MS-DOs 6.x, then only 64 MB will be usable.

The system memory limit ceiling was raised to 4 GB in MS-DOS 7, MS-DOs 7.1 and MS-DOS 8. However, up to around 3.6 GB of system memory will be usuable to the OS.

Hard disk size limitations in MS-DOS 2.x to MS-DOS 6.22

FDISK from MS-DOS 2.x only had FAT12 support with support for single hard disks up to 16 MB at 4,096 bytes per cluster. In MS-DOS 3.0 to MS-DOS 3.2, the limit was raised to 32 MB when FAT16 support was introduced.

FDISK from MS-DOS 3.3 allowed partition sizes of up to 32 MB (or 65,535 sectors at 512 bytes per sector) and recognises hard disks of up to 504 MB (1,024 cylinders, 16 heads and 64 sectors per track). For this instance, drive C as the primary partition and drives D through R would need to be created - 15 32 MB partitions and a 24 MB logical partition on drive R.

However, in November 1987 Compaq shipped Compaq MS-DOs 3.31 with support for hard disks up to 504 MB. Partitions over 32 MB used the partition type (0x06) which later became present in MS-DOs 4.0 and later.

FDISK from MS-DOS 4 and MS-DOS 4.01 is limited to a partition size of up to 4,095 MB per hard disk split to a 2,047 MB primary partition (drive C) and a 2,039 MB logical partition (drive D).

MS-DOS 4.0x had a serious bug where as if the size of the hard disk is greater than 4,095 MB, the OS would refuse to boot...even from a floppy disk. This bug was due to Microsoft programmers using 32-bit unsigned numbers to store hard disk drive capacity detection in FDISK which would cause the value (in megabytes) to wrap back to zero, meaning that a hard disk larger than 4 GB in capacity will be reported significantly less. IBM's PC-DOS 4.0 only supported partitions of up to 1,024 MB with up to four partitions.

The 4,095 MB bug was fixed in MS-DOS 5.0 and later where as the capacity limit was raised to 1,024 cylinders, 255 heads and 63 sectors per track for a total of 16,450,560 sectors. At 512 bytes per sector, this totals 8,422,686,720 bytes or more commonly - 8,032.5 MB (7.84 GB).

The hard disk with the maximum capacity of 7.8 GB must be split into four partitions, the 2,047 MB primary partition on drive C would first be created and a Extended DOS partition of 5,977 MB, consisting of two 2,047 MB logical partitions on drive D and E and one 1,883 MB partition on drive F.

If a hard disk has a capacity of 8,032 MB or more, then only 8,032 MB will be usable under MS-DOS 5 and 6.

Also, when it says "Do you wish to use the maximum available size for a Primary DOS partition?", if you try to select the whole hard disk if the size of the drive is more than 2,047 MB then only the first 2,047 MB will be used and the remaining 5,977 MB will be reserved for a Extended DOS partition.

Hard disk size limitations in MS-DOS 7, MS-DOS 7.1 and MS-DOS 8

In MS-DOS 7 (Windows 95 and 95A) FDISK, the 7.8 GB partition size limit was removed, however only FAT16 partition sizes of up to 2 GB could be created. MS-DOS 7 FDISK also cannot correctly display the size of large drives as the value is limited to 9,999 MB. If the size of the drive is over 10,000 MB, the last digit will be dropped. For example, a Quantum 12 GB with a partition size of 11,497 MB would be displayed as "1149".

Let me warn you that in MS-DOS 7 FDISK, there is a rather annoying bug where if you try to partition FDISK on a hard disk larger than 32,767 MB, FDISK will NOT report the correct size of the drive as the total disk space will end up showing negative numbers! MS-DOS 7 FDISK used signed 16-bit values internally to calculate the size of the drive in megabytes. And some of these variables will overflow when the size of the drive itself is equal to or larger than 32 GB.

For example, if the size of the physical drive is 48 GB in size, FDISK will use the first 2,047 MB for the primary partition and 47,104 MB for the Extended DOS Partition. However, FDISK will end up reporting the drive as being a -18,431 MB drive when a Extended DOS partition is created! A series of logical drives, drives D all the way to drive Z would need to be created and formatted. However, after partitioning logical drive R, FDISK under MS-DOS 7.0 will stop responding (hang) when attempting to partition logical drive S!

The solution when using MS-DOS 7 FDISK is use a hard disk smaller than 32 GB in size and create 2 GB partitions or use MS-DOS 7.1 which added FAT32 support and support for hard disks up to 2 TB.

In MS-DOS 7.1 when used with Windows 95 OSR2.x or Windows 98, there is a bug where FDISK will not recognise the full size of the hard disk larger than 64 GB: http://support.microsoft.com/kb/263044

The fix that I pointed out only applies to MS-DOS 7.1 when used with Windows 98 and Windows 98 Second Edition, because MS-DOS 7.1's FDISK uses unsigned 16-bit values internally to calculate the size of the drive in megabytes. However, even if the fix is applied, MS-DOS 7.1 when used with Windows 98 and MS-DOS 8.0 cannot correctly display the size of large drives as the value is limited to 99,999 MB. If the size of the drive is over 100,000 MB, the last digit will be dropped.

Also, FDISK when used with MS-DOS 7.1 will be unable to properly create a hard disk larger than 512 GB. For example when you attempt to set up a 640 GB hard disk with MS-DOS 7.1, you will not be able to use a partition of 610,352 MB, instead it will only end up as a partition size of 86,063 MB.

Such a issue will occur, because MS-DOS 7.1 FDISK uses signed 20-bit values to calculate partition creation sizes which limits the size of the partition to 512 GB. To work around this solution, you will either have to use the MS-DOS 8.0 FDISK (from the Windows Millennium boot disk), use the FreeDOS FDISK or use a third-party partition to create a FAT32 formatted hard disk of up to 2 TB.

Lastly, in FreeDOS, the size of the drive is limited to a six-digit value of 999,999 MB. If FreeDOS is used to partition a 1.5 TB or 2 TB hard drive then the last digit will be dropped.


Testing MS-DOS limitations

Okay, I create three 8,036 MB hard disk images for use in MS-DOS 6.22 under VMware Player. I allocated 64 MB of system memory and 4 MB of video RAM. Since the CD-ROM is present on the secondary master channel, MS-DOS FDISK will report three IDE hard drives as 8,025 MB each. The drives are partitioned as the following:

DISK 1

C: 2,047 MB (primary)
F: 2,047 MB (logical)
G: 2,047 MB (logical)
H: 1,833 MB (logical)

DISK 2

D: 2,047 MB (primary)
I: 2,047 MB (logical)
J: 2,047 MB (logical)
K: 1,833 MB (logical)

DISK 3

E: 2,047 MB (primary)
L: 2,047 MB (logical)
M: 2,047 MB (logical)
N: 1,833 MB (logical)

In short, when running MS-DOS under VMware, QEMU, Bochs, VirtualBox or Virtual PC:
1. If a CD-ROM is present, MS-DOS will use up to three IDE hard disks with a total of up to 24,075 MB of total disk space.
2. When a CD-ROM not present, MS-DOS will use up to four IDE hard disks with a total of up to 32,100 MB of total disk space.
3. If MS-DOS is set up on a SCSI virtual disk, MS-DOS will use up to 8 SCSI hard drives or up to 6 SCSI hard drives with a capacity of 8,032 MB each with the highest possible total of 48,192 MB of disk space (or up to 46,304 MB of disk space with a virtual CD-ROM). The absolute highest limitation maybe less if removable media is present.

Has anyone experienced testing hard disk and memory limits before in MS-DOS? If so, please share your experience. smile.gif

Update: I tested running MS-DOS 6.22 with 80 MB of system memory allocated to the VM and with the following example output:

C:\>memMemory Type Total = Used + Free---------------- ------- ------- -------Conventional 640K 24K 616KUpper 115K 96K 19KReserved 0K 0K 0KExtended (XMS) 65,985K 450K 65,535K---------------- ------- ------- -------Total memory 66,739K 569K 66,170KTotal under 1 MB 755K 120K 635KLargest executable program size 616K (630,288 bytes)Largest free upper memory block 9K (9,696 bytes)MS-DOS is resident in the high memory area.C:\>

As described above, MS-DOS will report the total amount of memory up to a little more than 1 MB over 65,535 KB leaving the maximum amount of XMS that MS-DOS can use to no more than 65,535 KB and with 640 KB of base memory and up to 128 KB of upper memory, that works out to a absolute maximum of 66,303 KB of total memory available to DOS! :w00t:

Edited by ppgrainbow
Removed the [size=1] tags, which are only useful to render text not meant to be read...
0

Share this post


Link to post
Share on other sites

Is it me or you used an unreadable (tiny) font size?

Can you set ti to "normal"?

jaclaz

0

Share this post


Link to post
Share on other sites

Has anyone experienced testing hard disk and memory limits before in MS-DOS? If so, please share your experience. :)

I have a dual-boot DOS 6.2/Windows 98 system with an 8GB and 64GB Hard Drives. I developed a DDO that runs with DOS 6.2 that makes the 64GB Hard Drive appear as 8 8GB Hard Drives.

With careful partitioning of the 64GB Hard Drive, including creating dummy partitions, I was able to share 12 2GB Partitions between both OSes. I could have shared 24 but I needed some larger FAT32 Partitions for data.

With Patches, DOS 7.1 can handle 8MB Clusters (256 Sectors of 32KB each), and can handle up to 3PB Hard Drives with a DDO, 48TB without.

0

Share this post


Link to post
Share on other sites

Has anyone experienced testing hard disk and memory limits before in MS-DOS? If so, please share your experience. :)

I have a dual-boot DOS 6.2/Windows 98 system with an 8GB and 64GB Hard Drives. I developed a DDO that runs with DOS 6.2 that makes the 64GB Hard Drive appear as 8 8GB Hard Drives.

With careful partitioning of the 64GB Hard Drive, including creating dummy partitions, I was able to share 12 2GB Partitions between both OSes. I could have shared 24 but I needed some larger FAT32 Partitions for data.

With Patches, DOS 7.1 can handle 8MB Clusters (256 Sectors of 32KB each), and can handle up to 3PB Hard Drives with a DDO, 48TB without.

Wow! That's pretty interesting. I kinda find it really weird to see MS-DOS 6.2 fully recongise the 64 GB hard disk as 8 8 GB hard drives with a Dynamic Drive Overlay that you developed, even if MS-DOS 6.22 and below will not support hard disks over 7.8 GB.

Edited by ppgrainbow
0

Share this post


Link to post
Share on other sites

Has anyone experienced testing hard disk and memory limits before in MS-DOS? If so, please share your experience. :)

I have a dual-boot DOS 6.2/Windows 98 system with an 8GB and 64GB Hard Drives. I developed a DDO that runs with DOS 6.2 that makes the 64GB Hard Drive appear as 8 8GB Hard Drives.

With careful partitioning of the 64GB Hard Drive, including creating dummy partitions, I was able to share 12 2GB Partitions between both OSes. I could have shared 24 but I needed some larger FAT32 Partitions for data.

With Patches, DOS 7.1 can handle 8MB Clusters (256 Sectors of 32KB each), and can handle up to 3PB Hard Drives with a DDO, 48TB without.

Wow! That's pretty interesting. I kinda find it really weird to see MS-DOS 6.2 fully recongise the 64 GB hard disk as 8 8 GB hard drives with a Dynamic Drive Overlay that you developed, even if MS-DOS 6.22 and below will not support hard disks over 7.8 GB.

The limit for a single Drive Letter in CHS is 1024x255x63x512 Bytes which is 8422686720 Bytes. This is 8.4GB or 7.8GiB. The two different ways of describing capacity can be confusing at times.

I rounded to the nearest GB. The eighth simulated drive was a little smaller as the drive was less than 8 times the limit.

0

Share this post


Link to post
Share on other sites

That's pretty interesting.

The other day when I created a MS-DOS partition of 8,036 MB, only 8,025 MB of those would be usable.

If I wanted to directly access more than one logical hard disk, I had to use IMDisk and enter the image file offset in blocks and the size of the virtual disk.

Since the primary partition has 2,047 MB, the extended partition having 5,977 MB (or 12,241,529 sectors), IMDisk would only mount the primary DOS partition (starting in sector 63 and ending on sector 4,192,964) and the first logical DOS partition (starting on sector 4,192,964 and ending on sector 8,385,929) in extended DOS partition.

IMDisk wouldn't even display info for the second logical DOS partition or even the third logical DOS partition. So, I had to enter the information manually for the following:

For the second logical DOS partition, the LBA image offset will start at sector 8,385,993 blocks and end on sector 12,578,894.

For the third logical DOS partition, the LBA image offset will start at sector 12,578,958 and end on sector 16,434,494). The third logical DOS partition has a capacity of 1,882.59 MB or 3,855,535 sectors.

One thing to note that for some reason when there is too much FAT on the hard disk partition, Windows 3.1 will eventually fail to boot properly with memory managers installed.

Update: I tested Windows 3.1 on a 3 GB hard disk with a FAT32 partition, but here's what I had to do in order to get Windows 3.0 or Windows 3.1 running on a FAT32 partition:

1. Create a virtual hard disk partition between 2,048 MB to 8,032 MB.

2. Use the Windows 95 OSR2, Windows 98, Windows 98SE (MS-DOS 7,1) or Windows Millennium boot disk to boot from the virtual floppy disk.

3. Partition the whole hard disk using FDISK with FAT32 support and make the partition active.

4. Format the hard disk.

5. Copy the following files from the Windows 95 OSR2, Windows 98 or Windows Millennium installation in order to use commands under MS-DOS 7.1 or MS-DOS 8.0. The following files found in \WINDOWS\COMMAND are from MS-DOS 7.1 when used with Windows 98 Second Edition for example:

ANSI     SYS         9,719  04-23-99 10:22p
ATTRIB EXE 15,252 04-23-99 10:22p
CHKDSK EXE 28,096 04-23-99 10:22p
CHOICE COM 5,239 04-23-99 10:22p
COUNTRY SYS 30,742 04-23-99 10:22p
DBLSPACE SYS 2,135 04-23-99 10:22p
DELTREE EXE 19,083 04-23-99 10:22p
DISKCOPY COM 21,975 04-23-99 10:22p
DISPLAY SYS 17,175 04-23-99 10:22p
DOSKEY COM 15,495 04-23-99 10:22p
EDIT COM 69,902 04-23-99 10:22p
EDIT HLP 10,790 04-23-99 10:22p
EGA CPI 58,870 04-23-99 10:22p
EMM386 EXE 125,495 04-23-99 10:22p
EXTRACT EXE 93,242 04-23-99 10:22p
FC EXE 20,574 04-23-99 10:22p
FDISK EXE 63,916 04-23-99 10:22p
FIND EXE 6,658 04-23-99 10:22p
FORMAT COM 49,575 04-23-99 10:22p
HIMEM SYS 33,191 04-23-99 10:22p
KEYB COM 19,927 04-23-99 10:22p
KEYBOARD SYS 34,566 04-23-99 10:22p
KEYBRD2 SYS 31,942 04-23-99 10:22p
KEYBRD3 SYS 31,633 04-23-99 10:22p
KEYBRD4 SYS 13,014 04-23-99 10:22p
LABEL EXE 9,324 04-23-99 10:22p
MEM EXE 32,146 04-23-99 10:22p
MODE COM 29,271 04-23-99 10:22p
MORE COM 10,471 04-23-99 10:22p
MOVE EXE 27,299 04-23-99 10:22p
MSCDEX EXE 25,473 04-23-99 10:22p
NLSFUNC EXE 6,940 04-23-99 10:22p
SCANDISK EXE 143,818 04-23-99 10:22p
SCANDISK INI 7,329 04-23-99 10:22p
SCANREG EXE 165,502 04-23-99 10:22p
SORT EXE 25,882 04-23-99 10:22p
START EXE 28,672 04-23-99 10:22p
SUBST EXE 17,904 04-23-99 10:22p
SULFNBK EXE 45,056 04-23-99 10:22p
SYS COM 18,967 04-23-99 10:22p
XCOPY EXE 3,878 04-23-99 10:22p
XCOPY32 EXE 3,878 04-23-99 10:22p
XCOPY32 MOD 41,472 04-23-99 10:22p

6. The following files that you can copy are the CD-ROM drive, mouse driver and the CPU idling driver, those are optional:

CDROM    SYS        11,202  06-07-96  5:30p
IDLE COM 128 03-11-04 3:03p
MOUSE COM 9,169 08-03-04 12:00p

7. The following files that you can copy are from a MS-DOS 5 to 6.22 installation, those are optional as well:

MONEY    BAS        46,225  05-31-94  6:22a
GORILLA BAS 29,434 05-31-94 6:22a
DOSSHELL COM 4,620 05-31-94 6:22a
DOSSHELL EXE 236,378 05-31-94 6:22a
DOSSHELL GRB 4,421 05-31-94 6:22a
DOSSHELL HLP 161,323 05-31-94 6:22a
DOSSHELL VID 9,462 05-31-94 6:22a
MSD EXE 165,864 05-31-94 6:22a
NIBBLES BAS 24,103 05-31-94 6:22a
QBASIC EXE 194,309 05-31-94 6:22a
QBASIC HLP 130,881 05-31-94 6:22a
REMLINE BAS 12,314 05-31-94 6:22a

8. Download and run Win3XStart 1.57 to get Windows 3.0 or Windows 3.1 working on a FAT32 partition.

9. Install Windows 3.0 or Windows 3.1. After that, reboot. You'll notice that you will have to reboot after Windows 3.x is installed.

10. In CONFIG.SYS, add the following:

FILES=30
BUFFERS=30
DEVICE=C:\DOS\HIMEM.SYS /testmem:off
DEVICE=C:\DOS\EMM386.EXE NOEMS I=B000-B7FF
LASTDRIVE=Z

11. In AUTOEXEC.BAT, add the following:

@ECHO OFF
PATH C:\DOS;C:\WINDOWS;
SET TEMP=C:\TEMP

12. Grab the WINA20.386 file from a MS-DOS-based installation and place it in the root directory on the boot drive.

13. Grab the IFSHLP.SYS either from a Windows for Workgroups 3.11 or Windows 0x/Me installation and place it in the \WINDOWS directory.

Windows 3.x should now run as usual. Please note that Windows 3.1's File Manager will report a hard disk drive larger than 2 GB as 2,097,088 KB. However, the File Manager used in Windows 3.0 will end up reporting negative numbers or not report the drive as the correct size if the drive is over the 2 GB limit. This is the case, because File Manager used signed 32-bit numbers to store hard disk space capacity in bytes and any number beyond 2,147,483,647 will wrap as a negative number and misrepresent the size of the hard disk over 2 GB.

I would also like to mention that some of the 16-bit DOS and 16-bit Windows-based software that relies on hard disks of 2 GB or small may not even work correctly, if not at all.

Edited by ppgrainbow
0

Share this post


Link to post
Share on other sites

I will be testing Windows 3.1 on a 3 GB and then a 10 GB partition FAT32 partition under MS-DOS 7.1 in a virtual machine to see what the side effects are and report back. :)

Windows 3 trashes the Current Directory entry upon exit if the drive is formatted to FAT32.

0

Share this post


Link to post
Share on other sites

I will be testing Windows 3.1 on a 3 GB and then a 10 GB partition FAT32 partition under MS-DOS 7.1 in a virtual machine to see what the side effects are and report back. :)

Windows 3 trashes the Current Directory entry upon exit if the drive is formatted to FAT32.

Really? How did you know that?

I resized the virtual hard disk using VHD resizer from 3 GB to 10 GB, booted up Windows 3.1 on a FAT32 partition in Virtual PC and it did not immediately trash the \WINDOWS directory.

But when I started up Windows 3.1 again and exited it, it dropped me back to C:\WINDOWS, I typed in the contents of the \WINDOWS directory and got this:

C:\WINDOWS>dir
Volume in drive C has no label
Volume Serial Number is 2443-1BEE
Directory of C:\WINDOWS

File not found
9,971.55 MB free

C:\WINDOWS>

Upon exiting Windows 3.1 on a FAT32 partition, all of the contents of the \WINDOWS directory are gone. I've noticed that this only occurs if Windows 3.x is started from the \WINDOWS directory.

SCANDISK refuses to detect any data corruption residing in the \WINDOWS directory when the hard disk gets scanned.

Windows 3.0 and Windows 3.1 will end up corrupting the current directory pointer in the drive table entries in MS-DOS 7.1 and MS-DOS 8 respectively. For this reason, Windows 3.x will not properly support hard disk and other media larger than 7.8 GB (or partitions larger than 2 GB on a FAT or FAT 32 partition) without a high probably of data corruption.

Hard disk and other media larger than 7.8 GB were not available at the time when Windows 3.0 and Windows 3.1 were released. And the changes that would be required to support hard disks larger than 7.8 GB (and partitions larger than 2 GB) would require architectural changes that will never be supported on Windows 3.x.

The only way to fix this is to either run SCANDISK or press CTRL+ALT+DELETE to reboot and the bug should go away. :)

Edited by ppgrainbow
0

Share this post


Link to post
Share on other sites
[...]  The only way to fix this is to either run SCANDISK or press CTRL+ALT+DELETE to reboot and the bug should go away. smile.gif

 

Only the Current Directory Pointer in RAM is affected. There is no corruption on the Hard Drive itself. CDing to an absolute Path will also clear the bug. I added a Patch to Windows 3 to fix this problem.

0

Share this post


Link to post
Share on other sites
Only the Current Directory Pointer in RAM is affected. There is no corruption on the Hard Drive itself. CDing to an absolute Path will also clear the bug. I added a Patch to Windows 3 to fix this problem.

 

Oh really? I didn't know that. The bug turns out to be harmless after all. Is there a direct link to the patch to fix this bug?

If so, let me know. I'll probably look for the patch online. smile.gif

0

Share this post


Link to post
Share on other sites

Oh really? I didn't know that. The bug turns out to be harmless after all. Is there a direct link to the patch to fix this bug?

If so, let me know. I'll probably look for the patch online. smile.gif

 

It may not be harmless if you attempt to write into the Current Directory.
There is no link as far as I know. I wrote the Patch myself.

0

Share this post


Link to post
Share on other sites
It may not be harmless if you attempt to write into the Current Directory.

There is no link as far as I know. I wrote the Patch myself.

 

Thank you for telling me. I noticed that according to this forum thread, data corruption will eventually occur if you attempt to write to the current directory pointer.

I found that a better solution would be to use a hex editor to patch WIN386.EXE found in the \WINDOWS\SYSTEM directory to see if it fixes the directory corruption bug or not:

In Windows 3.1, edit the following:

 

 

0005EA26: 66 C7 46 49 FF FF -> 6A FF 8F 46 49 90

0005EC38: 66 C7 46 49 FF FF -> 6A FF 8F 46 49 90

In Windows 3.11, edit the following:

 

 

00065A26: 66 C7 46 49 FF FF -> 6A FF 8F 46 49 90

00065C38: 66 C7 46 49 FF FF -> 6A FF 8F 46 49 90

I myself used the hex editor to patch those files and placed them in separate directories on a 1.44 MB diskette image:

1. For WIN386.EXE used in Windows 3.1, the size of the file is 544,789 bytes (532 KB) and it's placed in the \WIN.310 directory.

2. For WIN386.EXE used in Windows for Workgroups 3.111, the size of the file is 577,557 (564 KB) and it's placed in the \WFW.311 directory.

The patch made hasn't been tested on Windows for Workgroups 3.1 and Windows 3.11. The directory corruption fix will not work in Windows 3.0 as I don't think that there is a fix to this issue. sad.gif Users who want to run Windows 3.0 on a FAT32 partition under FreeDOS, MS-DOS 7.1 or MS-DOS 8.0 will have to use a partition of 2 GB or smaller.

0

Share this post


Link to post
Share on other sites
The patch made hasn't been tested on Windows for Workgroups 3.1 and Windows 3.11. The directory corruption fix will not work in Windows 3.0 as I don't think that there is a fix to this issue. sad.gif Users who want to run Windows 3.0 on a FAT32 partition under FreeDOS, MS-DOS 7.1 or MS-DOS 8.0 will have to use a partition of 2 GB or smaller.

 

When I posted those Patches, I did not have Windows 3.0 handy. It probably can be Patched also.

0

Share this post


Link to post
Share on other sites
When I posted those Patches, I did not have Windows 3.0 handy. It probably can be Patched also.

How can WIN386.EXE in Windows 3.0 and Windows 3.0a be patched too?

Also, is there a patch to overcome the 16 MB physical limit in Windows 3.0/3.0a or is this by design? If so, which of the files in Windows 3.0 would you have to patch up?

0

Share this post


Link to post
Share on other sites

How can WIN386.EXE in Windows 3.0 and Windows 3.0a be patched too?

Also, is there a patch to overcome the 16 MB physical limit in Windows 3.0/3.0a or is this by design? If so, which of the files in Windows 3.0 would you have to patch up?

I would need to find copies of WIN386.EXE for Windows 3.0 and 3.0a before I could answer that.

I am not familiar with the 16MB limit.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.