hnlyzhd:
"Got it", what exactly is "got it"? Is it that chainloader (hd....)/ieldr was successful? Or something else? Thank you for the detailed description. According to your description, it seems that the method of chainloader (hd....)/ieldr should be almost successful, and no additional command-line parameters need to be added.
Esme:
Thank you for the detailed report. I have reviewed the source code in asm.S in these versions again. I found that the earliest and most crude pre version was a lucky hit. This crude version actually suits the appetite of your ntfs4dos pro, which is really a mixed feeling.
When I first wrote this pre-release version, I used the int15 instruction when reading the virtual sector data in the extended memory. Later versions were improved, sometimes using the int15 instruction, and sometimes using pushf; call far to directly call the original int15 entry address in the BIOS. That is, in real mode, we need to call the original BIOS program, and in protected mode, since the BIOS is no longer valid, we should call the int15 instruction at this time.
Your ntfs4dos pro does not comply with the int15/EAX=e820h specification. It arbitrarily moves the system memory space that is reserved and not allowed to be used casually by int15/EAX=e820h. If we modify the program to adapt to ntfs4dos pro, then a large number of other programs may fail. So, let's just abandon it. Does anyone have any opinions? Maybe someone will say, add another map command-line parameter to control this behavior, so that it can meet the requirements of ntfs4dospro. However, the problem is that our parameter space is exhausted. For such a non-compliant program, it is not suitable for us to make major adjustments. Our program can cooperate well with Microsoft's DOS boot floppy disk and even win98. There is really no need to take care of other third-party non-compliant programs. You can find a substitute to use, or wait for the software to be upgraded, correct the non-compliant problems, and then use it.
因为我们亲手创建,这个世界更加美丽。