Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hi! 15--2004 21:59 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO BC isn't a target for freedos optimizations; there's one and only one BO target to optimize for : WATCOM. BO so BC specific optimization is a waste of time (ours and yours) BO This just being tom's opinion but I still agree -- I agree too, but _small_ optimizations, like discussed joined write into lr.BX, _may_ be applied, because they (may) help for other compilers too. BO I even agree more than BO I did a couple months ago, that's why I rejected my own idea of using BO _seg * pointers. I played for a while again with Turbo C++ back then but BO in the end decided that the difference was just too big. After my playing with _seg (you may see its usage in unstable branch through MK_SEG_PTR()) I see the noticeable code reduction for Borland. Though, Borland contains bug also there, it related to conversion literal values to far pointers. :( --- 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] 32RTM Bug Found, no good fix
Hi! 15--2004 20:24 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: - lr.BH = OEM_ID; - lr.CH = REVISION_MAJOR; /* JPP */ - lr.CL = REVISION_MINOR; - lr.BL = REVISION_SEQ; + lr.BX = (OEM_ID 8) | REVISION_SEQ; + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes BO tabs?). There's also a pointless optimization, that the compiler can do BO for us as well. Can != to will and/or my. Yes, Watcom (but not, say, Borland) (sometime) may join adjacent memory writes into memory, but there writes into BX are interspersed. Also, to make more readable code, I add macro MK_UWORD(): lr.BX = MK_UWORD (OEM_ID, REVISION_SEQ);. --- 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! 10--2004 20:05 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG brain-dead BIOSes if the boot drive is A: (but not if it's C:), the FF LG value written to by SYS causes a compatibility problem. What happens if LG someone decides to overwrite our boot sector later with a boot sector from LG another DOS? The FF will remain there (I checked that with PC-DOS) and the LG new boot sector will try to boot off drive FF, which will fail. Being too LG smart sometimes hurts (if everyone else is dumb ;-) 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? Or, do you mean, that someone will _add_ own boot sector _into SYS_? But added boot sectors should follow some rules, including boot drive field (which, of course, internally may be ignored). LG So, I propose that SYS stores 0 if the drive is A: or B:, 80 if the drive LG is C: or D:, D:==second disk? Second disk is a 81h value. LG and FF in all other cases, and that we add a special boot LG drive option that can be used by advanced users to store whatever value LG they like. We could also just leave that value unchanged from the old boot LG sector as most other SYSes doo, For this, SYS should verify, that it knows old boot record andr that mask is placed at expected position. Too fuzzy and ambuguous. LG thus placing the responcibility on FORMAT LG ;-) Please express your opinions on this issue. Changing the SYS behaviour LG is easy, but taking the right decision isn't. 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. --- 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
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? The trouble is that most SYSes don't bother to set this value - they just copy the whole data area from the old boot sector and replace only the code and OEM ID. So the FF remains there. Verified. D:==second disk? Second disk is a 81h value. Only 0 and 80 are used by MS-DOS. All other values are FreeDOS extensions ;-) 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. Currently, fixed drive number 0 is used for floppies, but for hard disks, FF is used, which is troublesome if FreeDOS is replaced by another DOS later. Now Jeremy added an option to set the boot drive to an arbitrary 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] Boot sector drive incompatibility with other boot sectors
Hello Luchezar, D:==second disk? Second disk is a 81h value. Only 0 and 80 are used by MS-DOS. All other values are FreeDOS extensions ;-) are you SURE ? I remember a BIOS that had the option to boot from 2'nd drive. this only makes sense if DOS then boots from 0x81. 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] Re: kernel/kernel country.asm, inthndlr.c
Hello Luchezar, 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 :-( at least I know the problem - and described it when publishing the patch. it happens if a int24 handler returns to itself directly, instead of the 'normal' way to return to DOS with some error code. In that case the near f_nodes are never freed (until the program terminates) the only real solution that comes to my mind is to undo the alloc_fnode() change, even if that costs a few byte in low memory; if you don't have UMB's, it even saves a few byte (the memory used by the 2 near_fnodes) 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] Re: kernel/kernel country.asm, inthndlr.c
Hi! 12--2004 14:28 Arkady V.Belousov wrote to [EMAIL PROTECTED]: And what about INT2F/122F? LG Although only MS-DOS 4.0 had it, I won't remove it AVB Let me ask reverse question: why you add this _another FreeDOS AVB specific AVB function, which duplicates another specific function_, whereas only some AVB version only some _MS-DOS_ versions AVB probably support this function (and RBIL is not very clear how!). And we even don't may prove this or check how those MS-DOS editions support this function. --- 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] showing off with low RAM?
Hi, after PTS-DOS, the DR-DOS enhancement people have added an option to put more data structures of DOS into UMB (I guess this time we are talking about LoL / SDA). That way they get 626k of 640k low DOS RAM free after loading HIMEM/EMM386. If you want to keep up with the game, we could add such an option to FreeDOS, too. However, we already do have 622k low DOS RAM free in a quite straightforward configuration (in DOSEMU, where HIMEM / EMM386 take almost no memory, even 627k), and I never met any program which really needed more than 590k, so this is only about bragging. Relocating LoL/SDA into UMB might be a bit tricky, and it will not work if programs outside the kernel start using it before it gets moved. However, HIMEM / EMM386 are usually loaded first, so... More interesting and useful would definitely be something like my suggested checksum some/all SFT entry fields and force an update of the corresponding f_node if a SFT entry is found to be changed from outside. I believe this would be necessary to allow DOS boxes to work inside Win 3.x standard mode (DSWAP/WSWAP). Eric PS: Other interesting details: Our STACKS data structure is very different from / simpler than classic DOS 3.x STACKS, and we support neither int 2f.13 (rehook int 13) nor offer an int 13 wrapper which avoids DMA problems (we just avoid them in the kernel BEFORE calling the disk device driver, so programs which call int 13 directly have to check for DMA boundaries themselves) nor do we have the original int vectors 10/13/15/19/1b data at 70:100 or the DDPT at 0:522 (we have it at 70:0). Hard to tell which compatibility problems those details could cause. Bonus question: Does MS DOS actually call int 25/26 itself or does it - like FreeDOS - only offer int 25/26 for disk tools, but calls the device drivers directly for everything else? --- 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] showing off with low RAM?
Hallo Eric, we already do have 622k low DOS RAM free in a quite straightforward configuration (in DOSEMU, where HIMEM / EMM386 take almost no memory, even 627k), and I never met any program which really needed more than 590k, so this is only about bragging. Exactly. I have 629 KB free in FreeDOS and that's enough for me. More interesting and useful would definitely be something like my suggested checksum some/all SFT entry fields and force an update of the corresponding f_node if a SFT entry is found to be changed from outside. I believe this would be necessary to allow DOS boxes to work inside Win 3.x standard mode (DSWAP/WSWAP). Then go ahead, what are you waiting for? You do have write CVS access, don't you? ;-) But remember what Tom said about the 3m long stick (that he won't touch the unstable kernel). Got the hint? ;-) programs which call int 13 directly have to check for DMA boundaries themselves) nor do we have the original int vectors 10/13/15/19/1b data at 70:100 or the DDPT at 0:522 (we have it at 70:0). Hard to tell which compatibility problems those details could cause. If I remember correctly, Bart had some solid arguments against moving from 60:0 to 70:0... Bonus question: Does MS DOS actually call int 25/26 itself or does it - like FreeDOS - only offer int 25/26 for disk tools, but calls the device drivers directly for everything else? It's like FreeDOS - doesn't call Int 25h/26h itself but calls the device drivers directly. 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: Boot sector drive incompatibility with other boot sectors
Hallo, Therefore I vote for a SYS option which lets you decide whether or not the 0x80 in the boot sector will be used. The DEFAULT should be, in my opinion, to accept the value from the boot manager / MBR / BIOS for harddisks. For floppy, 0 will be in the boot sector, and the DEFAULT should probably be to ignore the value from the BIOS / boot manager. Why discriminate between floppy and hard disk? So: - no more 0xff - always write 0 or 0x80 I agree with both of the above. - allow control (patching, e.g. mov variable,reg - mov reg,variable) of the actual source (value from caller versus value in boot sector) of the used boot drive number. Can you give more details for the above? I don't like patching boot sectors at non-uniform places. 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] break.c, inithma.c
unsigned char check_handle_break(struct dhdr FAR **pdev)
{
- unsigned char c;
+ unsigned char c = 0;
if (ctrl_break_pressed() ||
(c = (unsigned char)ndread(syscon)) == CTL_C
||
*pdev != syscon (c = (unsigned char)ndread(pdev))== CTL_C)
{
handle(break(pdev, -1);
}
return c;
}
Wrong. If no Ctrl-break (ctrl_break_pressed() returns false), then
called second part of condition (c = ndread()). So, my code _is_
correct, and this extra assignemnt is useless code spending.
*You* are wrong. If ctrl_break_pressed() returns true, c (and
therefore the function return value) would be *undefined* without my patch!
+static struct { /* Boot sector of a RAM-Disk */
+ UBYTE dummy1[3];/* HIMEM.SYS uses 3, but FDXMS uses
2 */
+ char Name[5];
[...]
+} VDISK_BOOT_SECTOR = {
+ {0xcf,' ',' '},
+ {VDISK},
Unfortunately, newer standards prohibit to assign nonterminated strings
to arrays (ie. 5-character string VDISK _plus_ trerminating zero not
fit into 5-bytes array, so newer compilers should compain).
Surprisingly, even OpenWatcom 1.3 (so new that it's not even announced!)
doesn't complain! ;-)
---
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: boot sector drive incompatibility with other boot sectors
Hi Jeremy, I vote for 2) - use 0 or 80 only in the boot sector (or really any value the user wants, but default to 0 or 80) - the boot sector code has at a fixed location useBIOSorNotFixedLocation: mov [drive], dl - SYS is then responsible for determining if BIOS provided value is used or not by patching useBIOSorNotFixedLocation with NOPs ... *but* with different SYS behaviour: Make /B drivenumber and /USEBPBDRIVE work independent from each other. Sometimes you will want /B 81 /USEBPBDRIVE, sometimes /USEBPBDRIVE (with default drive 0 or 80 that is), and in rare cases even /B 81 (where the 81 is only read by disk tools but DOS uses the value passed by the boot loader / MBR instead). And of course (use value passed by MBR and write default 0 or 80 value into boot sector). MS DOS 5 behaves as /USEBPBDRIVE MS DOS 4 same IBM DOS 3 probably the same Win9x same but skips int 13.00 depending on drive number high bit? WinNT same as DOS 5 ... and so on. According to: http://home.att.net/~rayknights/pc_boot/pc_boot.htm Win9x scans the MBR to find the primary partition which starts at the same LBA offset as stored in the boot sector... (if drive number is 0x80 or higher) ... So all MS operating systems require that either the BIOS maps around the drive numbers or that something stores 0x81 in the boot sector. Otherwise they cannot boot from a secondary harddisk. They all ignore the drive number passed from the BIOS / MBR / boot loader. Or course this does not stop us from ACCEPTING the drive number passed from the BIOS / MBR / boot loader :-). But it seems to be okay to make /USEBPBDRIVE on by default. Then the user can use either the default drive numbers (0 or 0x80) or select a different number (e.g. 0x81) manually with the /B ... option. Some /DONOTUSEBPBDRIVE option would only be needed for smart boot managers / BIOSes which can pass other drive numbers than 0x80 to the boot sector. You would have to test yourself if your BIOS is able to do that, and if not, how it implements booting from secondary harddisks (e.g. by mapping drive numbers in a different way or by patching around in boot sectors?). Eric --- 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
