Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

Testing MS-DOS limitations

- - - - -

  • Please log in to reply
25 replies to this topic

#1
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag

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:\>mem

Memory Type Total = Used + Free
---------------- ------- ------- -------
Conventional 640K 24K 616K
Upper 115K 96K 19K
Reserved 0K 0K 0K
Extended (XMS) 65,985K 450K 65,535K
---------------- ------- ------- -------
Total memory 66,739K 569K 66,170K

Total under 1 MB 755K 120K 635K

Largest 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, 27 October 2013 - 03:52 PM.
Removed the [size=1] tags, which are only useful to render text not meant to be read...

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64



How to remove advertisement from MSFN

#2
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,042 posts
  • OS:none specified
  • Country: Country Flag
Is it me or you used an unreadable (tiny) font size?
Can you set ti to "normal"?

jaclaz

#3
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#4
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag


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, 28 November 2012 - 02:13 PM.

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#5
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag



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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#6
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag
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, 28 November 2012 - 11:41 PM.

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#7
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#8
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag


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, 29 November 2012 - 12:12 AM.

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#9
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag



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. :)

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#10
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag




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. :)

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. :)

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#11
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

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. :)

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#12
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag


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. :)

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. :( 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.

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#13
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag



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. :)

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.11, 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. :( 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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#14
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag




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. :)

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.11, 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. :( 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.


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?

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#15
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#16
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag


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.


Should I send you a e-mail for the details?

In a DOSBox machine, I had to set the memory limit to 64 MB, copy the KRNL286.EXE, KRNL386.EXE and WIN386.EXE files from a Windows 3.1 installation and for some reason...Windows 3.0 would throw me back to DOS. As you're not familiar with the 16 MB limit, I will have to revert the changes until further notice. :(

More about the memory limits at this page: http://support.microsoft.com/kb/84388

A temporary workaround for a Windows 3.0 installation with more than 16 MB of system memory would be to create a RAM disk drive to occupy the amount of memory until the total amount of physical memory is 16 MB of less. :)

1. If the amount of memory installed is 24 MB, then a 8 MB RAM disk would need to be created.
2. If the amount of memory installed is 32 MB, then a 16 MB RAM disk would need to be created.
3. If the amount of memory installed is 48 MB, then a 32 MB RAM disk would need to be created.
4. If the amount of memory installed is 64 MB, then a 48 MB RAM disk would need to be created and you will have to use a third-party RAM disk driver such as XMSDisk. If you use Microsoft's RAMDRIVE.SYS driver then at least two RAM disk drives, a 32 MB and a 16 MB would be created.

Edited by ppgrainbow, 01 December 2012 - 05:05 PM.

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#17
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag



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.


Should I send you a e-mail for the details?

In a DOSBox machine, I had to set the memory limit to 64 MB, copy the KRNL286.EXE, KRNL386.EXE and WIN386.EXE files from a Windows 3.1 installation and for some reason...Windows 3.0 would throw me back to DOS. As you're not familiar with the 16 MB limit, I will have to revert the changes until further notice. :(

More about the memory limits at this page: http://support.microsoft.com/kb/84388

A temporary workaround for a Windows 3.0 installation with more than 16 MB of system memory would be to create a RAM disk drive to occupy the amount of memory until the total amount of physical memory is 16 MB of less. :)

1. If the amount of memory installed is 24 MB, then a 8 MB RAM disk would need to be created.
2. If the amount of memory installed is 32 MB, then a 16 MB RAM disk would need to be created.
3. If the amount of memory installed is 48 MB, then a 32 MB RAM disk would need to be created.
4. If the amount of memory installed is 64 MB, then a 48 MB RAM disk would need to be created and you will have to use a third-party RAM disk driver such as XMSDisk. If you use Microsoft's RAMDRIVE.SYS driver then at least two RAM disk drives, a 32 MB and a 16 MB would be created.

I would assume that the Current Directory Fix for Windows 3.0 would involve finding the same pattern and replacing it with the same data as Windows 3.1. If not, you can E-Mail me the two Versions to examine.

