Open 386MAX 8.58

Open 386MAX 8.58, English (US) and German (GR).

A maintenance release of the 8.x line: bug fixes from the 9.x work, each with a test in the regression suite.

Bug fixes

• XMS 01h/02h now mark the HMA as used in all copies of 386MAX's data. 386UTIL and MAXIMIZE read those copies and never saw DOS in the HMA.
• On 486 and later CPUs, the FPU was mistaken for a Cyrix EMC87 and a Weitek coprocessor was reported. 386UTIL WEITEK=ON then hung the machine with DOS=HIGH. The EMC87 check now runs on a 386 only. Weitek and EMC87 support stays for old hardware.
• Port 92h is trapped on every machine. FORCEA20 is now the default; UNSHIFT turns it off. A program that turned A20 off through port 92h or the keyboard controller turned off the real A20 line under paging and crashed.
• INT 15h 2400h/2401h (A20 off/on) did nothing, and 2402h reported the A20 state the wrong way round.
• INT 15h E801h and E820h report only the memory 88h leaves to INT 15h clients. The rest is marked reserved. The BIOS answers showed 386MAX's own memory as free, and a program that trusted them could overwrite it.
• Without 64KB free above 640KB, the EMS page frame went into conventional memory, and MS-DOS 6.22 hung after 386MAX. 386MAX now installs without a page frame (as with NOFRAME) and says so.
• XMS 11h/12h free or resize only UMBs from XMS 10h, not any DOS memory block. XMS 10h returns DX=0 with error B1h.
• EMS 5201h (make a handle volatile) failed with 91h.
• Nested DPMI real-mode callbacks are refused with 8012h when the ring 0 stack runs low. About 70 levels used to corrupt the memory tables. 386MAX's own DOS translation keeps its reserve, so HX RMCB8 unwinds cleanly.
• VCPI with about 1GB of RAM or more: DE01h wrote past the client's page table buffer (HDPMI said "insufficient memory" and DOS memory was broken). Now DE01h fails with 84h if 386MAX doesn't fit, and EXTSIZE defaults to at most 896MB, with a warning above that. DE05h freed DE04h pages again from 512MB on.
• STRIPMGR found no section in an MS-DOS 6 multi-configuration CONFIG.SYS ([MENU] ... [NORMAL]), so HIMEM.SYS stayed after 386MAX in the active section. The cause was a compiler register assumption in the small model; STRIPMGR, BATPROC and SNAPSHOT are rebuilt.
• SETUPDOS, MAXIMIZE, STRIPMGR and ASQ work on the files the running DOS reads: FDCONFIG.SYS on FreeDOS, DCONFIG.SYS on DR DOS, and the startup batch file given to COMMAND.COM (/K on MS-DOS, /P=file or /P:file with FreeCOM such as FDAUTO.BAT, /P:file on DR DOS such as AUTODOS7.BAT). Before, they changed CONFIG.SYS and AUTOEXEC.BAT, which these systems didn't run.
• STRIPMGR recognizes the FreeDOS and DR DOS line prefixes (1?DEVICE=, !DEVICE=, ?DEVICE=) and the FreeDOS memory managers HIMEMX, HIMEMSX, JEMMEX and JEMM386. They used to stay in CONFIG.SYS before 386MAX.
• ASQ (and MAXIMIZE without 386MAX) no longer writes test patterns into the system ROM area. Under UEFI with CSMWrap it is RAM, and the CSM's BIOS proxy crashed.

Regression tests

New tests: V86/A20, MAX/MAXINFO, MAX/UTIL (386UTIL with all switches), MAX/UMBDOS, MAX/HMADOS, XMS/XMSUMB, XMS/XMSLOCK, EMS/EMSMORE, DPMI/RMCBNEST, DPMI/PMSTACK, DPMI/CALLGATE, DPMI/NULLSEG, DPMI/LINOOM, DPMI/MANYSEL, DPMI/DPMILEAK, DPMI/DPMIMISC, DPMI/MAXAPI. V86/INT15 and VCPI/VCPIFUNC were extended. Under 386MAX every test passes on MS-DOS 6.22 and 7.1, Enhanced DR-DOS, SvarDOS and FreeDOS.

Installation from the floppy disks was tested in QEMU in English and German.