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 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