Fixing the memory limitation probably would involve a significant amount of work. The very limited number of users and the availability of Windows 3.1 makes this unworthwhile.
I already have a memory limiter that can set the available memory to anything I want.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#18
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag




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.


Should I send you a e-mail for the details?

In a DOSBox machine, I had to set the memory limit to 64 MB, copy the KRNL286.EXE, KRNL386.EXE and WIN386.EXE files from a Windows 3.1 installation and for some reason...Windows 3.0 would throw me back to DOS. As you're not familiar with the 16 MB limit, I will have to revert the changes until further notice. :(

More about the memory limits at this page: http://support.microsoft.com/kb/84388

A temporary workaround for a Windows 3.0 installation with more than 16 MB of system memory would be to create a RAM disk drive to occupy the amount of memory until the total amount of physical memory is 16 MB of less. :)

1. If the amount of memory installed is 24 MB, then a 8 MB RAM disk would need to be created.
2. If the amount of memory installed is 32 MB, then a 16 MB RAM disk would need to be created.
3. If the amount of memory installed is 48 MB, then a 32 MB RAM disk would need to be created.
4. If the amount of memory installed is 64 MB, then a 48 MB RAM disk would need to be created and you will have to use a third-party RAM disk driver such as XMSDisk. If you use Microsoft's RAMDRIVE.SYS driver then at least two RAM disk drives, a 32 MB and a 16 MB would be created.

I would assume that the Current Directory Fix for Windows 3.0 would involve finding the same pattern and replacing it with the same data as Windows 3.1. If not, you can E-Mail me the two Versions to examine.

Fixing the memory limitation probably would involve a significant amount of work. The very limited number of users and the availability of Windows 3.1 makes this unworthwhile.
I already have a memory limiter that can set the available memory to anything I want.


Alright. I sent you a e-mail so that you can look into the current directory data corruption issue under Windows 3.0

As for Windows 3.0, I honestly agree. PCs that had 16 MB of memory (or more) were not available at the time when Windows 3.0 and Windows 3.0a came out in 1990 and the changes that are required to overcome (break) the 16 MB memory limit under Windows 3.0 would involve more than a significant amount of work, it would require architectural changes that can never be supported under Windows 3.0.

Windows 3.1 is capable of addressing up to 64 MB of memory under MS-DOS 4.0 to MS-DOS 6.22 (and MS-DOS 6.3 beta) and up to 512 MB of memory when Windows 3.1 is only run in Standard Mode in MS-DOS 7.0 through 8.0 as well as FreeDOS.

Edited by ppgrainbow, 01 December 2012 - 07:48 PM.

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#19
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

Alright. I sent you a e-mail so that you can look into the current directory data corruption issue under Windows 3.0

I examined the files and did not find any suspicious code.
I inserted the 3.0 Version into my Windows 3.1 Setup. I did not see any Current Directory corruption on exit.
If the problem exists in 3.0 then it probably occurs elsewhere.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#20
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag


Alright. I sent you a e-mail so that you can look into the current directory data corruption issue under Windows 3.0

I examined the files and did not find any suspicious code.
I inserted the 3.0 Version into my Windows 3.1 Setup. I did not see any Current Directory corruption on exit.
If the problem exists in 3.0 then it probably occurs elsewhere.


I believe so. I'm gonna be doing a test installation of Windows 3.0 in Virtual PC on a 3 GB and 10 GB hard disk partitions in VirtualPC to see if there is any side effects from the "current directory" data corruption.

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#21
os2fan2

os2fan2

    Advanced Member

  • Member
  • PipPipPip
  • 421 posts
DOS findings by os2fan2

Here are some interesting things i found and collected of dos.

