Menu
▾
▴
freedos-kernel
|
From: C. M. <cm...@bt...> - 2012-09-27 04:11:27
|
> I'll link to the 1.0 boot floppy image, under the "FreeDOS 1.0" section. > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdboot.img Kernel on that image uses 386+ instructions... and it seems as if it does that without (properly) checking for the presence of a 386. That it's a 386+ kernel is just an oversight (or should be documented for the image), but if 386+ kernels really do not abort with an appropriate message on non-386 CPUs, that's a bug. Does a kernel developer know whether such checks are... just kidding, I examined the sources myself. In kernel.asm such a check does not exist or (in recent builds and SVN revisions) it exists but isn't used to orderly abort loading if the CPU isn't supported. It then jumps to _FreeDOSmain, which is the C function FreeDOSmain in main.c. In the kernel on that disk image, the very first instruction happens to be "push fs", code 0Fh 0Ah, which on pre-386 CPUs is an error (or at least not "push fs"). The file kernel.asm (SVN r1705) is this one: http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/kernel/kernel.asm?revision=1705&view=markup Note lines 194 to 196, where precisely in this latest r1705, Kenneth added the comment "TODO display error if built for 386 running on 8086 etc". I can prepare a patch to implement this (I'd think entirely in kernel.asm) if the kernel developers are interested. Regards, Chris |
|
From: Eric A. <e....@jp...> - 2012-09-27 07:40:10
|
Hi Chris, >> I'll link to the 1.0 boot floppy image, under the "FreeDOS 1.0" section. >> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdboot.img That is a bit old so I am still preferring Ruffidea ;-) Also because it is easier to delete than to add stuff, for the latter you have to download things first. On the other hand, I think Jeremy once had some sort of automated builds with always fresh kernels online? For people like Georg who need just a minimal bootable DOS this would be a good source of boot floppy images. > Kernel on that image uses 386+ instructions... and it seems as if it > does that without (properly) checking for the presence of a 386. That is correct, as a kernel cannot be both optimized for 386 and compatible with 8086 at the same time. We had some specifically PC-XT compatible boot floppies mentioned on the list in the past, e.g. by somebody who made a virtual PC-XT in Java if I remember right? > That it's a 386+ kernel is just an oversight (or should be documented for > the image), but if 386+ kernels really do not abort with an appropriate > message on non-386 CPUs, that's a bug. I disagree here. Without a kernel, you cannot do any useful DOS stuff. However, I once made some tools for Bernd to have a boot disk which automatically picks boot files depending on your available CPU, as far as I remember also related to MEMDISK detection? You CAN make a NON minimal boot disk which automatically can fall back to 8086 that way. However it is VERY rare to find pre-386 hardware today, so I would really say that it is better to have separate downloads: Normal boot floppy for 386+ and special 8086 compatible boot floppy for people with really ancient hardware (or a virtual ancient computer, as the one mentioned above). Of course it is a different story for EMM386, HIMEM, USB drivers and similar: THOSE can automatically say that they cannot load on incompatible hardware, then return to DOS. Users can still use DOS then and sure it is nice to not crash on old hardware but show some message. But a kernel? It cannot skip itself and jump to a command prompt with only the 8086 part loaded ;-) > The file kernel.asm (SVN r1705) is this one: > http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/kernel/kernel.asm?revision=1705&view=markup > > Note lines 194 to 196, where precisely in this latest r1705, Kenneth added > the comment "TODO display error if built for 386 running on 8086 etc". Well if it really makes you happy... Note that also a number of boot loaders only work with 386 anyway now. Regards, Eric |
|
From: C. M. <cm...@bt...> - 2012-09-27 10:17:50
|
Hi Eric, >> Kernel on that image uses 386+ instructions... and it seems as if it >> does that without (properly) checking for the presence of a 386. > > That is correct, as a kernel cannot be both optimized > for 386 and compatible with 8086 at the same time. Well, yes it could (look at FreeDOS DEBUG/X's sources for table-based load-time patch method), but that's not the point. The point is that software requiring a particular instruction set should usually check whether that's available (before using it), and more or less gracefully abort if not. The kernel itself has no reason to not show a little more grace here, especially now that the _check_ for 386+ is already implemented, just the conditional branch out and showing an error message then rebooting not yet. >> but if 386+ kernels really do not abort with an appropriate >> message on non-386 CPUs, that's a bug. > THOSE can automatically say > that they cannot load on incompatible hardware, then > return to DOS. Users can still use DOS then and sure > it is nice to not crash on old hardware but show some > message. But a kernel? It cannot skip itself and jump > to a command prompt with only the 8086 part loaded ;-) Yes it could sort of, which is again not the point. Just look at the boot sector loaders, maybe their earlier revisions though (with as far as I remember more descriptive error messages). Nothing prevents the 386+ kernel from appropriately branching out, displaying "This is a 386+ build of the FreeDOS kernel, please obtain a different one for this non-386 CPU. Press any key to reboot." (using Int10.0E like all other messages from the loaders), then calling Int16.00 and Int19. >> Note lines 194 to 196, where precisely in this latest r1705, Kenneth >> added >> the comment "TODO display error if built for 386 running on 8086 etc". > > Well if it really makes you happy... Well, "if it makes you happy" (not really the topic what would make whom happy?), you can of course refrain from writing the code necessary for that or alternatively asking for a patch. > Note that also a > number of boot loaders only work with 386 anyway now. Including at least some MS-DOS 7+ boot loaders, and FreeDOS's current FAT32 FS boot sector loaders, thankyou I'm aware. That's still no reason to hold onto this user-unfriendly behaviour everywhere. (The FAT32 FS boot sector loader has a restriction as designed which makes it at least somewhat sensible to not emit a nice diagnostic on failure. This is not true of the kernel at the stage we're examining.) And yeah, I do think it could genuinely put a user off. Imagine someone gets that image, maybe extracts the files to put them onto a smaller format floppy. Loading an actual machine with that, or emulated, regardless. This image specifically described as "Great for booting FreeDOS on old PCs" on the website right now. And the kernel just crashes. What if that person is unable/unwilling to step through the kernel's early load phase (including UPX decompression) to figure out what caused the crash? Maybe they'll ask on the list for help with a mysterious crash, but I wouldn't guess it'd make a particularly good (first) impression. And it's so easily avoidable. So many words. What a waste. I should condense more next time. Regards, Chris |
Thanks for helping keep SourceForge clean.
X