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