Drivers

                                   Emm   Ram  Smart
                Pk         Himem   386  Drive  Drv  Mouse  Mscdex  MSD
   Win286  2.11  C 880527  1.0           2.04  1.05
   Win386  2.10  C 880907  2.04          2.10  2.10
   DR-DOS  3.40  C 890630           ?   R1.01
   MS-DOS  4.01  C 890407  2.04   4.00   2.12  2.10
   DRDOS   5.00    900814
   OS/2    2.11    940129  2.10   4.00              (9.01)
   MS-Win  3.00            2.60   4.10   3.04  3.03  7.04  
   B PDS   7.10  U 900624  2.60          3.04  3.03
   MS-Win  3.01  S 901031  2.60   4.10   3.04  3.06  7.04
   MS-WMM  3.07  C 911001  2.60   4.10   3.04  3.06                1.10
   IBMDOS  5.00  S 910509  2.77   4.20   3.06  3.13  7.04
   OS/2 NT                (2.77)                    (8.00) (2.21)  2.00
   MS-DOS  5.00  S 911111  2.78   4.33   3.06  3.13  
   IBMDOS  5.02  S 920901  2.78   4.33   3.06  3.13  8.20          2.00
   MSC     7.00  K 920305  2.78   4.33   3.06  4.00  8.20          2.00
   b 068   3.10    920203  3.03   4.41   3.06  4.00  8.20          2.00 x
   MASM    6.11  K 920305  3.07   4.44   3.06  4.00  8.20
   MS-Win  3.10  S 920310  3.07   4.44   3.06  4.00  8.20          2.00
   MS-WfW  3.30  S 921001  3.07   4.44   3.06  4.00  8.20   2.21   2.00a
   DR-DOS  6.00  C 920407
   MS-Win  3.11  K 931231  3.07   4.44   3.06  4.00                2.00
   MS-DOS  6.00  K 930310  3.07   4.45   3.06  4.10  8.20   2.22   2.01
   IBMDOS  6.00  K 930629  3.09   4.45   3.06  4.10  8.20
   PC-DOS  6.10  K 931116  3.09   4.45   3.06  4.10  8.20
   MS-Fix  6.0a  Z 930601                      4.20
   PC-DOS  6.30  K 931231  3.09   4.48   3.06  5.00  9.01   2.23
   MS-DOS  6.07  C 940101  3.10   5.00   3.07  5.00         2.22   2.01
   MS-DOS  6.20  K 930927  3.10   4.48   3.07  5.00  8.20   2.23   2.01
   MS-DOS  6.21  K 940213  3.10   4.48   3.07  5.00         2.23   2.01
   MS-WfW  3.31  K 931101  3.10   4.48   3.07  5.00         2.23   2.10
   MS-DOS  6.22  K 940531  3.10   4.49   3.07  5.01  8.20   2.23   2.11
   DR-DOS  7.00  C 940126
   PC-DOS  7.00  P 941117  3.15   4.50   3.10  5.10  8.20   2.25
   DR-DOS  7.03  C 980107
   PC-DOS  7.10  C 031002  3.15          3.10  5.10         2.25
   Win-95  3.95  X 950711  3.95   4.95   3.06  5.00 (8.30)  2.25   2.13
   Win-98  3.98  X 990423  3.95   4.95   3.06  5.02 (8.30)  2.25   2.14
   Win-ME  3.99           (3.99)  4.95   3.06  5.02 (8.30)  2.25   2.14


Windows 3.01 and 3.07 are 3.00a and 3.00 mme respectively.  Wfw 3.30 and 3.31 are vers 3.10 and 3.11.

MS-DOS 6.07 is MS-DOS 7.0 beta 1.  It is largely based on MS-DOS 6.00, but has drivers of version 6.20 vintage.


None of these drivers seem to be dos dependent, save for MS-fix for smartdrv,exe 4.20, which had an artificial check for DOS 6.0 or greater. It actually requires DOS 3.3

A number of utilities that ship with DOS can be used with other versions of dos.

1 deltree, move and choice do not check for dos versions, and work with DOS 5
2, acalc, backup, crc, dynaload, internk/intersvr, msd, qconfig, xdf, xdfcopy, work with any version of DOS. Many of these come from PC-DOS 7 (which largely have the versioning removed)
3. DOS-free versions packages that work with DOS. defrag and scandisk complain for versions of dos less than 6.0 m=msdos, p=pcdos.

