I have continued doing a lot of tests with FreeDOS, and testing some old DOS programs (including Win3.1!!) to see how it works. FreeDOS works rather well, I would say... I found these small failures, or I would like to make these comments.
Previous Notes:
Kernel:As my personal choice, I never like to have the Numlock ON at boot, so that's why I wanted to ask if NUMLOCK= is supported in CONFIG.SYS (I believe it is very easy to do, anyway).
KERNEL, memory, MEM and Windows3.1, WordStar and WordPerfect: I tried to install Windows 3.1... I thought everything was going to work ok: Windows has several running modes, and as the PC is not a 386, I thought it would run in real mode or standard mode (I can't remember which is the difference of these two). But the install crashed with:
PANIC: MCB chain corrupt System halted
I don't know if we still have notices of findfirst/findnext bug out there, but otherwise, I would suggest that this MCB chain corrupt is perhaps a good candidate for the bug of the month...
Recall that this is the cause of MEM not working, and as I can't see how much memory do I have, I don't know if WordStar is complaining correctly. It says: not enough memory. This program works with overlays, and I recall it needed a lot of memory, so it could be true.
James Tabor (kernel maintainer) writes: When a program uses Dos function 0x67, it works by allocating (if files=40) additional space for the JFT. etc etcOkay, yes MEM can not see the file table because FD doesn't use traditional memory allocation during the init phase. So, if you look at Dos MEM dump you'll see the data segment is one block. This segment is marked with the Dos MCB 'SD' (I think) and the "List of list", SDA, cds, nls and the rest, "Segment" pointers point to it.
A second possible bug in Kernel (perhaps this was commented, and I missed the result), that has to do with WordPerfect 5.1 for DOS. This processor never runs, and always complains: increase FILES= in the CONFIG.SYS. I have put FILES=40, which I believe it should be enough for any program in DOS, but it still does not work. Again, as MEM is not working, I can't see how much memory is the FILES (I suppose I can see used memory growing)
COMMAND: integrated DOSKEY is great! I have just a small comment: imagine I insert a floppy in A: with a directory (say PCTOOLS), and do the following sequence:
C:\>A: A:\>CD PCTOOLS A:\PCTOOLS>C: C:\>
Then I remove the disk and I insert a blank one, with only AUTOEXEC.BAT. Under FreeDOS:
C:\>DIR A: File not found
Under M$-DOS: whenever the A:'s dir doesn't exist, it seems to change to A\:, and says:
C:\>DIR A: Volume of A:\ AUTOEXEC.BAT 1 file(s) found
Perhaps is a good idea. I don't vote for anything... Do give your opinion yourself.
And a reply to last message from Steffen: so if COMMAND doesn't find the message file after installing beta5, did I do something wrong? do I have to modify the %PATH%? Nor the C:\> after install neither the full boot floppy seem to have any STRINGS.DAT...
Steffen Kaiser (maintainer of FreeCOM/command.com) writes: Well, the strings are searched the following order: 1) If the environment variable COMSPEC exists, in that file; 1.2) otherwise: If there was a first non-option argument when FreeCOM was invoked, in that file or, if this is a directory, in COMMAND.COM located there; 1.3) otherwise: in argv[0]. 2) In the file named STRINGS.DAT located in the same directory as described in 1), but, if an out-of-memory error occurs during above procedure, in the current directory.%COMSPEC% must not contain spurious whitespaces and must specify the filename portion, e.g.:
set comspec=c:\command.comits contents is fully used as filename.
PC-TOOLS 4.22: Strange behaviour: executed from a floppy, it works. Executed from an HD, it says: NO RESPONSE, and you have to cancel. I recall that I created my partition and then formated it with M$-DOS. But the C:\PCTOOLS folder was created with FreeDOS' MD.
What can this be? Findfirst/findnext? disk corruption somehow?
MOUSE and CuteMOUSE: Cutemouse still doesn't work, with same problem. However, M$-MOUSE works, and all the programs that use MOUSE work fine.
Alain writes: This could be because of UMB, try to use the /W switch so that it doesn't try to load high
MOVE: something strange happens with this. I had to move a file, and although it moved it (I could test it after booting), it never returned to the shell, so the system locked. The file was copied correctly, it was compressed and the uncompressor didn't complain.
XKEYB: I installed latest version of XKEYB with the SP.KEY file of the older version, and it worked. CapsLock didn't lock my PC... After I translate all the news of the newssite, I'll dig into xKEYB, and create a package with everything. Then I would like you to test this version to see if it locks with CapsLock, as Alain reported. However, I have noticed something not working: I can't put ortographic accents to letters (áàâä)... But appart from this, it worked fine for me...
EDIT: Oh, I like this editor very much. I found two small inconvenients: I clicked on the square topleft the screen (perhaps the control box for the main window), and it locked the PC...
Secondly, there are some keyboard layouts (e.g. Spanish) in which many keys have a third character, which is invoked in a combination of Alt-Gr (former right Alt) plus the key. But as this Alt seems to be trapped to activate the menus, it can't be used for these characters, so these characters can't be typed inside the editor. Note that the characters that can't be typed (as they are the 'third' character) are:
\ | @ # ¬ [ ] { }
note that some are quite important...
Other stuff: DELTREE, latest ARJ, BannerMania and Logitech Publisher worked fine.
HTML Help: A very small detail: if you run it after the install 'as is', you will come up with:
Error reading C:\DOS\BIN\HELP.HTM
The error can be solved by copying HELP.HTM in that path. Perhaps this should be done during the Install.
This was because I created the HTML Help package file incorrectly. My fault. -jh
By the way, is there a file having the list of commands, as it is in M$-DOS Help??
I think this was the file that I didn't include in the HTML Help package. -jh
DWIN: I got this error:
WTIE handled a graphics problem
and then RunTimeError 2, which I recall it is 'file not found'.
This appears to be because I missed a file when creating this package. I'll post a note to the errata. -jh
Well, that's all for now. Don't worry, I won't post messages like this very often, just from time to time, unless you consider these are very interesting messages.
My test environment is VMware 2 (MS-DOS optimization) using the floppy installation.
Just some summary before anything else:
After installation I ran some (not many) programs and I had to reboot fairly often; for not less than 40% this was caused by my own "not following to the rules", because I think very deeply that a computer has to work as the user expects and not the other way around. And how many percents VMware adds, I don't know.
So I will focus on to repair the memory issue of FreeCOM, in order to include more debugging-style stuff in it to allow to retreive certain information without the need to call another external program; sort of the administrator's shell I came across some day form Linux.
: (1) All the versions of all the programs used are those included within
: the FreeDOS Beta5.
As in my test(s).
: PANIC: MCB chain corrupt
: System halted
I never got this error, however, HELP worked exactly one time, then the whole system was in an unstable state, which usually required a reboot to fix it, but see below.
: And a reply to last message from Steffen: so if COMMAND doesn't find the
I haven't encountered this problem. I will address this issue in another, separate mail.
INSTALL: (Well, this was the command I was testing most actually :( )
1st question about the source directory A:\ >
where "A:\" is the current working directory, and
2nd question about the target directory C:\FDOS >
Or enclosed by brackets, e.g.: [A:\]
I guess that James Hall knows what went wrong, but I didn't at this time.
So I retried with no different result and I decided to install the packages of the UTIL1 disk manually, which failed, too, because there was no UNZIP installed by BASE1 nor is there any program I found to install a package manually. (INSTALL-wishlist)
My problem actually was that I had created a MINI boot disk, rather than a FULL one. When I tried to solve the problem by creating a new boot disk, INSTALL behaved differently than before and let me choose which optional disk sets I want to install.
INSTALL-wishlist: When a disk set is disabled, I think, it should not be displayed during the initialization of INSTALL or at least marked as "excluded" or something like that; the fact that INSTALL displayed the name of the disk set convinced me, that this set will be processed.
INSTALL-wishlist: A "Yes-to-all" when installing the individual components of a disk set. Maybe asked when INSTALL asks about if to include a set.
I don't remember if there was a note after INSTALL drops to the prompt, but I think the user should be adviced to add the BIN directory into the PATH. And if no AUTOEXEC.BAT exists, INSTALL should create one with the correct PATH, maybe PROMPT $p$g, too. ;-)
: HELP: A very small detail: if you run it after the install 'as is', you
: will come up with:
The HELP command did worked exactly one time, then the whole system was in an unstable state:
C:\ C:\FREEDOS C:\FREEDOS\BIN C:\FREEDOS\BIN\FILES
contained no files no longer (only directories). It seems these are the directories HTMLHELP (or the kernel) walks through to reach the files to be displayed. BTW the other directories were still filled. After reboot, the directories are "filled" again.
BTW: Where does the help texts come from?? The ASSIGN page, at least, does definitely not stem from the MAN page, because it states the command line options false and makes a false statement about its relation to SUBST, which are both correctly explained in the MAN page. Also, I don't understand its statement that "d" and "e" must be both valid hard disks. That's wrong at least when I interprete the sentence.
These were written by Joe Cosentino, and the Help program that Steffen is referring to is HTML Help. -jh
At this point I quit then and decided to move on with FreeCOM and put the debugging stuff in there, in order to peak around in the system without to trust the system it can find and execute the various tools necessary otherwise.