win31 hangs on reboot after install

[stsp]

Installation completes successfully but when it asks to reboot win31, it doesn't boot up.

[stsp]

Hi @tkchia, do you know why _TEXT_DGROUP is needed? Can I use DGROUP everywhere instead?

[stsp]

Hi @bartoldeman why _TEXT_DGROUP is needed? Can I use DGROUP everywhere instead? I want to remove or reduce the usages of _LOWTEXT as it is not too low in fdpp.

[stsp]

I removed _TEXT_DGROUP. Wonder if that is correct or not.

[bartoldeman]

It's correct. It's only there to avoid relocations, there was a change back in 2003 where we avoided relocations with changes like this:

-    mov ax,DGROUP
-    mov ds,ax    
-    extern   _int2F_12_handler:wrt TGROUP
+    mov ds,[cs:_DGROUP_]
+    extern   _int2F_12_handler

but if I remember well this was mostly done so we could easily identify wrong relocations in exeflat.exe. It would work either way.

[stsp]

Thanks for an info! Could you please help me check the remaining 3 uses of _LOWTEXT in #187 ? The main question is: are they in _LOWTEXT because no one wrote the relocation entry for HMATEXT, or because they should be in 0x70 space? Since we no longer load on 0x60, I need to identify all spots of 0x70 space, and _LOWTEXT is the primary suspect.

[bartoldeman]

yes, for console.asm, and procsupt.asm we never bothered to move them to HMA because they take a tiny amount of memory (unlike blk_driver and clk_driver which are in C) the floppy table can't be easily relocated, but I guess you can handle it like the int vector table at 70:100.

[stsp]

I am confused about the floppy table. First, at what address in 0x70 should that be? You say its not easily relocated, which means its address is documented - where? And second, why freedos re-creates it if it is already in bios.s and is pointed to by 0x1e? Will it help if I completely remove it from fdpp and use vector 0x1e to locate in bios instead? I think there was a bug in dosemu-1.x where int 1e was not set pointing to a table. Was freedos working around that one?

[bartoldeman]

No, nothing to do with DOSEMU, according to history.txt one change (from 2002) is a workaround against some XT BIOSes which have less than 9 sectors per track in the BIOS table.

The other works around a bug in memdisk, that was fixed in 2012: https://github.com/joyent/syslinux/commit/7307d60063ee4303da4de45f9d984fdc8df92146

So I think you can just leave INT1E as is with fdpp, and delete all that code.

[stsp]

OK, done just that, thanks. Incidentally fdpp already had problem with that code, so it looked like this:

  /* quick adjustment of diskette parameter table */
//  fmemcpy(int1e_table, *(char FAR * FAR *)MK_FP(0, 0x1e*4), INT1E_TABLE_SIZE);
  /* FDPP: wrong parse of the above */
  fmemcpy(int1e_table,  *(__FAR(__DOSFAR(char)))MK_FP(0, 0x1e*4), INT1E_TABLE_SIZE);

Obviously my parser did something wrong with double-far.