m63=msdos 6.21, m64=ms-dos 6.22, p52 = pcdos 5.02

   ADOS                         m60       m62  m63  m64
   CPBACKUP                                              p60  p61  p63  p70
   CPCOMMON                                              p60  p61  p63  p70
   DBLSPACE                     m60  m61  m62
   DOSSHELL      m50  p50  p52  m60  m61  m62  m63  m64  p60  p61  p63  p70
   DRVSPACE                                         m64                      m70  m71
   E3-DOS                                                p60  p61  p63  p70
   EDITv2                                                                    m70  m71
   FILEUP                                                               p70
   IBMAV                                                 p60  p61  p63  p70
   MEMMAKER                     m60  m61  m62  m63  m64                      m70 
   MSAV                         m60  m61  m62  m63  m64
   MSBACKUP                     m60  m61  m62  m63  m64                      m70
   NETWORK                      m60       m62  m63  m64
   PCMCIA                                                p60  p61  p63  p70
   PENDOS                                                p60  p61  p63  p70
   QBASIC 1.0    m50  p50  p52
   QBASIC 1.1                   m60  m61  m62  m63  m64                      m70  m71
   REXX                                                                 p70
   SSTOR                                                      p61  p63
   STACKER                                                              p70
   VIEW                                                                 p70


#22
os2fan2

os2fan2

    Advanced Member

  • Member
  • PipPipPip
  • 421 posts
BennyLevel is a hack around the DOS errorlevel bug, which treats a two letter errorlevel as

10*h- + l - 11*'a'+11, modulo 256

(c2d('x')*10+c2d('a')-528)//256
(c2d('H')*10+c2d('a')-528)//256

(10*('x'-'0')-('$'-'0'))mod 256 lower case
(10*('H'-'0')-('$'-'0'))mod 256 upper case

What the batch does here, is test the hex on HA



@ECHO OFF
choice /n /cABCDEFGHIJKLMNOPQRSTUVWXYZ Choose drive:
: FINDCD
FOR %%D IN (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) IF ERRORLEVEL H%%D SET DRIVE=%%D
FOR %%D IN (a b c d e f g h i j k l m n o p q r s t u v w x y z) IF ERRORLEVEL x%%D SET DRIVE=%%D
ECHO You chose drive %DRIVE%


================================================

Benny Pederson recently discovered an important new batch feature (4th November 2000 in alt.msdos.batch thread "Choice" ), namely that ERRORLEVEL checks can be made with characters other than 0-9. As I posted at the time, the values of the characters run in parallel to their ASCII values (they are their ASCII values less 48 decimal, 30hex). In other words, Command.com _doesn't_ check range on the character, it just subtracts the offset ASCII character 0 (zero = 48 decimal, 30 hex). To distinguish this from ordinary
ERRORLEVEL checking, I call this _BennyLevel_ checking.

For convenience, throughout the following account, I call ASCII-Value-Of [character] - 48 the BennyValue of the character.

All normal keyboard characters can be used (except the five in exception list below): from the character next in ASCII order after [space], namely ! (exclamation 33 decimal, 21hex) through to ~ (tilde 126 decimal, 7Ehex). High ASCII characters (above 127 decimal, 7Fhex) can be used also, but because of code page variations, this is less useful. In the rest of this, I use DECIMAL arithmetic to avoid the constant translations in parentheses.

A very small number of characters can't be used because of conflicts. The five characters which can't be used are:
comma ,
semicolon ;
less than <
equals =
greater than >

Note that percent (%) _can_ be used (but _beware_ of generating internal script conflicts with environment variables)

For combinations of two Benny characters, Command.com just applies the algorithm: if second character present, multiply BennyValue of first by 10, add BennyValue of second. Similarly for three characters:
(BennyValue first x 100) + (BennyValue second x 10) + (BennyValue third).

To give examples:
The BennyValue for A (ASCII 65)= 65 - 48 = 17 decimal, thus
IF ERRORLEVEL A is true for ERRORLEVELs >= 17 decimal

The BennyValue for a (ASCII 97) is 97 - 48 = 49 decimal, thus
IF ERRORLEVEL a is true for ERRORLEVELs >= 49 decimal

Also _note_ that ERRORLEVELs work modulo 256, so
IF ERRORLEVEL 513
and
IF ERRORLEVEL 257
and
IF ERRORLEVEL 1
are all equivalent.

BennyValues make it very easy to construct high ERRORLEVELs.

In my opinion, this is a _very_significant_ and exploitable feature. It (turns out that it) has been a feature of Command.com for the past 14 years (since DOS 3.20) for certain, and almost certainly
since DOS 2.0 when the IF command and ERRORLEVEL checking were both introduced. As far as I know Benny Pederson was the first to discover this feature in all this time.

Simple example showing calculation to simplify Choice menus:

The first of the two example batch scripts I posted was:
::====BENNYDRU.BAT
@ECHO OFF
choice /n /cABCDEFGHIJKLMNOPQRSTUVWXYZ Choose drive:
FOR %%D IN (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) DO IF ERRORLEVEL H%%D SET DRIVE=%%D
ECHO You chose drive %DRIVE%
::====
Only four lines in the above (watch for accidental line wrap).

In this script, BennyLevel checking is used with an offset (calculated as below) to make the Choice letter result and the corresponding BennyLevel check letter from the FOR IN DO loop become the same letter in each case.

To make this work, you need the ERRORLEVEL resulting from each Choice entry to match the BennyLevel check by that letter. Choice is not case sensitive, but BennyValue _IS_, of course, case sensitive, because it derives from the ASCII value. In this example I work with an Upper Case BennyLevel check

The BennyValue of A is 17 (ASCII 65 - 48). A (or a) in Choice in the above returns ERRORLEVEL 1. To make them match, we use ERRORLEVEL overflow - remember ERRORLEVEL works modulo 256. Also remember the algorithm Command.com uses for character pairs is 10 x BennyValue(first) + BennyValue(second)

So we match ERRORLEVELs 17 and 1 by solving the following equation in integers m and n:

10m + 17 = 256n + 1

and it's easily seen that m = 24 and n = 1 will solve this. The important part of the solution is the m value. The character whose BennyValue is 24 = H .

Therefore, the BennyLevel check: IF ERRORLEVEL HA
is the same as IF ERRORLEVEL 1
and similarly HB is the same as 2 and so on.

Hence, the offset H in the above Uppercase Benny check.

Similarly, we can produce a lower case result as in the second script:
::====BENNYDRL.BAT
@ECHO OFF
choice /n /cABCDEFGHIJKLMNOPQRSTUVWXYZ Choose drive:
FOR %%D IN (a b c d e f g h i j k l m n o p q r s t u v w x y z) DO IF ERRORLEVEL x%%D SET DRIVE=%%D
ECHO You chose drive %DRIVE%
::====
Only four lines in the above (watch for accidental line wrap).

Here the BennyValue of a is 49 (ASCII 97 - 48), so the equation to solve becomes:

10m + 49 = 256n + 1

We easily see that n = 3 and thus m = 72 solve this. If you can't see this quickly, all I am doing is finding the first multiple of 256 that when you add 1 gives a last digit of 9. Then I know that when I subtract 49 I will get a multiple of 10 (in this case 720).

Again, the important value is m = 72. We need the character whose BennyValue is 72 = x (ASCII 120 - 48). Hence the offset x will allow a simple FOR IN DO lowercase Bennycheck of the ERRORLEVEL from Choice without any padding characters. All the padding can be done with a BennyValue offset prefix to the ERRORLEVEL check.

You would use the first version of the script (with Upper Case list in FOR IN DO loop and offset H) if you wanted to return an Upper Case result. You would use the second version of the script (with Lower Case list in FOR IN DO loop and offset x) if you wanted to return a Lower Case result. The case of the Choice list doesn't matter in either version, of course, since Choice is not case sensitive.

Further note on characters prior to ASCII 0 ( = 48):
===================================================

Characters prior to ASCII character 0 (=ASCII 48) work as follows:

Take example of ! (exclamation = ASCII 33 decimal). The BennyValue of ! is 33 - 48, but Command.com works modulo 256 so this is translated to 33 - 48 + 256 = 241

