ppgrainbow Posted December 1, 2012 Author Share Posted December 1, 2012 (edited) 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/84388A 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 December 1, 2012 by ppgrainbow Link to comment Share on other sites More sharing options...
rloew Posted December 2, 2012 Share Posted December 2, 2012 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/84388A 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. Link to comment Share on other sites More sharing options...
ppgrainbow Posted December 2, 2012 Author Share Posted December 2, 2012 (edited) 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/84388A 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.0As 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 December 2, 2012 by ppgrainbow Link to comment Share on other sites More sharing options...
rloew Posted December 2, 2012 Share Posted December 2, 2012 Alright. I sent you a e-mail so that you can look into the current directory data corruption issue under Windows 3.0I 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. Link to comment Share on other sites More sharing options...
ppgrainbow Posted December 2, 2012 Author Share Posted December 2, 2012 Alright. I sent you a e-mail so that you can look into the current directory data corruption issue under Windows 3.0I 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. Link to comment Share on other sites More sharing options...
os2fan2 Posted December 2, 2012 Share Posted December 2, 2012 DOS findings by os2fan2Here 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.14Windows 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.3A 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 52, 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 Link to comment Share on other sites More sharing options...
os2fan2 Posted December 2, 2012 Share Posted December 2, 2012 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 OFFchoice /n /cABCDEFGHIJKLMNOPQRSTUVWXYZ Choose drive:: FINDCDFOR %%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=%%DFOR %%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=%%DECHO 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 AllenThis works under command.com, but not under 4dos.com. Link to comment Share on other sites More sharing options...
ppgrainbow Posted December 3, 2012 Author Share Posted December 3, 2012 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 Windowscannot run in 386 enhanced mode;please reboot your computer and try again or else run Windows inreal 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:\WINDOWSWinBootDir=C:\WINDOWSWindows 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. Link to comment Share on other sites More sharing options...
ppgrainbow Posted December 3, 2012 Author Share Posted December 3, 2012 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! Link to comment Share on other sites More sharing options...
rloew Posted December 3, 2012 Share Posted December 3, 2012 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 Windowscannot run in 386 enhanced mode;please reboot your computer and try again or else run Windows inreal 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:\WINDOWSWinBootDir=C:\WINDOWSWindows 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. Link to comment Share on other sites More sharing options...
ppgrainbow Posted December 4, 2012 Author Share Posted December 4, 2012 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 Windowscannot run in 386 enhanced mode;please reboot your computer and try again or else run Windows inreal 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:\WINDOWSWinBootDir=C:\WINDOWSWindows 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.I lowered the RAM to 12 MB and it wasn't too much of a help. I'll try to experiment Windows 3.0 on a FAT 32 partition again soon to see what I can come up with. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now