Reply 120 of 121, by ElTentakel
DoZator wrote on Today, 12:24:If memory above 4G is used, it will be necessary to check whether there is any useful data in these ranges, since many users of such systems often use something like "RAMDRV4M" or "RamDsk64", and user data may easily be present there - data that is saved in memory above 4G even after switching to MS-DOS mode, as well as after a hardware reboot of the PC (in the case of "RAMDRV4M"); this data continues to be used under Windows. Could GLIDULATOR somehow fail to notice and damage this data if it does go beyond 4G and manages to reach it, or is such a thing ruled out?
Pył with EMM386 but without HDPMI32i crashes while loading a level on one tester's machine (HIMEM + EMM386, DOS/4GW directly). Without EMM386, or with HDPMI32i, it loads. Cause not known yet; please report the error text and a trace log if you see it.
In version 9.6, these crashes stopped. In MS-DOS modes, everything works stably - before and after Windows (only one core). HDPMI32I adds support for multithreading to EMM386 (in both cases). Everything works just as stably and smoothly. Performance has noticeably improved (it started improving rapidly back in version 0.9.5) and it’s now playable. On Windows, there’s only one core with glide2x.ovl (just as before). Thank you.
Previously the registers were not cleaned up properly, so this explains it completly. And no, I hadn't thought about RAM disks, thank you for pointing that out.