Thus:
IF ERRORLEVEL !
is equivalent to
IF ERRORLEVEL 241

and, because of the properties of modulo arithmetic, these characters work in combinations with other characters, too: thus, !A is the BennyLevel for 123, so
IF ERRORLEVEL !A
and
IF ERRORLEVEL 123
are equivalent.

Work this out as follows:
BennyValue of ! (ASCII 33) = (33 - 48) -15 = 241 (mod 256),
(to get the value mod 256, just add 256 to -15)

and BennyValue A (ASCII 65) = 65 - 48 = 17:
hence: 10 x 241 +17 = 2427 = 123 (mod) 256

======

And all this has been in Command.com since DOS 3.20 and probably since DOS 2.0. All thanks to the original programmer nearly 20 years ago who _didn't_ put in an entirely unnecessary range check<G>.

--
William Allen

This works under command.com, but not under 4dos.com.

#23
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag
Okay, for some reason, when I tried to run Windows 3.0 on top of MS-DOS 7.1 whatever or not the drive is formatted as a FAT or FAT32 partition, attempting to boot Windows 3.0 or Windows 3.0a throws this error message:

The conventional memory in your system is fragmented and Windows
cannot run in 386 enhanced mode;

please reboot your computer and try again or else run Windows in
real mode by typing win /r.


If I strip out the two lines in [Path] at the beginning of MSDOS.SYS and keep HostWinBootDrv=C paramenter:

WinDir=C:\WINDOWS
WinBootDir=C:\WINDOWS

Windows 3.0 would boot on a FAT32 partition. However, doing that under Virtual PC causes the screen to go blank when Windows 3.0 is run in 386 Enhanced Mode. :( I'll probably give it a go and test Windows 3.0 under DOS 7.1 in VMware soon.

I tested a ran Windows 3.0 VM with MS-DOS 5.0 and it worked okay without problems.

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#24
ppgrainbow

ppgrainbow

    Advanced Member

  • Member
  • PipPipPip
  • 448 posts
  • OS:Vista Ultimate x64
  • Country: Country Flag
Thank you so much for posting all of the info regarding DOS findings and BennyLevel hacks regarding MS-DOS and PC-DOS, os2fan. I really appreciate it! :thumbup

AVA Direct FX AM3+ specs: Zalman ZM Z9-U3 Black Mid-Tower case / ASUS M5A97 R2.0 / AMD FX-4300 3.8 GHz quad-core processor / Fractal Design Integra R2 500W PSU/ Hyper 212 EVO CPU cooler / Western Digital BLACK SERIES 1 TB (WD1003FZEX) SATA III 7200 RPM / Lite-On iHas124 Black 24x DVD-RW / Sabrent CRW-UINB internal memory card w/USB 2.0 port (to be replaced soon) / 8 GB Crucual (2 x 4GB) Ballistix Sport PC3-12800 DDR3 RAM / EVGA GeForce 8400 GS 520 MHz 1 GB GDDR3 / Microsoft Windows Vista Ultimate SP2 x64


#25
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag

Okay, for some reason, when I tried to run Windows 3.0 on top of MS-DOS 7.1 whatever or not the drive is formatted as a FAT or FAT32 partition, attempting to boot Windows 3.0 or Windows 3.0a throws this error message:

The conventional memory in your system is fragmented and Windows
cannot run in 386 enhanced mode;

please reboot your computer and try again or else run Windows in
real mode by typing win /r.


If I strip out the two lines in [Path] at the beginning of MSDOS.SYS and keep HostWinBootDrv=C paramenter:

WinDir=C:\WINDOWS
WinBootDir=C:\WINDOWS

Windows 3.0 would boot on a FAT32 partition. However, doing that under Virtual PC causes the screen to go blank when Windows 3.0 is run in 386 Enhanced Mode. :( I'll probably give it a go and test Windows 3.0 under DOS 7.1 in VMware soon.

I tested a ran Windows 3.0 VM with MS-DOS 5.0 and it worked okay without problems.

When I ran my experiments, I had to limit RAM to 15MB and enable EMM386.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN