Re: [Freedos-kernel] FreeDOS kernel UPX'ing and versionning chaos
Most FreeDOS kernels released so far were UPX'ed and not un-UPX'able. The kernel almost-2040 included on 1.1test3 CD distro is NOT UPX'ed. Problem: with UPX'ed kernel, you can't check the version without booting the kernel. Suggestion: at the beginning or end of the file, add a string allowing to identify the kernel with compile date and other crucial info: K2040D2011-07-31C32F16B K2041D2011-08-31C16F28W C is CPU (16 aka 8086 or 32 AKA 80386) F is FAT (16 or 28) W and B are compilers (or is Boreland now dead ?). +1 Extend that CONFIG area at the beginning of the file, that's left uncompressed anyway. Providing the build and version information on an exclusive API for the currently running kernel would be useful too. Currently, there's a string with some 21.33Fx (.33FD ?) API, but that's just a string (difficult to parse; format changes happen), and then, 21.3000 returns the (low byte of the?) version number in cx or bx or somewhere, but that's unreliable because 21.30 is often intercepted and modified by version faking software. -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] FreeDOS kernel UPX'ing and versionning chaos
Hi Bernd, general question: How much do we want to know about a kernel without booting it? Because a lot of the information below is available AFTER booting the kernel, be it by human reading of the version description string (21.33xx) or by querying some int 21 functions to check FAT32 support or revision number. I agree that it would be good to have some thing visible in an easy to access area. Because we would probably use tools like SYS CONFIG to show it, the uncompressed CONFIG kernel data area is a nice place, but we do not have to use text. Instead of K 2040 D 2011-07-31 C 32 F 16 B or the shorter K 40 11-07-31 0 6 W, the encoded data could be for example byte:40 dosdateword:2011-07-31 and one byte-of-bits: FAT32 no, 386+ no, upx yes, cross-compile no, borland no, other reserved features no (actually I think only the first two feature flags are REALLY interesting at the moment). This encoding only needs FOUR bytes (1 byte, 1 word and some bits) to encode a machine readable binary form :-) We can offer a simple Perl script or similar for those who want to know which kernel binary they have but who cannot run SYS /SHOW-ME-THE-VERSION-OF X:SOMEKERNEL because SYS does not run in their operating system. I think we should not try to put a version string in the config area which would be visible in a text editor. All suggestions shown below use cryptic text anyway and they are even MEANT to be more machine- than human-readable. In short, I suggest a small, binary version encoding :-) Eric K2040D2011-07-31C32F16B K2041D2011-08-31C16F28W C is CPU (16 aka 8086 or 32 AKA 80386) F is FAT (16 or 28) W and B are compilers (or is Boreland now dead ?). ... In typical pre-Y2K-style I'd suggest: K4011073106W K -- kernel 40 -- kernel 2040 (to 2099) 11 -- year (to 99 so 2099) 07 -- month (01..12) 31 -- day (01..29/30/31) 0 -- 086+ (valid options [0,3] for 086+/386+) 6 -- FAT12/FAT16 (valid options [6,7] for filesystems that MSDOS 6/7 understand) W -- Watcom -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Kernel 2040 released
License evilness. Better to have the EDR DOS style hack for files above 4 GB file size than that. Than what that ??? Isn't it the same thing ??? I thought there was some discussion about exfat or whatever the MS thing for big files on embedded devices is, as that is not FAT in the DOS sense at all and highly proprietary... How about 64 kB? Heh ??? DOS can read or write full 64 KiB I was only talking about cluster sizes, not about the amount of data that you can read or write in a single int 21 call. The latter is indeed 65535 bytes, but I would prefer a multiple of the cluster size or 4096. Also, a cache can extend reads (read-ahead) or pool writes to larger chunks. Limits for that depend on the BIOS, e.g. 1 track or 127 sectors for floppy or older BIOSes but more when using LBA - at least the int 13.42 and 43 data block uses a WORD for number of to be read or written sectors, but I doubt that any BIOS would be happy to transfer 65535 sectors (almost 32 MB) in one call ;-) I think some hacks even support 128 kB I would highly nonrecommend hacks using 128 KiB clusters (maybe that's what you meant ?). Yes, and I agree. Even 64 kB clusters are a bit evil. Eric -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel