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.


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!
Freedos-kernel mailing list

Reply via email to