Re: [Freedos-kernel] Re: 2F-122F
Hi! 13--2004 04:19 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA how to use it that way ;-). In addition, the MS-ish interface allows EA revert to real version number by passing a value of zero. The extra RBIL doesn't says this. EA few bytes are really VERY few bytes and they should be in HMA anyway. EA By having a set reported version number function in the kernel, EA programs like CALLVER / SETVER do not have to hook int 21 themselves and You already have INT21/33FC. Why to introduce _another_ FreeDOS specific function (which not present neither in MS-DOS 5-8, DR-DOS, ROM-DOS, etc)? PS: BTW, Eric, may you recall URL for your CALLVER? Unfortunately, I lost it, but it was need me sometime (because I need to run, say, MS-SYS6 under MS-DOS7). EA (SETVER is quite complex and changes the version number dynamically, It requres changes in config.sys, and it changes itself. :( --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 12--2004 14:30 [EMAIL PROTECTED] (tom ehlert) wrote to Luchezar Georgiev [EMAIL PROTECTED]: Only 0 and 80 are used by MS-DOS. All other values are FreeDOS extensions ;-) te are you SURE ? How strange. B-\ I receive this letter two minutes back, whereas I answer yesterday to Lucho's letter, where was answer to this letter. Somewhere works time machine? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hi! 12--2004 14:28 [EMAIL PROTECTED] (tom ehlert) wrote to Luchezar Georgiev [EMAIL PROTECTED]: and removes (parts? of) tom's patch. As you wrote youself, it's better to have the whole patch than parts of it. And even better is to solve entirely the problem which this kludge solves partially. But we don't know the problem :-( te at least I know the problem - and described it when publishing the patch. tom, please, publish _diff-file_ with your patch, and I think, no one will complain to include your patch. Previously you publish only plain text with quotes. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel asmsupt.asm,1.23,1.24 entry.asm,1.27,1.28 fatfs.c,1.70,1.71
On Sun, 12 Sep 2004, Kenneth Davis wrote: merge in some changes from UNSTABLE I wonder about those creation time set removals. It looks like your removing a useful feature here. Sure a reason given is MSDOS 7.10 doesn't do this. Well, I say, who cares about this specific DOS, many other OS'es *do* set the creation time. Did it hurt that FreeDOS did this? Maybe it should be a config.sys option if it did hurt in certain (documented) circumstances. batch files no change just line ending issue which is pretty annoying if you check out on Linux -- I'll really have to push a patch to Steffen to allow FreeCOM not to choke on LF-ended batch files... Bart --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 2F-122F
In addition, the MS-ish interface allows revert to real version number by passing a value of zero. RBIL doesn't says this. It does say this. D-2F122F says: DX = DOS version number (h = return true DOS version). RBIL also says this is supported by Matthias Paul's FREEVER.COM. Do you see now why I won't remove it? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Although I dislike the idea of patching the bootsector, choice 2 does seem most compatible and is slightly smaller boot code (as the logic is moved to sys). I agree and prefer method 2 too. The distance between this new patched boot sector offset and the existing boot segment offset seems constant for all boot sectors, so patch location IS uniform ;-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Tom's patch dated 5 July
Hello Luchezar, Do you mean http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html yes (It doesn't contain other comments but those in the patch.) If you confirm, I can apply it. yes. it happens if a int24 handler returns to itself directly, instead of the 'normal' way to return to DOS with some error code. But an Int 24h handler returns with an IRET, so to return to itself means that it's re-entrant! has nothing to do with reentrancy. a) program installs it's own int24handler. b) critical error happens, int24() gets called. *usually* this sets carry flag etc. and returns to DOS (and DOS gets a chance to free_fnode() etc.) in the observed case (which probably came from some Turbo Pascal library, floating in the net), the program instead pops all (DOS saved) registers from stack, sets some magic flag in the application, and returns immediately to the user adress on the stack - no chance for DOS to reset errorlevel, no chance to free_fnode(). tom --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Creation times
Hallo Bart, merge in some changes from UNSTABLE If Bart doesn't like some changes, I don't mind if they're not merged them into stable ;-) I wonder about those creation time set removals. It looks like your removing a useful feature here. Sure a reason given is MSDOS 7.10 doesn't do this. Well, I say, who cares about this specific DOS, Isn't *this* specific OS what we try to emulate as closely as possible (including even its bugs)? many other OS'es *do* set the creation time. Did it hurt that FreeDOS did this? It didn't actually do that. FreeDOS did *always* set the creation time *equal* to the write time. So the creation time didn't hold even a single of bit of information and was therefore misleading. Making it set the creation time *only* once, when a file is created, is surprisingly difficult (I tried and failed), and is not required for a DOS anyway. Let's not try to be bigger catholics than the pope. Maybe it should be a config.sys option if it did hurt in certain (documented) circumstances. Too complex. I like the KISS principle (Keep It Simple, Stupid = KISS :) which is pretty annoying if you check out on Linux -- I'll really have to push a patch to Steffen to allow FreeCOM not to choke on LF-ended batch files... Now when AUTOEXEC.BAT is just one line ending with LF, not CRLF, FreeCOM happily processes it ;-) Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
Eduardo, couldn't we divide the work between ourselves? If you do the changes in nls_hc.asm for the third option you offered (make enough room), I will add the necessary code in config.c ;-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Tom's patch dated 5 July applied in its full glory :)
Do you mean http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html yes (It doesn't contain other comments but those in the patch.) If you confirm, I can apply it. yes. Just applied and committed (and updated binary on my site ;-) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hello, Award BIOS dated 1999 for Intel i810, and the original IBM PC/AT BIOS don't seem to pass anything in DL on Int 19h. How did I verify it? For those who can't guess, let this be my little secret ;-G (Table 00653) Values Bootstrap loader is called with (IBM BIOS): CS:IP = h:7C00h DH = access bits 7-6,4-0: don't care bit 5: =0 device supported by INT 13 DL = boot drive 00h first floppy 80h first hard disk The above excerpt from the RBIL also proves that not all BIOSes pass boot drive in DL on Int 19h, and even if they do (e.g. IBM BIOS), they pass *only* 0 or 80h. Period. (And end of FF kludge ;-) Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 2F-122F
Hi! 13--2004 12:04 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: In addition, the MS-ish interface allows revert to real version number by passing a value of zero. RBIL doesn't says this. LG It does say this. D-2F122F says: DX = DOS version number (h = return LG true DOS version). Hm, I miss this. Anyway, return is ambiguous in this context. :) LG RBIL also says this is supported by Matthias Paul's LG FREEVER.COM. Do you see now why I won't remove it? No, I don't see. _If_ freever.com supports only this function, then it useless in (all other versions of) MS-DOS. Why it should be useful in FreeDOS (especially because we have Eric's CALLVER, which (may) use INT21/33FC)? I don't think, that Matthias as author of FREEVER doesn't makes this interrupt more important for FreeDOS. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: [Freedos-cvs] kernel/kernel inthndlr.c,1.87.2.5,1.87.2.6
Hi! 13--2004 12:09 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG +++ inthndlr.c 13 Sep 2004 12:09:37 - 1.87.2.6 LG + if (fnode[0].f_count != 0 || LG + fnode[1].f_count != 0 ) if (fnode[0].f_count | fnode[1].f_count) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
The BIOS Boot specification warns that only 0 and 80h can be [...] [...] interesting enough... Nevertheless, trying it gives me 404... Moved - http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdf --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 13--2004 12:48 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: My AwardBIOS here for example does have such a feature. However, when I look at the boot record of my second hard drive, I see again boot drive = 80. Do you try to boot from second drive with this boot record (which contains 80h)? And it boots fine (without accessing first disk)? LG Yes, of course. So, BIOS probably swaps LG Not probably - surely. Ie., second disk was enumerated as 80h (and, for example, partitions from it was labeled earlier, than from first disk)? Probably?! In this case it not need to pass to boot code information about boot drive! LG The BIOS Boot specification LG (http://www.phoenix.com/resources/specs-bbs101.pdf) warns that only 0 and LG 80h can be safely considered as boot devices, albeit it recommends (but LG doesn't require) that BIOS passes boot device in DL on Int 19h. The 0/80h LG limitation warn != limitation. This warning may be only because authors of tose spec may know about existance of buggy BIOSes. LG is due to the MS-DOS boot sectors, of course. So, whatever we LG decide, we should remove the FF kludge in any case. I already expressed my LG opinion - I agree with Jeremy and Eric that choice (2) is better for LG compatibility reasons. No, not better. For example: if you use boot manager, which supports loading boot record from second disk, then (your) boot code will not work in such configurations, if it will contain 80h. And vice versa: let suggest, that BIOS swaps disks numbers. In this cases you can't boot (your) boot record, if it will contain 81h. Will? Do you mean, that currend FD boot record (with FFh mask) doesn't work when loading FD from second disk?! LG It works until replaced by another boot sector that tries to boot off LG drive FF. ?! Lucho, please, reread your sentence! We don't discuss _some_ _buggy_ boot code, which by some strange reason uses FFh as boot drive # (how this relates to FD boot code?), we discuss, should _FD boot code_ expect drive# from BIOS or use fixed values. Hm. Or you mean, that _some_ (non-FD!) SYS, which writes own boot sector, by some strange/buggy reason will preserve FD's boot record _field_ drive number (offset 0x24) and then its boot code will reuse this field? How this alien buggy SYS relates to our boot code and dependence from BIOS info? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
El lun, 13-09-2004 a las 12:36, Luchezar Georgiev escribió: Eduardo, couldn't we divide the work between ourselves? If you do the changes in nls_hc.asm for the third option you offered (make enough room), I will add the necessary code in config.c ;-) Hi Lucho, I don't mind adding the changes to nls_hc.asm, but I'm not sure that I like that option. In a private mail, Eric suggested a fourth option: Check if there is enough room for loading the package and, if not, allocate extra memory only for the additional tables. This will keep the kernel size unchanged and optimze the memory useage, as only a percentage of NLS packages are bigger than the default. I've been thinking about how to implement this, and I've come up with this: We could insert a null pointer for subfunction 0 just before subfunction 1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as subfunction 0 does not exist (example patch below). This will add just 5 bytes to the tables and can be used as a placeholder for subfunction 3 (LCASE). This maintains all the pointers into predictable indexes and prevents moving the CTYINFO table when loading a package with LCASE. When loading a package from COUNTRY.SYS, we should do something like the following pseudocode before actually reading the data: extra_memory = 0; if (LCASE_is_present) extra_memory += 258; /* sizeof(WORD) + actual length */ if (UCASE_offset != FUCASE_offset) extra_memory += 130; if (DBCS_length != 0) extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */ allocate(extra_memory); And then, read the info overwriting the harcoded tables for UCASE, FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.) Comments? Eduardo. --- unstable/kernel/kernel/nls_hc.asm 2002-12-09 01:17:14.0 +0100 +++ unstable.new/kernel/kernel/nls_hc.asm 2004-09-13 16:29:08.831007552 +0200 @@ -12,7 +12,7 @@ GLOBAL _nlsPackageHardcoded _nlsPackageHardcoded: DB 000h, 000h, 000h, 000h, 001h, 000h, 0b5h, 001h - DB 00fh, 000h, 059h, 000h, 04eh, 000h, 006h, 000h + DB 00fh, 000h, 059h, 000h, 04eh, 000h, 007h, 000h DB 002h DW ?table2, SEG ?table2 DB 004h @@ -23,6 +23,8 @@ DW ?table6, SEG ?table6 DB 007h DW ?table7, SEG ?table7 + DB 000h + DW 000h , 000h ; Placeholder for table3 (LCASE) GLOBAL _nlsCountryInfoHardcoded _nlsCountryInfoHardcoded: DB 001h --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Ie., second disk was enumerated as 80h (and, for example, partitions from it was labeled earlier, than from first disk)? Yes, exactly. This warning may be only because authors of tose spec may know about existance of buggy BIOSes. No, they state several times that ONLY 0 AND 80 may be boot drives. No, not better. For example: if you use boot manager, which supports loading boot record from second disk, then (your) boot code will not work in such configurations, if it will contain 80h. And vice versa: let suggest, that BIOS swaps disks numbers. In this cases you can't boot (your) boot record, if it will contain 81h. For this, an option of SYS will revert back to DL = boot drive Hm. Or you mean, that _some_ (non-FD!) SYS, which writes own boot sector, by some strange/buggy reason will preserve FD's boot record _field_ drive number (offset 0x24) and then its boot code will reuse this field? Yes. How this alien buggy SYS relates to our boot code and dependence from BIOS info? I already explained. If it overwrites our boot sector, it won't boot. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
Hola Eduardo, I don't mind adding the changes to nls_hc.asm, but I'm not sure that I like that option. Neither do I like it very much, but (1) and (3) are most straightforward and easiest to implement. In a private mail, Eric suggested a fourth option: Check if there is enough room for loading the package and, if not, allocate extra memory only for the additional tables. This will keep the kernel size unchanged and optimze the memory useage, as only a percentage of NLS packages are bigger than the default. The problem is that the already statically allocated memory for hard-coded tables will be lost. I've been thinking about how to implement this, and I've come up with this: We could insert a null pointer for subfunction 0 just before subfunction 1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as subfunction 0 does not exist (example patch below). This will add just 5 bytes to the tables and can be used as a placeholder for subfunction 3 (LCASE). This maintains all the pointers into predictable indexes and prevents moving the CTYINFO table when loading a package with LCASE. When loading a package from COUNTRY.SYS, we should do something like the following pseudocode before actually reading the data: extra_memory = 0; if (LCASE_is_present) extra_memory += 258; /* sizeof(WORD) + actual length */ if (UCASE_offset != FUCASE_offset) extra_memory += 130; if (DBCS_length != 0) extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */ allocate(extra_memory); And then, read the info overwriting the harcoded tables for UCASE, FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.) But we will have a common memory for all the information and could not distinguish between the beginnings of the different structures. It's better to allocate memory separately for each one. I still think that half a kilobyte isn't a big price to pay, PROVIDED THAT SOMEONE WILL REALLY USE THE DOUBLE-BYTE TABLES. As far as I know, there are complete Chinese, Korean and Japanese packages that install their own font, NLS and keyboard support, and most people will use them and not our inferior but much more difficult to set up COUNTRY + NLSFUNC + DISPLAY + KEYBOARD + whatever :-/ If nobody will use them, then your option (1) is the one to implement. Chinese, Japanese and Korean friends, please express your opinion now. Last not least, we don't have these tables yet, and may not have them. Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 13--2004 19:55 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: This warning may be only because authors of tose spec may know about existance of buggy BIOSes. LG No, they state several times that ONLY 0 AND 80 may be boot drives. Ok. What about boot managers? No, not better. For example: if you use boot manager, which supports LG For this, an option of SYS will revert back to DL = boot drive Hm. Your arguments sounds reasonable. But I continue to _feel_, that using BIOS info instead fixed value is better (except buggy BIOSes, which pass wrong drive#). Hm. Or you mean, that _some_ (non-FD!) SYS, which writes own boot sector, by some strange/buggy reason will preserve FD's boot record _field_ drive number (offset 0x24) and then its boot code will reuse this field? LG Yes. How this alien buggy SYS relates to our boot code and dependence from BIOS info? LG I already explained. If it overwrites our boot sector, it won't boot. You _suggest_, that _some_ SYS (may) remain untouched 24h field when it overwrite boot sector _and_ its boot code reuse this value? Or you know such _known and usable_ SYS with such (strange!) behavior? If first, then we shouldn't worry about this; if second, then, probably, we should force bugfixing of those SYS. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
El lun, 13-09-2004 a las 19:19, Luchezar Georgiev escribió: In a private mail, Eric suggested a fourth option: Check if there is enough room for loading the package and, if not, allocate extra memory only for the additional tables. This will keep the kernel size unchanged and optimze the memory useage, as only a percentage of NLS packages are bigger than the default. The problem is that the already statically allocated memory for hard-coded tables will be lost. Not really. In the worst case, only the 4 bytes for the empty DBCS table will be unused. The idea is to overwrite the hardcoded tables for CTYINFO, UCASE, FCHAR, and COLLATE and allocate new memory (if needed) for FUCASE, LCASE and DBCS _only_. I've been thinking about how to implement this, and I've come up with this: We could insert a null pointer for subfunction 0 just before subfunction 1 (CTYINFO) into nls_hc.asm, which will be ignored by NLS functions as subfunction 0 does not exist (example patch below). This will add just 5 bytes to the tables and can be used as a placeholder for subfunction 3 (LCASE). This maintains all the pointers into predictable indexes and prevents moving the CTYINFO table when loading a package with LCASE. When loading a package from COUNTRY.SYS, we should do something like the following pseudocode before actually reading the data: extra_memory = 0; if (LCASE_is_present) extra_memory += 258; /* sizeof(WORD) + actual length */ if (UCASE_offset != FUCASE_offset) extra_memory += 130; if (DBCS_length != 0) extra_memory += 2 + DBCS_length; /* sizeof(WORD) + actual_length */ allocate(extra_memory); And then, read the info overwriting the harcoded tables for UCASE, FCHAR, CTYINFO, YESNO and COLLATE and into the allocated memory for LCASE, FUCASE (if different than UCASE) and DBCS (if non-empty.) But we will have a common memory for all the information and could not distinguish between the beginnings of the different structures. It's better to allocate memory separately for each one. I don't see the point. You have the array of nlsPointer structures, which tells you where the tables are for each subfunction. If you have a look at nls_hc.asm, maybe it will be clearer. I still think that half a kilobyte isn't a big price to pay, PROVIDED THAT SOMEONE WILL REALLY USE THE DOUBLE-BYTE TABLES. As far as I know, there are complete Chinese, Korean and Japanese packages that install their own font, NLS and keyboard support, and most people will use them and not our inferior but much more difficult to set up COUNTRY + NLSFUNC + DISPLAY + KEYBOARD + whatever :-/ If nobody will use them, then your option (1) is the one to implement. Not only DBCS. Also LCASE (for Russian) or FUCASE, for other languages. But yes, it is only a percentage. Chinese, Japanese and Korean friends, please express your opinion now. Last not least, we don't have these tables yet, and may not have them. Regards, Lucho Regards, Eduardo. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot drive incompatibility with other boot sectors
No, they state several times that ONLY 0 AND 80 may be boot drives. Ok. What about boot managers? The option mentioned below is for boot managers too. For this, an option of SYS will revert back to DL = boot drive Hm. Your arguments sounds reasonable. But I continue to _feel_, that using BIOS info instead fixed value is better (except buggy BIOSes, which pass wrong drive#). Did you read my other message about these BIOSes? I repeat it below. You _suggest_, that _some_ SYS (may) remain untouched 24h field when it overwrite boot sector _and_ its boot code reuse this value? Or you know such _known and usable_ SYS with such (strange!) behavior? If first, then we shouldn't worry about this; if second, then, probably, we should force bugfixing of those SYS. It's like waiting a letter from a dead person, as we say here ;-) Let me repeat my other message, because it seems that it vanished. Award BIOS dated 1999 for Intel i810, and the original IBM PC/AT BIOS don't seem to pass anything in DL on Int 19h. How did I verify it? For those who can't guess, let this be my little secret ;-G (Table 00653) Values Bootstrap loader is called with (IBM BIOS): CS:IP = h:7C00h DH = access bits 7-6,4-0: don't care bit 5: =0 device supported by INT 13 DL = boot drive 00h first floppy 80h first hard disk The above excerpt from the RBIL also proves that not all BIOSes pass boot drive in DL on Int 19h, and even if they do (e.g. IBM BIOS), they pass *only* 0 or 80h. Period. (And end of FF kludge ;-) Regards, Lucho --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector drive incompatibility with other boot sectors
Hi! 12--2004 14:08 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: I don't understand this. SYS writes 0/FF only into its own images, builtin into SYS executables. And, if _after_ SYS someone will change boot loader, then 0/FF value also will be replaced. Where is trouble? LG The trouble is that most SYSes don't bother to set this value - they just LG copy the whole data area from the old boot sector and replace only the LG code and OEM ID. So the FF remains there. Verified. _And_ their boot code reuse this field? If not, then this in unimportant, what those SYSes remain in 24h field. I think, current behavior (use fixed drive# in case of A:/C: and BIOS value in other cases, including HDs), is good and flexible way. LG Currently, fixed drive number 0 is used for floppies, but for hard disks, LG FF is used, which is troublesome if FreeDOS is replaced by another DOS LG later. Well, right now I look at boot code of MS-SYS6, and found, that it not uses 24h offset itself, but pass value from there to kernel. I not check what SYS does with original 24h field, but image inside SYS contains 80h value, so I doubt that MS-SYS preserves this field. LG Now Jeremy added an option to set the boot drive to an arbitrary LG value, which solves the issue. But FF is still default for hard disks. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
Hi! BTW, Lucho, if you wish, I may prepare for you macroses in TASM to ease writing more readable and safer country.asm. Probably, someone then may translate these macro to NASM? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Patch: COUNTRY.ASM
Hi! 12--2004 14:23 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: * There is no room for the LCASE table, so it won't be possible to load the ru/866 pair. BTW, in contary to RBIL (which says that INT21/6503 is present only in DOS 6.2+ COUNTRY.SYS and supports only CP866) MS-DOS with CP866 installed doesn't supports LCASE. B-\ --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel country.asm, inthndlr.c
Hi! 12--2004 13:54 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: Show this, please. LG See it in the CVS, along with the nice additions of Eduardo. CVS isn't accesible for me. Let me ask reverse question: why you add this _another FreeDOS specific function, which duplicates another specific function_, whereas only some version probably support this function (and RBIL is not very clear how!). LG It's not FreeDOS-specific. It's MS-DOS 4.0 specific. And some software LG uses it. Why then you not add other-DOSes-specific functions? For example, INT21/20: S/DOS 1.0+ PTS-DOS 6.51+ - GET OEM REVISION? Or INT21/92? Some software also use these functions. In case of INT2F/122F some software mean mythical Matthias' FREEVER, which noone of us seen it, and it even unknown if this function need for FREEVER at all. LG Don't ask me more. Lucho, you introduce change in interface. _Such_ actions necessarily _must_ be discussed and approved. So don't ask me more is not in given case. Now your patches mention GPL (which associated with GPL1) LG No, GPL means *current* version, and the URL points to it. URL is reduced for convenience, but for law clarity (for which you at all mention license) you should mention complate license name. Explicitly. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Reading new COUNTRY.SYS records
Hi, Luchezar Georgiev escribi: I still think that half a kilobyte isn't a big price to pay, PROVIDED THAT SOMEONE WILL REALLY USE THE DOUBLE-BYTE TABLES. As far as I know, there are complete Chinese, Korean and Japanese packages that install their own font, NLS and keyboard support, and most people will use them and not our inferior but much more difficult to set up COUNTRY + NLSFUNC + DISPLAY + KEYBOARD + whatever :-/ If nobody will use them, then your option (1) is the one to implement. Chinese, Japanese and Korean friends, please express your opinion now. Last not least, we don't have these tables yet, and may not have them. Japanese is different from the other two, at least keyboardwise. Japanese-style DOS allows that the keyboard driver outputs simple characters, thus KEYB is valid, and furthermore, I am precisely implementing the last required bit so that FD-KEYB is good for Japanese. The problem is that one needs another sofware, called Front-end Processor (I seem to recall, someone correct me) that collects bytes from keyboard and also the status of KEYB through some API (being now implemented) so that you have Japanese keyboard support. I don't know much what happens respect to the display adapter. And I know nothing about Korean or Chinese, so I can't help, sorry. Aitor --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
