Testing FreeDOS beta5

Aitor performed a number of tests on the FreeDOS Beta5 (Lara) distribution, and here is what he found:

This will be the last time I try programs for a while. In the meantime, fill my mailbox of feedback requests if you want! (IBM PS/1).

Today's main characters:

  1. FREECOM 0.79d/beta
  2. CTMOUSE (of FreeDOS Beta 4)
  3. EURO (and KERNEL)
  4. (couldn't test REBOOT of my APMLib, as the PS/1 does not have APM-BIOS)

FREECOM 0.79d/beta

I am very glad to announce and confirm that my testing with this new version didn't give me any trouble. I did some CD, MD, DIR, COPY, REN, MOVE, VER, apparently both the HD and FD were read correctly, I could boot from both the FD and HD (just replaced the COMMAND.COM of both my 'rescue' disk and the HD root dir. I tried it again with other resident programs: xKeyb, Mouse.

Improvements noticed:

1) Now DIR/P seemed to show 'Press any key to continue'.

2) Perhaps the most impressive new feature has been te reduction in size. FreeCOM has passed from 84Kb to 77Kb, even if now it seems to include the strings correctly. This involves that there is more free room in the boot floppies and that booting process is faster.

I (personal opinion) would recommend updating the beta5 with this new FreeCOM, and probably the other suggestions I made.

Just one detail (perhaps I am wrong). The C:\DOS\BIN list is huge, so it gave me the opportunity to try the 'BREAK' command. Well, perhaps I am wrong, but I activated BREAK (BREAK ON), then tried to list the directory of C:\DOS\BIN, but I couldn't stop it with Control+C (later I tried DIR /P, and it worked, stopped before one of those questions). M$-COMMAND seems to stop if you press Control+C when listing a directory... (BY THE WAY: I have noticed that under Win9X this feature works horribly if you do DIR /S!!, please, avoid that mistake, and check Control+C often if someone does DIR /S!! This is rather frequent: you wish to stop after the first occurrence of the file you are looking for).


I tried this time CTMOUSE /W as I was suggested. This time the system didn't seem to have strange behaviour: it detected the mouse in PS/1 and got installed (probably, stayed resident). Unfortunately, I regret to say that it didn't work. I opened, for example, EDIT and HELP, and the mouse pointer was shown, but didn't move or react on my moving the mouse... I am open to new testings in October and onwards...

Aitor adds: This means no IRQ interrupt is really catched. Two suggestions: (1) try latest beta (CuteMouse 1.8 beta 8, http://www.vein.hu/~nagyd/) and (2) try to inspect by which interrupts handled (don't know if Manifest from QEMM can run under FreeDOS, I prefer it to see memory) - for COM1/COM3 must be catched INT C, for COM2/COM4 must be catched INT B.

Also try CTMOUSE under other DOS on this machine - probably there is hardware peculiarity, which prevents tested version of CTMOUSE from catch mouse events.


Unfortunately, my own program EURO, that worked fine under M$-systems, didn't work under FreeDOS. Fortunately, it can give us an interesting clue about the kernel and the MCB bug. What I obtained is a:

 Kernel panic.
 MCB chain corrupt

from the TSR part of the program (EUROTSR.EXE). I reproduce here the main() part of the program (in Pascal), that could give us the clue of what was wrong, and hopefully, help us locate the MCB bug. (part 1 missing is initialising local variables). To read it remember that:

 Ptr(seg,ofs) == MK_FP (seg, ofs)
 $nnn ==0xnnn

You would recoginze these from RBIL:

CTMOUSE didn't crash, and CUTEMOUSE would probably call SetIntVect, SetIntVect and Keep. So the problem will probably be in the call to deallocate the memory block of the data of the program. Perhaps the problem is in creating these blocks when executing a program, who knows...

A last question: Is NUMLOCK= (of CONFIG.SYS) implemented in the kernel?