419 breaks DOS memory manager XMGR

[Paul]

XMGR is an open source DOS XMS memory manager. It's is the most actively developed of its kind.

Unetbootin 408 works fine with it. 419 freezes when XMGR is invoked. I have also tried 429 and it has the same problem.

XMGR home page: http://johnson.tmfc.net/dos/driver.html
Direct download: http://johnson.tmfc.net/dos/file/drivers.zip

Example boot floppy that uses XMGR: http://superkeen.com/peacecorpsweblog/learning-software/
Direct download: http://superkeen.com/peacecorpsfiles/FUZOMA14.IMG

[Geza Kovacs (gezakovacs)]

What OS are you running UNetbootin on? Also, what stage does it freeze on?

[Paul (dummy)]

Unetbootin is running on Windows Vista.

The freeze occurs just as XMGR loads during DOS boot.

I have also observed another problem introduced by 419. The IBM PC-DOS 7.10 RAMDisk utility crashes the FreeDOS kernel where previously in 408 it did not.

Presumably these are related problems, as they both involve low-level memory handling.

Example boot disk: http://superkeen.com/peacecorpsfiles/FUZOMA12.IMG

[Geza Kovacs (gezakovacs)]

The issue appears to be a regression in memdisk (the part of syslinux which handles the floppy disk image loading); the regression seems to have occurred between versions 3.72 (the one bundled in UNetbootin 408) and version 3.73. I've reported the issue to the upstream syslinux mailing list.

[Geza Kovacs (gezakovacs)]

I reported the memdisk bug to the mailing list at http://syslinux.zytor.com/archives/2010-April/014091.html

[Paul (dummy)]

So it seems like the problem is that MEMDISK has changed their default memory handling routine, and since Unetbootin uses those defaults, DOS boot floppies are now having a problem.

It would seem that there are two options:

1) Get them to change the default back to what it was and/or fix the current mode so it works better.

On that front, for what it's worth, I tried booting previous versions of my floppy disk and NONE of them work with Unetbootin (I tried 442 also, BTW). This is interesting because these disks use completely different memory managers and ramdisk TSRs, yet NONE of them make it all the way through the boot process. The only thing they have in common is that they all have FreeDOS kernels, but they are also different versions, and even different boot sectors!

Jack Ellis, the author of the XMGR memory manager, also points out that it is likely FreeDOS itself that has the incompatibility, since the FreeDOS kernel successfully displays a message AFTER the memory manager finished loading: http://www.bttr-software.de/forum/forum_entry.php?id=7854

Here are links to the various disk images and a short summary of their memory manager, ramdisk drivers, and image sizes. As you can see, it's quite a combination and yet NONE of them work.

http://superkeen.com/peacecorpsfiles/PB-LearningA10.img (HIMEM64/XMSDSK/1440)
http://superkeen.com/peacecorpsfiles/PB-LearningA11.img (FDXMS/XMSDSK/1440)
http://superkeen.com/peacecorpsfiles/FUZOMA12.IMG (FDXMS/PC-DOS 7.1 RAMDRIVE/1680)
http://superkeen.com/peacecorpsfiles/FUZOMA13.IMG (FDXMS/RDISK/1680)
http://superkeen.com/peacecorpsfiles/FUZOMA14.IMG (XMGR/RDISK/1680)

(I am testing on my laptop, a Toshiba A605-201.)

So maybe this information will help the MEMDISK team change their minds about this default and/or fix the new implementation.

The other option, though, is:

2) Unetbootin can override the MEMDISK defaults so things will work just like before. Perhaps this would make an easy solution while pushing ahead with option 1.