Hi Chris, Jeremy, > Commit 1705 renames a particular LoL field CPULevel and adds a comment > correctly claiming that MS-DOS sets this field to 1 on 386+ CPUs and to 0 > otherwise. The commit however makes the boot loader store the detected CPU > level (0, 1, 2, or 3) there instead. I don't think it's necessary to use > the field in an incompatible manner, and neither is the new 21.33
I totally agree. Reporting 386 versus older is more compatible and good enough. Only in rare cases when you want to know exactly, you would have to fall back to a tool such as CPULEVEL, but for a kernel flag, "32 bit CPU" is exact enough information :-) > subfunction that the commit adds, because no one uses it yet. Even so, You do not need an unused API function to read a rarely read field because the very few tools interested in the field can read LoL :-) > the subfunction does not require using that particular field to store > the detected CPU level. Even that... And by the way, I agree with Tom that flexible sector sizes are a bit shaky and the default compile should use 512 byte. However, a CONFIG.SYS option to modify the max sector size at boot would be a good compromise between hardcoding this at compile time and spending code and effort on automatic sizing at boot initdisk. Eric ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
