Re: [Freedos-kernel] Commit 1705
Op 19-2-2012 20:10, Eric Auer schreef: > For the VERY exotic case that you have a bootdisk which > boots from memdisk on 386 and without on older 386, if > you can still find any... And the exotic case where the > two styles of booting still share the same config sys? I'm still aiming at a unified installation bootdisk. And yes, I agree ODIN is usually a far better idea for pre-386 systems. [ http://www.reactos.org/bugzilla/attachment.cgi?id=7374 ] is a simplified version of a bootdisk containing Syslinux/Memdisk (and your CPUBOOT program could protect pre-386 systems). > then they can just boot ANYTHING from another portable > boot drive and whether they can mess up how your DOS > portable boot drive acts is a relatively small worry. Yes. Actually I'm currently having trouble using this memdisk-args stuff, might be lack of a menu system used in my config.sys. Seeing some memdisk-related output (the version) so assume it's compiled into the kernel by default. > I do not understand... Anyway, here is what RayeR says: Working on stuff in quiet periods and then having it sit around until being able to find time again before releasing, is a waste. Bernd -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Commit 1705
Hi Bernd, >> (untested, just "history.txt" __IS__ updated this time) >> >> but nobody annouced it :-D Yes, why?? I forward a message from RayeR in the forum below. > It's a secret to everybody! > (hm, too much Zelda) > > The pre-386/memdisk detection is a good thing, finally a unified kernel. For the VERY exotic case that you have a bootdisk which boots from memdisk on 386 and without on older 386, if you can still find any... And the exotic case where the two styles of booting still share the same config sys? > Right until someone does a "append FD={INSTALL=FORMAT C: /Z:SERIOUSLY}" You might want to use a login to protect advanced boot menu options. However, if people can boot DOS from a memdisk - I assume this is NOT now they boot from C:! then they can just boot ANYTHING from another portable boot drive and whether they can mess up how your DOS portable boot drive acts is a relatively small worry. > Having 2041 out when maintainers had time for it relieves them from > pressure for implementing stuff and releasing new versions. I do not understand... Anyway, here is what RayeR says: > posted by RayeR(R) Homepage, CZ, 19.02.2012, 17:39 > > Thx for notification. Let's see what's new: > > 2012 Feb 07 - Build 2041 > Jeremy Davis > > + Changes Jeremy > * r1637 fix out of range byte in country.asm > * r1685 add int 2f subfunc 122B and 122D from Eduardo Casino > * r1697 from Pete Batard, do not display CHS mismatch warning > during booting when forcing LBA mode option set > * r1702 improve handling for sectors not 512 bytes in size > (up to 2048 bytes, larger sizes not yet working) > * r1705 add cpu detection so memdisk args supported in 8086 build > > Seems like minor changes except the support for 2048 sectors? > Where is it used? I know that CDROM use 2kB sectores but it was > handled by driver for a long time. I also read that some new HDDs > have 4kB sectors but AFAIK they still emulate 512B sectors for system. > > --- > DOS gives me freedom to unlimited HW access. -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Commit 1705
Op 19-2-2012 10:57, dos386 schreef: > (untested, just "history.txt" __IS__ updated this time) > > but nobody annouced it :-D It's a secret to everybody! (hm, too much Zelda) The pre-386/memdisk detection is a good thing, finally a unified kernel. Right until someone does a "append FD={INSTALL=FORMAT C: /Z:SERIOUSLY}" Having 2041 out when maintainers had time for it relieves them from pressure for implementing stuff and releasing new versions. Bernd -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Commit 1705
Kernel 2041 seems to be out: http://sourceforge.net/projects/freedos/files/Kernel/2041/ (untested, just "history.txt" __IS__ updated this time) but nobody annouced it :-D -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Commit 1705
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
[Freedos-kernel] Commit 1705
Hi, 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 subfunction that the commit adds, because no one uses it yet. Even so, the subfunction does not require using that particular field to store the detected CPU level. Regards, C. Masloch -- 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