Re: [Freedos-kernel] Re: 32RTM bug
Luchezar Georgiev escribiÃ: Using the -X option bypasses the InDOS function call, so you don't see a problem when you use that 32RTM option. But the InDOS call just does: case 0x34: lr.ES = FP_SEG(&InDOS); lr.BX = FP_SEG(&InDOS); wouldn't that be FP_OFS? break; What could be wrong here? Aitor --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Will FreeDOS work from a primary slave partition?
Hi, Arkady V.Belousov escribiÃ: LG> Let's concentrate on bgfixing before the imminent FD1 release. I not object, but this question may be studied _for future releases_. Isn't? :) Of course. If it's not to be forgotten, I could annotate it on the post-1.0 table (currently a badly mixed list of missing tools, to be tidied up soon). Shall I proceed? Aitor --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM Bug Found, no good fix
Hello Eric, >> - lr.CH = REVISION_MAJOR; /* JPP */ >> - lr.CL = REVISION_MINOR; >> + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes >> stack! */ > I would vote for lr.CH = 0 lr.CL = *letter* MSDOS votes cx=0. end of story. tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM Bug Found, copyleft message
Hallo Eric, Even 2035z would still mean a sufficiently small CX value and 32RTM would work. If CX is nonzero, 32RTM will *not* work. And CX *is* zero in *all* DOS version I've tested (MS-DOS, PC-DOS, ROM-DOS and DR-DOS). Michael, Tom and Alain are right. There's nothing else we could do but clear CX. What's more important after all - that FreeCOM shows 1.1.35 instead of 0.0.35, or that 32RTM works? I think that the answer is obvious for everybody. Yes we DO want to mention the license! MENTION. Not display the whole 18k file, obviously. That's exactly what I meant with my proposal (it fits on 2 lines despite the wraparound that my mail client will probably do): FreeDOS kernel build 2035a-UNSTABLE Copyleft 1985-2004 Pasquale J. Villani and The FreeDOS Project. NO WARRANTY. Licensed under the GNU General Public License This increases the size in RAM by ZERO bytes and the size on disk by some really small number of bytes - and our kernel is very small on disk already anyway. So leave the banner message as is, thank you. The current message does more than simply MENTIONING the GPL. That's why I think it's too long. Just MENTIONING the GPL is enough - most people nowadays already know it. It's not like it was back in 1991! Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035a) start segment must be variable
Hi Arkady, good to have you back :) Please send me your email address for direct contact. I sent you a message that was probably lost :( Alain --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hello Luchezar, >> There you have it folks. A dumb bug in a Borland product that by purest >> happenstance fails under FreeDOS and not MS-DOS. I don't have any idea >> how to gracefully fix the problem other than to have FreeDOS change its >> serial number. And it shouldn't have to do that. Another one who whishes to congratulate Michael for finding this bug, and thanks. > --- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200 > +++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200 > @@ -698,10 +698,8 @@ > case 0x30: > lr.AL = os_setver_major; > lr.AH = os_setver_minor; > - 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 > stack! */ and that's a patch I can peer review, understand it's implications, and merged into my boring rock solid (as stone) kernel branch ;) tom --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Initial copyleft / licensing message
FreeDOS kernel build 2035a-WHATEVER. Copyright... This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to redistribute it under certain conditions; press F1 for details. I'd prefer this: FreeDOS kernel build 2035a-UNSTABLE Copyleft 1995-2004 Pasquale J. Villani and the FreeDOS Project. NO WARRANTY. Licensed under the GNU General Public License Nice idea and very easy to implement. :) I think, this is even _should_ be implemented, as startup screen should be cleaned. Please don't put the licensing conditions into the kernel! We strive for small size, don't we? Besides, that GNOMOVISION example is in the 12 year olg GPL2 only. The Alfero license, which is said to be the example for the future (mythical?) GPL3, doesn't have this example. If you ask me, the smaller startup message the better, and no license games at DOS bootstrap! Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hi! 8-Авг-2004 11:39 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO> FreeDOS could, say, show the full message if you press a certain F key(as BO> it waits for F5/F8 anyway), like this BO> FreeDOS kernel build 2035a-WHATEVER. Copyright... BO> This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to BO> redistribute it under certain conditions; press F1 for details. Nice idea and very easy to implement. :) I think, this is even _should_ be implemented, as startup screen should be cleaned. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS
Hi! 11-Авг-2004 14:22 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG> RAR 3.30 (its DOS version fails LG> to modify existing archives but its Windows console version can do it). Do you report this to Eugeny? I may do this myself, if you explain me, how to reproduce this bug. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hi! 7-Авг-2004 17:22 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG> Arkady, please respond if you read this. How are you? Fine, thank you. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Thank you very much, Michael, for your discovery of the 32RTM bug!
There you have it folks. A dumb bug in a Borland product that by purest
happenstance fails under FreeDOS and not MS-DOS. I don't have any idea
how to gracefully fix the problem other than to have FreeDOS change its
serial number. And it shouldn't have to do that.
Sure. But since it's easier to make the kernel return a serial mumber of 0
as MS-DOS does than to patch each and every copy of 32RTM.EXE, I changed
our function 30h to return 0 in CX. I tested this change and now 32RTM
works without -X as Michael wrote indeed! So I uploaded a new unstable
kernel binary at http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ along
with a comulative patch (CVSPATCH.TXT) for the unstable branch consisting
of the Eduardo's NLS patch and the following patch. Thus, regrettably
we're back to version 0.0.35 now (as reported by the FreeCOM's VER /R ;-)
I guess 32RTM now stands for "32 times Read The Manual!" ;-)
Do you see now what I meant when I wrote that MS-DOS has a better "bug
compatibility"? ;-)
Regards,
Lucho
--- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200
+++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200
@@ -698,10 +698,8 @@
case 0x30:
lr.AL = os_setver_major;
lr.AH = os_setver_minor;
- 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
stack! */
if (ReturnAnyDosVersionExpected)
{
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
At 09:18 AM 8/13/2004 +0300, Luchezar Georgiev wrote: I tried "int 0x21 ah=0x34" in both MS-DOS 7.10 and FreeDOS. In both, the returned offset in BX is 321h although the segment in ES is slightly lower in MS-DOS than in FreeDOS (C9h vs D2h). But in both cases, the memory location pointed to by ES:BX was 0. So, that pointer seems valid to me. Yes, I think the ES:BX pointer is always valid, but I think, or thought, that maybe an internal pointer is not valid because of stack problems trashing a pointer value elsewhere in the vicinity. Turns out the problem may be stack-related, but not really pointer related. I may have found the problem and if correct it is Borland's error. More in a bit, I have to double- and triple-check this possible bug I found in RTM. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Good luck, Arkady!
My working machine died, so I currently change my machine, disks and OS. Good luck with your new PC, and may you have at least one FAT32 volume! :) --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
Hello Michael, I don't want to suggest basic things you've probably already thought of, but want to point out that the actual exception due to REP MOVSW in protected mode is significant. It's not a crash within FreeDOS or failure within the real mode INT 21h handler. Looks like a bad pointer to me. I tried "int 0x21 ah=0x34" in both MS-DOS 7.10 and FreeDOS. In both, the returned offset in BX is 321h although the segment in ES is slightly lower in MS-DOS than in FreeDOS (C9h vs D2h). But in both cases, the memory location pointed to by ES:BX was 0. So, that pointer seems valid to me. I also tried to catch the real pointer value when called by 32RTM with STEPDOS. It didn't came to calling DOS function 34h at all! The latest DOS function I saw before it showed the "Unhandled exception" message was 2Fh (get DTA). The returned value by function 2Fh in ES:BX was 1376:80h. Of course, that bad pointer could have come about due to stack corruption real or pmode, stack overflow back into Borland's data storage, memory corruption, or changing an unexpected register, but RTM lives long enough to get back to the RTM code itself, presumably in the DPMI dispatch/return area. I don't think the actual ES:BX return value is the problem, because it's not had a chance to be used at the exception point. You may be right that it's a bad pointer in the context of the real call. Could you catch what pointer it returns when called by 32RTM? The returned value in ES:BX when I test it by "int" is D2:321h. I tried manually shoehorning my own GDT entry in the RTM GDTand overwriting RTM's IDT for exception 0DH so I could catch the exception without any luck other than a change in exception message, but I could try again if nobody has any idea why it's failing. Alas, this seems so, indeed... If you can see the pointer DOS function 34h returns (or even the byte pointed to by it) when called by 32RTM, this may help. Thanks, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
Hallo Bart, case 0x34: lr.ES = FP_SEG(&InDOS); lr.BX = FP_SEG(&InDOS); break; What could be wrong here? Copy and paste is broken where you are. Not copy and paste, my head is broken because I typed it by hand! ;-) with lr.BX = FP_OFF(&InDOS); it would be correct. But that's what it does in my source so... Of course it's FP_OFF, not FP_SEG for lr.BX - I just mistyped it :-( Stack usage during the call? that's what I suspected. Eric suggested (in a private email) to make int21/ah=34 reentrant like we did for 25 and 35. However than it would completely execute on the user stack and that stack seemed to have been the problem (only 30 words?). How do you know that the user stack is just 30 words? Since you said commenting out calls to the int2a handler didn't help... The only other extra stack user is the macro for 386 registers. Perhaps compiling for <386 or pushing/popping these on the kernel stack would work around that. I tried a 80186 kernel but the result is the same. I don't know how to implement the other suggestion but because of the test results so far I'm not sure if the problem is indeed the stack. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035a) start segment must be variable
Hi! 7-Авг-2004 13:28 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: LG> exeflat.c of build 2035a (not 2035) has a problem. The start segment is an LG> argument so it's a variable and its value - 2 must be loaded into DI LG> instead of the constant 0x5E. Here's a fix: LG> +*(short *)&trailer[3] = start_seg - 2; True. Thank you, Lucho. PS: My working machine died, so I currently change my machine, disks and OS. The more so, many times I spend by playing into Heroes III. :( So, some time I will answer slowly. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
At 11:57 PM 8/12/2004 +1200, Bart Oldeman wrote: > The InDOS flag value itself? with lr.BX = FP_OFF(&InDOS); it would be correct. But that's what it does in my source so... > Stack usage during the call? that's what I suspected. Eric suggested (in a private email) to make int21/ah=34 reentrant like we did for 25 and 35. However than it would completely execute on the user stack and that stack seemed to have been the problem (only 30 words?). I don't want to suggest basic things you've probably already thought of, but want to point out that the actual exception due to REP MOVSW in protected mode is significant. It's not a crash within FreeDOS or failure within the real mode INT 21h handler. Looks like a bad pointer to me. Of course, that bad pointer could have come about due to stack corruption real or pmode, stack overflow back into Borland's data storage, memory corruption, or changing an unexpected register, but RTM lives long enough to get back to the RTM code itself, presumably in the DPMI dispatch/return area. I don't think the actual ES:BX return value is the problem, because it's not had a chance to be used at the exception point. I tried manually shoehorning my own GDT entry in the RTM GDTand overwriting RTM's IDT for exception 0DH so I could catch the exception without any luck other than a change in exception message, but I could try again if nobody has any idea why it's failing. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local
> > issue he raised here but good enough for testing. Unfortunately it > > broke "mkdir" so this would need a bit more work than the 3 > > patch-lines I got from Eric. > > Hmm. Stange that it broke mkdir. My fault. It happened that I applied it on a kernel-tar from just before the 2035-release which appearantly was not in good shape. I now applied it on the "official" 2035-source (ke2035src) and Eric's patch does NOT break mkdir. But it also did not help anything to bug 1753. Nor the 3-line patch or the 2-line proposal by Bart did improve anything here. When logging in to NetWare there is an error by login.exe that it cannot find its msg-file (which is present) and then it halts (with or without showing some invalid opcode data). So it seams we still cannot shake of 1753 which has been with us since kernel 2027. Erwin --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
On Thu, 12 Aug 2004, Luchezar Georgiev wrote: > [added by me]: Michael wrote: > > > Using the -X option bypasses the InDOS function call, so you don't see a > > problem when you use that 32RTM option. > > But the InDOS call just does: > > case 0x34: > lr.ES = FP_SEG(&InDOS); > lr.BX = FP_SEG(&InDOS); > break; > > What could be wrong here? Copy and paste is broken where you are. > The InDOS flag value itself? with lr.BX = FP_OFF(&InDOS); it would be correct. But that's what it does in my source so... > Stack usage during the call? that's what I suspected. Eric suggested (in a private email) to make int21/ah=34 reentrant like we did for 25 and 35. However than it would completely execute on the user stack and that stack seemed to have been the problem (only 30 words?). Since you said commenting out calls to the int2a handler didn't help... The only other extra stack user is the macro for 386 registers. Perhaps compiling for <386 or pushing/popping these on the kernel stack would work around that. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local
On Thu, 12 Aug 2004, Erwin Veermans wrote:
> issue he raised here but good enough for testing. Unfortunately
> it broke "mkdir" so this would need a bit more work than the
> 3 patch-lines I got from Eric.
Hmm. Stange that it broke mkdir.
> [Eric's incomplete patch-proposal]
>
> dosfns.c DosFindNext:
> wrong -->
> if (dmp->dm_attr_fnd & (D_DEVICE | D_VOLID))
> return DE_NFILES;
> correction -->
> if (dmp->dm_attr_find & (D_DEVICE))
> return DE_NFILES;
ok, that's bit clearer than his email (which was about 10x longer than
necessary, but obviously I'm the only one here who thinks that?).
The dosfns.c "correction" here is wrong IMHO. What it means is:
" if the direntry *found* in the findfirst has VOLID or DEVICE bits set
then we aren't searching any further "
This is not the same as the search attribute in dm_attr_srch, it merely
reflects the fact that we only want to find *one* volume label or device.
I'd propose to *only* apply the patch to fatdir.c, i.e. what's below.
In my own testing mkdir still works.
Bart
--- fatdir.c.~1.47.~2004-05-24 06:28:18.0 +1200
+++ fatdir.c2004-08-11 20:35:37.0 +1200
@@ -384,7 +384,7 @@
/* directory and only searched for once. So we need to open*/
/* the root and return only the first entry that contains the */
/* volume id bit set. */
- if ((attr & (D_VOLID|D_DIR))==D_VOLID)
+ if ((attr & ~(D_RDONLY|D_ARCHIVE))==D_VOLID)
i = 3;
/* Now open this directory so that we can read the */
/* fnode entry and do a match on it.*/
@@ -406,7 +406,7 @@
/* Copy the raw pattern from our data segment to the DTA. */
fmemcpy(dmp->dm_name_pat, SearchDir.dir_name, FNAME_SIZE + FEXT_SIZE);
- if ((attr & (D_VOLID|D_DIR))==D_VOLID)
+ if ((attr & ~(D_RDONLY|D_ARCHIVE))==D_VOLID)
{
/* Now do the search*/
while (dir_read(fnp) == 1)
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local
Hi, Eric reported a FindFirst/FindNext bug here in his message: "[Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local" (I included a part of it below in this message). When I filed bug 1753 (NetWare VLM invalid opcode upon login, http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1753 ), I added my suspicion that it might be invoked by a FindFirst/FindNext quirck. Since 1753 is in the 1.0-todo-list and Eric just mentioned a FindFirst/FindNext problem I thought to give it a shot. >From Eric I received following patches under the remark that it would not be a complete coverage of the FindFirst/FindNext issue he raised here but good enough for testing. Unfortunately it broke "mkdir" so this would need a bit more work than the 3 patch-lines I got from Eric. I can edit, compile and test but it all stops when I need to interprete Kernel-code and invent some modifications (I better not do that ;-) So is anybody out there with Kernel knowledge having some pointers for me (a diff ?) on this (clearing 1753 by brushing up FindFirst/Next) ? Thanks, Erwin [Eric's incomplete patch-proposal] dosfns.c DosFindNext: wrong --> if (dmp->dm_attr_fnd & (D_DEVICE | D_VOLID)) return DE_NFILES; correction --> if (dmp->dm_attr_find & (D_DEVICE)) return DE_NFILES; fatdir.c dos_findfirst: wrong --> if ((attr & (D_VOLID|D_DIR))==D_VOLID) i = 3; correction --> if ((attr & ~(D_RDONLY | D_ARCHIVE))==D_VOLID) i = 3; wrong --> if ((attr & (D_VOLID|D_DIR))==D_VOLID) correction --> if ((attr & ~(D_RDONLY | D_ARCHIVE))==D_VOLID) [From Eric Auer's initial message on FindFirst/Next to this list] > So I would like to report a kernel findfirst bug: > FreeDOS 2035 treats CX value 77a8 like CX value 0008, and returns only > the volume label, for a findfirst for "*.usr" on a local disk. On a > redir disk, no problems happen. Notice that the volume label does not > need to be *.usr to show up - it only has to exist - and that the game > does not need to be in the root directory to trigger this bug! > > For now, I can use a patch: "replace mov cx,dx by mov cl,0" - but > unless FreeDOS accidentally caused the load location & 00de (bits 0 > and 5 of CX are ignored in findfirst), the CONCLUSION for the kernel > should be: ONLY return only the volume label if cx & ffde equals 8. > Current situation seems to be "return only the volume label if cx & > 00de equals 8". --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
Using the -X option bypasses the InDOS function call, so you don't see a problem when you use that 32RTM option. But the InDOS call just does: case 0x34: lr.ES = FP_SEG(&InDOS); lr.BX = FP_SEG(&InDOS); break; What could be wrong here? The InDOS flag value itself? Stack usage during the call? --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS vs HX
Hello Japheth, and thanks for your reply! I downloaded all the 10 ZIPs there but none contained CRTDLL.DLL Yes. That is because CRTDLL.DLL is copyright MS and is included in every windows OS. I see! OK, when I copied it from W98 to C:\HX, PESTUB patched MASM 6.15 successfully, so I can now run it in FreeDOS, this time perfectly, also when building real projects with NMAKE and assembling multiple files at once. Congratulations! However, when I apply PESTUB to Digital Mars 8.38 (SC.EXE and SCPPN.EXE), it still crashes with a register dump (general protection fault) when I try to build real projects with SMAKE, but works when converted by HiNTOS, albeit *not* in FreeDOS :-( Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
At 11:35 PM 8/11/2004 +1200, Bart Oldeman wrote: There's one FD incompatibility that's been there for some time: OpenWatcom wd /tr=rsi and wd /tr=cw appear to run just fine when you debug a program but a crash occurs (black screen, reset only way out, or invalid opcode) when you exit the debugger. This doesn't happen with MSDOS. Guess I can download and copy it over to the FreeDOS machine. I'm back to average Joe User for all that stuff since my custom CauseWay and Watcom development machine setup had a very noisy and severe hard disk crash last month. Since no mission critical data was lost, I declined Ontrack Data Recovery's kind offer to recover the files from the magic magnetic fairy dust for the low low discounted price of $1600.00. Something about being able to get a much nicer new hard drive with a fairly powerful computer wrapped around it for the same amount of money made the process seem less worthwhile. Which is a roundabout way of saying that probably in the next day or three I'll grab the latest files from OpenWatcom and install there for testing. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS
At 02:22 PM 8/11/2004 +0300, Luchezar Georgiev wrote: HiNTOS is a DOS extender and Windows emulator that converts Windows console programs into programs that run in both Windows and DOS. It's the only one that can convert *fixed* PE executables (WDOSX can't!). It's available at http://www.alex-hint.narod.ru/hintos-e.html and I think it's becoming more and more important now when everybody releases Windows console programs without DOS counterparts. I converted successfully with it: Digital Mars C/C++ 8.38, MASM 6.15 and RAR 3.30 (its DOS version fails to modify existing archives but its Windows console version can do it). HiNTOS works under MS-DOS, PC-DOS and ROM-DOS, but not under DR-DOS and FreeDOS. To make it run under FreeDOS, the kernel will have to be rewritten not only to show SFT data to the outside world but also to work with this data internally as MS-DOS does. This won't happen soon, if at all :-( Given sufficient demand, some young hotshot programmer might be able to write a compatibility wedge for it if the code was open-sourced or the SFT req was fully spec'ed out . I don't know though, the software doesn't look ready for endusers other than experimenting types. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
dos_crit_sect: mov [_Int21AX],ax ; needed! pushax ; This must be here!!! mov ah,82h ; re-enrty sake before disk stack int 2ah ; Calling Server Hook! pop ax ret I don't understand the comments here. Who wrote this code? Does "re-enrty sake before disk stack" mean that this code has to be executed on the user stack? Anyway, one could experiment by commenting out all "call dos_crit_sect"s in entry.asm. Just tried what you suggested, Bart, but unfortunately the result is the same :-( Any other ideas? Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS vs HX
Wed, 11 Aug 2004 23:46:27 +1200 (NZST), Bart Oldeman <[EMAIL PROTECTED]>: On Wed, 11 Aug 2004, Luchezar Georgiev wrote: HiNTOS is a DOS extender and Windows emulator that converts Windows console programs into programs that run in both Windows and DOS. It's the only one that can convert *fixed* PE executables (WDOSX can't!). HiNTOS is at http://www.alex-hint.narod.ru/hintos-e.html Just in case you didn't know, there's yet another program in this department: HX, see http://www.japheth.de. Japheth has been very helpful in finding bugs in DOSEMU's built-in DOS extender (yes even though the DPMI spec doesn't mention it, a DPMI server will have to provide some DOS extender services to be compatible just because Windows' built-in DPMI server does that too). Thank you, Bart! I didn't know about HX (so I wasn't right that HiNTOS is unique!), hence I spent a few hours on it. I downloaded all the 10 ZIPs there but none contained CRTDLL.DLL that PESTUB.EXE needs. So I couldn't use it. But I tried the resident mode. The idea is great - for the price of just 496 resident bytes you could run PE files unpatched! But although I was able to run ML 6.15 and SC 8.38 on their own in both MS-DOS and FreeDOS (RAR 3.30 failed with a message that the required ExitWindowsEx call is unsupported), both failed with register dumps when I tried to build real projects with NMAKE and SMAKE, respectively, although I set DPMILDR=8 as recommended. (BCC 5.02 however ran successfully even in FreeDOS because it didn't have the chance to use 32RTM ;-) But TLIB failed to run in both MS-DOS and FreeDOS. So, at least for me, HiNTOS is the winner, because it runs RAR 3.30, ML 6.15 and SC 8.38 successfully, including when building projects with NMAKE and SMAKE, albeit HiNTOS doesn't support FreeDOS and DR-DOS but only MS-DOS, PC-DOS and ROM-DOS. But I'm sure that if Japheth and Alex unite, they'll blow out Windows with their future SUPER OS! Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS
On Wed, 11 Aug 2004, Luchezar Georgiev wrote: > HiNTOS is a DOS extender and Windows emulator that converts Windows > console programs into programs that run in both Windows and DOS. It's the > only one that can convert *fixed* PE executables (WDOSX can't!). Just in case you didn't know, there's yet another program in this department: HX, see http://www.japheth.de. Japheth has been very helpful in finding bugs in DOSEMU's built-in DOS extender (yes even though the DPMI spec doesn't mention it, a DPMI server will have to provide some DOS extender services to be compatible just because Windows' built-in DPMI server does that too). Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
On Tue, 10 Aug 2004, Michael Devore wrote: > And with that, I'm at the end of the list for finding FreeDOS > incompatibilities unrelated to kernel, shell, and stand-alone FD utilities > again. There's one FD incompatibility that's been there for some time: OpenWatcom wd /tr=rsi and wd /tr=cw appear to run just fine when you debug a program but a crash occurs (black screen, reset only way out, or invalid opcode) when you exit the debugger. This doesn't happen with MSDOS. I just tested today with WD from OW 1.3rc3. OW 1.2 has problems of its own in this department. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] HiNTOS
Hello Michael, Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or Windows to DOS converter) doesn't work at all in FreeDOS. This is either a really obscure extender or else also known under a different name, as even Google Usenet search doesn't pick up a hint of it. But it doesn't sound like it's a current issue for anyone. HiNTOS is a DOS extender and Windows emulator that converts Windows console programs into programs that run in both Windows and DOS. It's the only one that can convert *fixed* PE executables (WDOSX can't!). It's available at http://www.alex-hint.narod.ru/hintos-e.html and I think it's becoming more and more important now when everybody releases Windows console programs without DOS counterparts. I converted successfully with it: Digital Mars C/C++ 8.38, MASM 6.15 and RAR 3.30 (its DOS version fails to modify existing archives but its Windows console version can do it). HiNTOS works under MS-DOS, PC-DOS and ROM-DOS, but not under DR-DOS and FreeDOS. To make it run under FreeDOS, the kernel will have to be rewritten not only to show SFT data to the outside world but also to work with this data internally as MS-DOS does. This won't happen soon, if at all :-( Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
On Wed, 11 Aug 2004, Bart Oldeman wrote: Hello Bart, The section is not from me, but it simply is to inform a multitasking scheduler that something bad happens currently -- in a simple case it's just an extended InDOS flag. ASSIGN has to issue these calls, too, I believe to inform a protected mode portion that it has modified user space memory and it would be no good thing to return to that process before ASSIGN restored that memory. Maybe it is even needed for Win3.xx to unlock some memory protection? The only data it requires - as far as I know - is register AX, to inform the handler what type of Critical section is going on. At least ASSIGN does NOT include the PUSH AX's. However, maybe you can successfully search the archives, there was some discussion about how Windows 3 is patching MS DOS, and when you see RBIL's INT-2A-80 it makes sense to patch PUSH AX into RET and vice verse to enable / disable critical sections, see DOS-5D-06 for _DOS 3_ (but zero -> non-zero for DOS 4+). ; ; end Dos Critical Section 0 thur 7 ; ; dos_crit_sect: mov [_Int21AX],ax ; needed! pushax ; This must be here!!! mov ah,82h ; re-enrty sake before disk stack int 2ah ; Calling Server Hook! pop ax ret Bye, -- Steffen Kaiser FH Bonn-Rhein-Sieg| e-mail: [EMAIL PROTECTED] FB Informatik | Grantham-Allee 20 | phone : +49 2241/865-203 53757 Sankt Augustin | Germany - Deutschland | fax : +49 2241/865-8203 --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Win3.x /3 investigations, /s ones, cool 386SWAT debugger
At 05:38 AM 8/11/2004 +0200, Eric Auer wrote: > An unanswered question is are you able to successfully install Windows 3.1 > itself over FreeDOS? Attempting to do so here aborts the install while it Yes I were able to do that. I copied all disk contents into 7 directories first (because I got an original and therefore very old pile of disks and I wanted to have a backup first). Then I copied all 7 directories into one directory, and started the install process from there. Of course I selected manual / custom installation, and used some sane / generic drivers (VGA16, LMouse, no network...) at first. Everything worked okay, even MSD worked (looks as Seems to be very flakey and system dependent. Here, WINSETUP consistently fails during init into GPF, even with vanilla setup and true-blue MS-DOS HIMEM and EMM386, or no EMM386 present. It starts Windows to get name and option install info during initialization process, but that's as far as it goes. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
At 01:02 PM 8/8/2004 +0300, you wrote: Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or Windows to DOS converter) doesn't work at all in FreeDOS. This is either a really obscure extender or else also known under a different name, as even Google Usenet search doesn't pick up a hint of it. But it doesn't sound like it's a current issue for anyone. And with that, I'm at the end of the list for finding FreeDOS incompatibilities unrelated to kernel, shell, and stand-alone FD utilities again. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
At 06:44 PM 8/10/2004 -0500, I wrote: At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote: On Tue, 10 Aug 2004, Michael Devore wrote: > Some way or another, it looks 32RTM is unhappy with what is going on with > the stack on the call to function 34h. I don't think the InDOS pointer > itself is what causes the failure because the exception can occur during or > immediately after return from the Get InDOS simulate call. >From your story it sounds that the int21 entry code uses too much space on the user stack. Before someone invest too much of their life, I suppose the location could be an artefact of the debugger interacting with InDOS, but it doesn't look like it. Problem is definitely the INT 31h simulate real mode interrupt Get InDOS function. If I patch out the function to simply put a zero in the returned ES:BX pointer, 32RTM goes resident without kicking out an exception. Of course, it no longer uses the InDOS flag properly, assuming it ever does use it. Anyway, that's as far as I can go with what I see. It's a problem with INT 21h DOS function 34h when called from pmode through the Borland DPMI server via INT 31h. Hopefully a kernel person can either fix it or call shenanigans on Borland. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote: On Tue, 10 Aug 2004, Michael Devore wrote: > Some way or another, it looks 32RTM is unhappy with what is going on with > the stack on the call to function 34h. I don't think the InDOS pointer > itself is what causes the failure because the exception can occur during or > immediately after return from the Get InDOS simulate call. >From your story it sounds that the int21 entry code uses too much space on the user stack. Before someone invest too much of their life, I suppose the location could be an artefact of the debugger interacting with InDOS, but it doesn't look like it. After RTM goes into (16-bit) protected mode and installs a DPMI server, any breakpoints I place with 386SWAT wind up at an IRET (apparently because of the dual nature of what IRET does and confused real mode/pmode issues with the debugger). If I breakpoint right before the INT 31h simulate real call function, I get the expected IRET. Placing a breakpoint immediately after gets the exception and termination feedback. Can't see how it would be other than that INT 31h function which is the problem. I tracked down the actual exception location reported. It's on a REP MOVSW, as is very typical. Possibly occurs in the DPMI interface which copies values to/from low memory. Not much help, that. And for all I know, this could be a bug in RTM which is masked in MS-DOS because of a larger or differently structured stack, or other internal image difference. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
On Tue, 10 Aug 2004, Michael Devore wrote: > Some way or another, it looks 32RTM is unhappy with what is going on with > the stack on the call to function 34h. I don't think the InDOS pointer > itself is what causes the failure because the exception can occur during or > immediately after return from the Get InDOS simulate call. >From your story it sounds that the int21 entry code uses too much space on the user stack. The only place I could find in entry.asm where this could be a problem is in - ; ; end Dos Critical Section 0 thur 7 ; ; dos_crit_sect: mov [_Int21AX],ax ; needed! pushax ; This must be here!!! mov ah,82h ; re-enrty sake before disk stack int 2ah ; Calling Server Hook! pop ax ret - I don't understand the comments here. Who wrote this code? Does "re-enrty sake before disk stack" mean that this code has to be executed on the user stack? Anyway, one could experiment by commenting out all "call dos_crit_sect"s in entry.asm. Bart --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM bug
At 01:43 PM 8/8/2004 +0300, Luchezar Georgiev wrote: Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS. Forgot the message: Unhandled exception 000D at 0020 034B ErrCode . This happens without EMM386. I haven't tried it with EMM386 in FreeDOS. Well, I can tell you where it's happening and the problematic DOS call, but I'm not a kernel developer, so I can't suggest a fix or detail on what causes the function to fail. Anyway, the problem appears to occur when 32RTM is running in protected mode and issues an INT 31h function 300h (simulate real mode interrupt) to emulate INT 21h function 34h, aka get InDOS flag. The INT 31h function is set to use the internal DPMI stack which RBIL warns may be as small as 30 words and that it should not be messed about from its entry state. RBIL also warns about not calling the 34h DOS function when another DOS function may be executing. Some way or another, it looks 32RTM is unhappy with what is going on with the stack on the call to function 34h. I don't think the InDOS pointer itself is what causes the failure because the exception can occur during or immediately after return from the Get InDOS simulate call. Using the -X option bypasses the InDOS function call, so you don't see a problem when you use that 32RTM option. Incidentally, this occurs with only HIMEM loaded, DOS loaded low, and no XMS swapping command shell present , so EMM386 and the rest of the motley crew isn't getting in the way here. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM BitMixer feature incompatibility
Well, UNPAQ.EXE says it needs 32RTM.EXE when executed and DPMI32.PAK just sits there completely inert, so apparently there is a bit more to the process than having the two files. A Catch 22 situation - each file needs the other (UNPAQ.EXE needs 32RTM.EXE that is in DPMI32.PAK to execute, but DPMI32.PAK needs UNPAQ.EXE to unpack it)! :-( I just sent you 32RTM.EXE privately, in a not so big ZIP file (56 KB). --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: 32RTM BitMixer feature incompatibility
At 10:56 AM 8/10/2004 +0300, Luchezar Georgiev wrote: Hello Michael, More specifically, I would need download access to an application which fails when running under these (or any) extenders, rather than the bare extender itself. The whole Borland C++ 5.02 is in Vietnam at http://www.saigontech.net/users/htliem/BC502/ The only files you need from there are UNPAQ.EXE (48 KB) and DPMI32.PAK (110 KB) containing 32RTM.EXE, because if you make 32RTM.EXE successfully load by itself without the -X (disable "BitMixer") switch, the problem is solved. In short, the problem is getting its "BitMixer" feature work under FreeDOS. This is explained below. Well, UNPAQ.EXE says it needs 32RTM.EXE when executed and DPMI32.PAK just sits there completely inert, so apparently there is a bit more to the process than having the two files. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Will FreeDOS work from a primary slave partition?
Hi! 10-Авг-2004 10:02 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to [EMAIL PROTECTED]: >> BTW, what if FreeDOS will search (fd)config.sys not on C:, but on real >> bootable partition? Kernel knows which disk was used to boot (currently >> not preserved - at start of main.c:FreeDOSmain() LoL->BootDrive >> initialized to 1..3 for A:,B: and C:), and >> initdisk.c:ReadAllPartitionTables() may compute, which partition is >> booted from boot drive, so before calling DoConfig() consequent drive >> (instead C:) may be selected as default. Any objections? LG> Isn't the "real bootable partition" always assigned to C:? Not completely. See initdisk.c:ReadAllPartitionTables() - in case of MS-DOS order there always searched first primary active partition on _first_ disk. (If there is no active partition, searched any first primary partition). Only in case of (FreeDOS featured) "sorted by drives Drive Letter Assignment" FreeDOS assigns C: to _real_ active partition (see how first loop searches real boot drive). BTW, I think this (slightly) misleading, when (boot) partition from secondary disk becomes C:. Again, I suggest, probably, better to _not_ make it C:, but in main.c:FreeDOSmain() make it default (to allow process (fd)config.sys from it). LG> Let's concentrate on bgfixing before the imminent FD1 release. I not object, but this question may be studied _for future releases_. Isn't? :) --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hallo Bart, if the partition table "loops" (recursive problem), MSDOS just hangs but FreeDOS checks for it and happily uses the partitions that are fine. Of course, there are bugs in MS-DOS that are not present in FreeDOS. But I think that the main problem of the FreeDOS kernel are not bugs, but incompatibilities, e.g. with DOSLFN 0.33. Some of them will never be solved, e.g. the code patterns which Windows 3.1 looks for that Eric mentions will NEVER be there, nor should they be there, of course. Not to mention the fact that the FreeDOS kernel's disk and memory footprints (40K vs. 50K in HMA) are smaller than those of MSDOS 7.10. The HMA footprint doesn't count much if a disk cache is used, because the number of buffers that HMA is filled in doesn't matter then. Microsoft even recommends that an explicitly low number of buffers is used in this case (e.g. 8). The disk footprint counts much more, but not always. For example, if someone wants to embed the kernel into the BIOS (which turned out much more difficult than I thought, as modern BIOSes won't allow ISA option ROMs!) it counts a lot. It counts for boot diskettes too, but not for hard disks. Regards, Lucho --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
On Tue, 10 Aug 2004, Bart Oldeman wrote: I don't think other DOSes route things through int25/int26 either, I tested that a few years ago. It would be a major headache anyway as int25/26 would reset the DOS stack pointer! RBIL explicitly mentions There is yet another thing why DOS cannot use the plain INT-25/26 (maybe some internal counter function): ASSIGN hooks all three INT-21/25/26, hence, rewriting would take place twice. Bye, -- Steffen Kaiser --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hi Tom, > one reason for different behaviour *might* be that smartdrv traps > int25/int26, which is used differently in FreeDOS (not everything is > rooted through it) I don't think other DOSes route things through int25/int26 either, I tested that a few years ago. It would be a major headache anyway as int25/26 would reset the DOS stack pointer! RBIL explicitly mentions 480h 384 BYTEs disk stack (functions greater than 0Ch, INT 25,INT 26) in the SDA. To make a long story of Eric short, later versions hook at the device driver level, ie. what execrh.asm calls for FreeDOS. Searching a bit on google groups: interesting, this link talks about smartdrv but also about config.sys processing order: http://groups.google.com/groups?selm=1993Mar12.001843.20281%40microsoft.com Jen Kilmer posted more informative posts about smartdrv. If you even go further back you find posts from Mark Zbibowski (MZ) e.g. http://groups.google.com/groups?selm=8697%40microsoft.UUCP from 1984. Bart -- "Usenet is a strange place" -- Dennis M. Ritchie --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Win3.x /3 investigations, /s ones, cool 386SWAT debugger
At 06:39 AM 8/9/2004 +0200, Eric Auer wrote: I was able to learn more about Win32 loading in Win 3.1 / German this weekend. For me, the PCI/AGP bus magic for flipping and initializing cards *crashes* with MS HIMEM (3.07, comes with Win3.1) *unless* you also load MS EMM386 (4.44, same source), strange. Whatever. Then in Win3.x itself, there are some checks at - for me - 8028dfec/8028e067/8028e10b: first a lookup table for "known properties" (only contains DOS 4.00 it seems), An unanswered question is are you able to successfully install Windows 3.1 itself over FreeDOS? Attempting to do so here aborts the install while it is within the initial stages of running Windows after preliminary DOS file copies on disk 1 and 2. There is a fatal general protection or stack fault which consistently stops the process. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
At 01:02 PM 8/8/2004 +0300, Luchezar Georgiev wrote: Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS. I've patched it to make it work by modifying the byte at offset 284h from 0 to 1. The X32 DOS extender used in Digital Mars SMAKE had caused problems, so I've patched its offset 4707 from 23h to Bh, but right now when I test it, it works! (So somehow the bug got fixed during the last year ;-) Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or Windows to DOS converter) doesn't work at all in FreeDOS. Alas, I did my patches more than an year ago and I don't remember how I found out these offsets :( More specifically, I would need download access to an application which fails when running under these (or any) extenders, rather than the bare extender itself. Without the context of the CPU instruction or data being patched and what the patch is meant to do, an offset and byte punch value is of no use for externally tracking down and correcting the underlying problem. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
On Mon, 9 Aug 2004, Luchezar Georgiev wrote:
> OK, this is a good attestation, but perhaps if there wasn't the current
> absurd that using MS-DOS® in any way is illegal (unless you've bought a
> legal second hand copy or bought it long ago - hey, I even have a
> Certificate for Authenticity for MS-DOS 6 - just in case the cops intrude
> here! ;-) everybody would use MS-DOS 7.10 which guarantees 100%
> compatibility (and even BUG compatibility :)
Still won't help though. Anyway, from what I heard you can still get
licenses from MS to allow you to redistribute DOS 7.10 ("but you do not
want to know how expensive that is", see
http://pub50.bravenet.com/faq/show.php?usernum=4220517151&catid=3726#q2
). This is from another guy in the data recovery business,
www.diydatarecovery.nl. By the way, he specifically mentioned that if the
partition table "loops" (recursive problem), MSDOS just hangs but FreeDOS
checks for it and happily uses the partitions that are fine.
Not to mention the fact that the FreeDOS kernel's disk and memory
footprints (40K vs. 50K in HMA) are smaller than those of MSDOS 7.10.
Even if MSDOS would have a "Borland museum" style download it still
wouldn't help me. It's redistribution and no restrictions on
commercial/non-commercial use that count here. Most Linux distributions
would also refuse to ship a binary-only "free DOS" with DOSEMU.
Bart
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hallo Tom, the kernel talks directly to int13 and never uses int25 internally. SmartDrive 4/5 doesn't hook Int 25h as SmartDrive 3 hooks Int 13h. Here's a detailed description of the working principles of SmartDrive 4 and 5 - http://support.microsoft.com/?id=83325 I don't see any new features in keDANGEROUS either. Completely new no, but for example CONFIG.SYS menu processing has been improved (menu, prompts for each INSTALL command at the time of actual loading and not beforehand like in ROCK-SOLID-STONED ;) Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Luchezar, >> one reason for different behaviour *might* be that smartdrv traps >> int25/int26, which is used differently in FreeDOS (not everything is >> rooted through it) > What isn't routed through it? the kernel talks directly to int13 and never uses int25 internally. >> a) he implemented FAT32 >> b) he implemented FAT32 virtually bugfree on first try >>without 25 'please everybody test this' alpha releases. >>he probably tested it himself before publishing. >> c) he implemented FAT32 - and virtually every single line he changed >>was necessary to do the job. no additional noise at all. >>he probably optimized for smallest diff. > Great. So Victor's work can be an excellent example of how the job should > be done, indeed. YES. YES. YES. BTW: michael devore works exactly the same way. >> bug fixing will probably never stop, but squeezing single byte out of it >> is IMO a complete waste of time. > When there are important bugs to fix - yes. But Arkady notices bugs > exactly while optimising! ;-) AFAIR, he found *one* bug, that *might* have real world significance (ret_AH), which was introduced lately by some optimizations by Bart. >> 4 serious real world bugs; so I wouldn't call my branch dead. > You're right. It's not dead. Good job, Tom! Still, there's no progress in > anything but bug fixing - "the call of the day". I don't see any new features in keDANGEROUS either. > By the way, will all your changes go into the "stable" branch? hope so - at least they get posted here. and the source is available on request anyway. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hallo Tom,
I certainly didn't wait to say this until he's absent
Sure. The eternal dispute continues forever! ;-)
one reason for different behaviour *might* be that smartdrv traps
int25/int26, which is used differently in FreeDOS (not everything is
rooted through it)
What isn't routed through it?
I wouldn't hold my breath if I'd like to see this bug fixed.
OK. We'll see. Who knows, perhaps some day I'll try it myself.
a) he implemented FAT32
b) he implemented FAT32 virtually bugfree on first try
without 25 'please everybody test this' alpha releases.
he probably tested it himself before publishing.
c) he implemented FAT32 - and virtually every single line he changed
was necessary to do the job. no additional noise at all.
he probably optimized for smallest diff.
Great. So Victor's work can be an excellent example of how the job should
be done, indeed.
Speaking about Arkady, however, there are some circumstances which can
hinder his testing. He has only a 80386 PC with a small hard disk and
Windows 3.1. And he has no Internet connection at all!
and while I see no purpose in what he's doing in general, I look at his
changes, and what makes sense (to me), goes into my branch as well.
I see. That's good.
bug fixing will probably never stop, but squeezing single byte out of it
is IMO a complete waste of time.
When there are important bugs to fix - yes. But Arkady notices bugs
exactly while optimising! ;-)
you may have seen that while I stopped to work regularily on the kernel,
I probably made Stev Gibson happy with FreeDOS (stacks=9,256), made
FreeDOS load DD1000XX.SYS, made freedos kernel load Intel Pro1000
network driver, and found one reason for panic('too many fnodes in use')
4 serious real world bugs; so I wouldn't call my branch dead.
You're right. It's not dead. Good job, Tom! Still, there's no progress in
anything but bug fixing - "the call of the day". By the way, will all your
changes go into the "stable" branch? It's good that the "unstable" branch
benefits from your work too and has all your bug fixes integrated too.
Regards,
Lucho
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Luchezar,
> I use IOCTL every day and that's how I found that the XMSDSK lock bug that
> prevented SCANDISK from checking the XMSDSK drive had come back as Arkady
> moved the lock check too low. Without anger, I wrote a patch for this, he
> accepted it with some minor changes, and - voila! Problem solved :)
well - good to see that someone fixes some of these optimization
induced bugs.
> I don't even know what MS-LANMAN is, and I guess I don't use it ;-)
accessing files on a networked drive on a MS Server.
> Sure, but this can be said for the "stable" version too. In fact, Arkady
> hasn't touched the file system processing part of the kernel at all. So
> the two kenels don't differ very much internally.
except for 2 changed lines.
> You already wrote this, but (1) I'd prefer the "innocent presumption", to
> the "guilty presumption" towards him,
it's the guilty assumption about *any* change, that I didn't peer
review myself.
> and (2) I think that accusing him
> when he's absent to defend himself is not ethical.
I certainly didn't wait to say this until he's absent
>> smartdrv is an entirely different beast, that knows a lot about the
>> underlying DOS; expecting compatibility with SMARTDRV is probably beyond
>> the requitrements of this project (wouldn't hurt for sure, but not
>> *required* )
> I agree, but as I use it every day with FreeDOS, I think that besides the
> obscure incompatibility with its delayed write feature on FAT32 that I
> reported (which may well be a bug in SMARTDRV itself that doesn't reveal
> in MS-DOS!) I haven't noticed any other problems with it under FreeDOS.
one reason for different behaviour *might* be that smartdrv traps
int25/int26, which is used differently in FreeDOS (not everything is
rooted through it)
>> *very* easy to fix if you have softice loaded.
>>
>> boot normal.
>> softice>bpint 13 ah=2
>> softice>bpr 0:0 a000:0 t
>> softice>boot (which reboots the machine, but leaves s-ice
>> softice>active, and you can step booting !!)
> Yes, the great SoftICE! Sweating on the scene is good, but now I'd prefer
> to be among the public and see if anyone else can sweat instead of me ;-)
> Let's give a chance to the young generation ;-)
I wouldn't hold my breath if I'd like to see this bug fixed.
>> It's been a pleasure for me to work with Bart, you and the nearly
>> forgotten victor who gave us FAT32 in a very ompressive way.
> Victor Vlasenko? Can you write more about this remarkable achievement of
> his? I'm sure that such people may not be, can not be, and are not
> forgotten!
a) he implemented FAT32
b) he implemented FAT32 virtually bugfree on first try
without 25 'please everybody test this' alpha releases.
he probably tested it himself before publishing.
c) he implemented FAT32 - and virtually every single line he changed
was necessary to do the job. no additional noise at all.
he probably optimized for smallest diff.
>> It's good enough for what I do, and I take care that it remains that way.
> So this is your role since you stopped active kernel development - to act
> as a kind of Kerberos, and thus prevent the only person who still actively
> works on the kernel from having impact on it!
yes.
and while I see no purpose in what he's doing in general, I look at
his changes, and what makes sense (to me), goes into my branch as well.
> Which means that the kernel development has virtually stopped now. How
> sad...
bug fixing will probably never stop, but squeezing single byte out of
it is IMO a complete waste of time.
you may have seen that while I stopped to work regularily on the
kernel, I probably made Stev Gibson happy with FreeDOS (stacks=9,256),
made FreeDOS load DD1000XX.SYS, made freedos kernel load Intel Pro1000
network driver, and found one reason for panic('too many fnodes in use')
4 serious real world bugs; so I wouldn't call my branch dead.
tom
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hallo Tom, I have an idea - why not call the UNSTABLE branch DANGEROUS (but still moving!) and STABLE branch - ROCK-SOLID (like a stone, but also static and even almost dead as stone ;-) Joking of course... that you use it doesn't mean there are no news bugs. e.q. the complete ioctl was 100% mixed/changed/... how many ioctl's are you using - not every day, but at least once per month? I use IOCTL every day and that's how I found that the XMSDSK lock bug that prevented SCANDISK from checking the XMSDSK drive had come back as Arkady moved the lock check too low. Without anger, I wrote a patch for this, he accepted it with some minor changes, and - voila! Problem solved :) do you use MS-LANMAN networking (at least once per month)? etc... I don't even know what MS-LANMAN is, and I guess I don't use it ;-) just because YOU don't find bugs (old or new) doesn't mean there are no (old or new) bugs. Sure, but this can be said for the "stable" version too. In fact, Arkady hasn't touched the file system processing part of the kernel at all. So the two kenels don't differ very much internally. in particular (by your own finding) the new SYS is buggy (if loadseg != 60), but you only found out after using SYS (at least once). True. this shall not imply the arkady introduces new bugs every other day (although I've seem a couple of OOPS's); it's simply that I can't verify (perr review) what he changed simply because his stupid 'change everything' attitude. and so I won't touch the arkady branch with a 3 meter long stick. You already wrote this, but (1) I'd prefer the "innocent presumption", to the "guilty presumption" towards him, and (2) I think that accusing him when he's absent to defend himself is not ethical. if you are using (and distributing) SMARTDRV, you can also distribute msdos xx. I don't distribute SMARTDRV - Microsoft did this for many years in their SOFTLIB FTP directory, and now when they no longer offer it, there are mirrors from which I can still be downloaded. smartdrv is an entirely different beast, that knows a lot about the underlying DOS; expecting compatibility with SMARTDRV is probably beyond the requitrements of this project (wouldn't hurt for sure, but not *required* ) I agree, but as I use it every day with FreeDOS, I think that besides the obscure incompatibility with its delayed write feature on FAT32 that I reported (which may well be a bug in SMARTDRV itself that doesn't reveal in MS-DOS!) I haven't noticed any other problems with it under FreeDOS. you didn't report, if the same problem happens with LBACACHE. Because since I found out that SmartDrive is compatible with FreeDOS, I don't use LBACACHE anymore *very* easy to fix if you have softice loaded. boot normal. softice>bpint 13 ah=2 softice>bpr 0:0 a000:0 t softice>boot (which reboots the machine, but leaves s-ice softice>active, and you can step booting !!) Yes, the great SoftICE! Sweating on the scene is good, but now I'd prefer to be among the public and see if anyone else can sweat instead of me ;-) Let's give a chance to the young generation ;-) not 'complex tasks'. for tasks involving LFNDOS and creating new files; creating a lot of them just makes it more probable to happen. OK, perhaps I generalised unnecessarily. As Alexandre Dumas (father) put it, "every generalisation is dangerous, even this one" (one of my favourite recursive thoughts ;-) It's been a pleasure for me to work with Bart, you and the nearly forgotten victor who gave us FAT32 in a very ompressive way. Victor Vlasenko? Can you write more about this remarkable achievement of his? I'm sure that such people may not be, can not be, and are not forgotten! For me, it's THE dos today - and I can affort to distribute a junk DOS even less then Steve Gibson. OK, this is a good attestation, but perhaps if there wasn't the current absurd that using MS-DOS® in any way is illegal (unless you've bought a legal second hand copy or bought it long ago - hey, I even have a Certificate for Authenticity for MS-DOS 6 - just in case the cops intrude here! ;-) everybody would use MS-DOS 7.10 which guarantees 100% compatibility (and even BUG compatibility :) It's good enough for what I do, and I take care that it remains that way. So this is your role since you stopped active kernel development - to act as a kind of Kerberos, and thus prevent the only person who still actively works on the kernel from having impact on it! Which means that the kernel development has virtually stopped now. How sad... Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [
Re: [Freedos-kernel] More kernel bugs and incompatibilities
>> Remember that Steve Gibson went round trip back to FreeDOS after >> evaluating several other DOSes so this means that FreeDOS can't be that >> bad :) a) other DOS's were just too expensive b) his problems seem to have been entirely related to the 2033 kernel default stacksize of 128 byte c) he uses VERY few DOS functions; IMO Spinrite might even work with ke2028 (which had still MANY bugs) >> I just hope that if I ever need spinrite myself Steve can pay >> back by giving me a free copy ;) I's sure he'll be happy to send you a license; I'm proud owner of it already. > ;-) ;-) ;-) You're right. It's not bad at all. good *enough* for me (at least the part I use) > You know I like it, but I'm > afraid the remaining bugs (I don't mean just "my" bugs of course) may play > bad jokes on us in the future if not fixed. Besides, Steve can't afford to > use any DOS illegally. So if I were him, I'd choose FreeDOS too. it's just the question, if it's good enough for the job at hand. if 'yes' - use it. if 'no' - it's far too expensive, even if free. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Luchezar, >> or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main >> stream kernel should concentrate on FIXING bugs, rather then introducing >> new ones. > 100% agreed. Since I use "unstable" kernel every day in practice, I think > it has no more bugs than the "stable" one. that you use it doesn't mean there are no news bugs. e.q. the complete ioctl was 100% mixed/changed/... how many ioctl's are you using - not every day, but at least once per month? do you use MS-LANMAN networking (at least once per month)? etc... just because YOU don't find bugs (old or new) doesn't mean there are no (old or new) bugs. in particular (by your own finding) the new SYS is buggy ( if loadseg != 60), but you only found out after using SYS (at least once). this shall not imply the arkady introduces new bugs every other day (although I've seem a couple of OOPS's); it's simply that I can't verify (perr review) what he changed simply because his stupid 'change everything' attitude. and so I won't touch the arkady branch with a 3 meter long stick. > But during the last few weeks I > noticed several more bugs and incompatibilities present in both "stable" > and "unstable" branches, most of them extremely difficult to fix, namely: > 1. While copying a directory tree containing many LFNs *without* DOSLFN > loaded and *with* delayed write of SMARTDRV in a FAT32 directory, many > invalid directory entries are created, which consist of parts of the > contents of the copied files. Turning delayed write off makes the bug > vanish. If FreeDOS ir replaced by MS-DOS or if copying to a FAT16 > directory under FreeDOS, there is no bug. if you are using (and distributing) SMARTDRV, you can also distribute msdos xx. smartdrv is an entirely different beast, that knows a lot about the underlying DOS; expecting compatibility with SMARTDRV is probably beyond the requitrements of this project (wouldn't hurt for sure, but not *required* ) you didn't report, if the same problem happens with LBACACHE. > 3. If load segment (/L option) was different than 60h, bootstrap causes a > read error during the loading of the kernel if it's longer than about 62 > KB. The exact value of the load segment doesn't matter, and the bug > reveals for *any* value other than 60h. *very* easy to fix if you have softice loaded. boot normal. softice>bpint 13 ah=2 softice>bpr 0:0 a000:0 t softice>boot (which reboots the machine, but leaves s-ice softice>active, and you can step booting !!) > 4. SYS hangs up or causes an invalid opcode at the time of reading the > boot sector of my ATA flash cards, if compiled by anything than Watcom. > Non-Watcom versions of SYS work on all other drives. again - softice should be your friend. > So, as a prospective user of the kernel, after contributing to it for more > than an year, I can conclude than it's good enough for simpler tasks not > involving writing a lot of long named files on a FAT32 partition. For more > complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more > suitable. not 'complex tasks'. for tasks involving LFNDOS and creating new files; creating a lot of them just makes it more probable to happen. > Thank you for your attention. It's time for me to concentrate on other > tasks. It's been a pleasure for me to work with you guys. I hope that > FreeDOS will be THE DOS one day. But hardly "real soon now"... It's been a pleasure for me to work with Bart, you and the nearly forgotten victor who gave us FAT32 in a very ompressive way. For me, it's THE dos today - and I can affort to distribute a junk DOS even less then Steve Gibson. It's good enough for what I do, and I take care that it remains that way. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM BitMixer incompatibility
Hallo Eric, could you file the list of problems which are mentioned in this thread as Bugzilla entries? I already filled in all the 5 bugs (3 kernel and 2 SYS bugs) I reported but the DOS extender bugs. I believe some RTM did work - and Lucho found a very small binary patch to fix 32RTM - so Lucho, please try to remember what you patched and why, thanks. Just remembered! :) If 32RTM is loaded without the so-called "BitMixer", it works (e.g. load 32RTM -X and run TLIB - it works now, then unload RTM -U). So I had changed the byte at offset 284h that controls whether "BixMixer" is enabled from 0 (enabled) to 1 (disabled). Now when I run a Borland program that uses 32RTM, 32RTM gets loaded without "BitMixer", even though the Borland program doesn't explicitly use -X. Unfortunately I don't have the slightest idea what "BitMixer" is... :( Hope this helps. Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Copyright message, SFT vs F-node
Hallo Bart, Honestly I believe you're right here -- the issue is that changing copyright messages without agreement of the original author is a bit shaky IMHO. If you just get Pat's go ahead for the change then I'm all for it. OK. If Pat reads this list, perhaps he can write here if he approves the removal of this phrase? FreeDOS kernel build 2035a-WHATEVER. Copyright... "FreeDOS kernel build 2035a-DEADLY_DANGEROUS! Copyleft Pasquale J. Villani & the FreeDOS Project" ;-) This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to redistribute it under certain conditions; press F1 for details. I'd prefer "This kernel has ABSOLUTELY NO WARRANTY and is licensed under the GNU Public License". No need to play copyleft license games at so solemn moments like FreeDOS startup! ;-) Well those can be dealt with, a bit awkward though. IIRC Win98 stores these clusters in the various "SHARE" related fields. You mean, fields at offsets 2B (BYTE FAR *sft_bshare), 2F (WORD sft_mach), and 37 (BYTE FAR *sft_ifsptr)? Not sure how many DOS programs (if any) depend on these on FAT32 though. Maybe SMARTDRV and DOSLFN or LFNDOS? I don't know. IMHO easiest to copy those fields across that matter, and then then delete them from the persistent fnodes. i.e. the far fnodes would be able to become different from the near ones, and xlt_fd() and save_far_fnode() would no longer use "fmemcpy" but copy individual fields. A possible solution, indeed. But it won't allow programs like HiNTOS which modify the SFT to work. Another difference is the way that directory entries are addressed: SFT's use (sector number, entry in sector), where fnodes use (starting cluster number of dir, entry in directory). And if you don't keep the whole directory entry in memory then dir_write would have to become read/modify/write instead of simply "write". We can leave the directory entry structure in the F-node. It helps a lot indeed. Takes a fair bit of time of course, it just depends how motivated one is. Exactly. Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello! Jeremy: as for patch starting this discussion, I'll look at it when I get home from work tommorrow afternoon; anyway I've got to get ready Thanks for your commitment to maintain the kernel now when it's branched and thus hard to maintain Aitor: Could you please fill bugzilla entries with these please? Done. See bugs 1817 to 1821. A pitty to hear you go, or am I misinterpretating your words? They were misty enough to be understood. I don't leave FreeDOS but won't likely work on it anymore Michael: I'd like to know of any DOS extender compatibility problems as I have looked carefully for them. All the big name extenders and several 2nd or 3rd tier ones, work fine for all the applications tested. Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS. I've patched it to make it work by modifying the byte at offset 284h from 0 to 1. The X32 DOS extender used in Digital Mars SMAKE had caused problems, so I've patched its offset 4707 from 23h to Bh, but right now when I test it, it works! (So somehow the bug got fixed during the last year ;-) Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or Windows to DOS converter) doesn't work at all in FreeDOS. Alas, I did my patches more than an year ago and I don't remember how I found out these offsets :( Bart: Of course this is since the DOSLFN author apparently isn't interested in running it on FreeDOS and most FreeDOS developers aren't interested enough in DOSLFN (it's useless on networked drives for instance, which makes it almost useless in DOSEMU!). As Tom suggests, it's best to integrate LFN services into the kernel. The it can be distributed in two versions: LFN-enabled and non-LFN-enabled. But the task is rather complex as you know :-( Same for SMARTDRV, anyway why SMARTDRV if we have LBACACHE? Because it works better for me. They're very different beasts, using entirely different principles In any case these "China DOS Union" guys seem to think they can freely redistribute MSDOS 7.10 so if they think that's all fine and it works for what they want then I wish them good luck. Actually, the kernel they distribute is almost twice as small as the original kernel, because they managed to remove the embedded logo bitmap and other Windows-only code/data. If you have a chance to find Wengier's boot disk, take a look at it. Very good job! It's the best boot disk I've seen. PC-DOS 7.1 never seems to have been officially released but just appears to be what's used on Norton Ghost's boot disks. It can be freely downloaded with the trial Symantec Ghost version from the Symantec site. However, to get a DOS kernel consisting of only the IBMBIO and IBMDOS files and two boot sectors without even a SYS utility, one must download the whole 90 MB :( Latest build: 1.29 dated 9 November 2003. Remember that Steve Gibson went round trip back to FreeDOS after evaluating several other DOSes so this means that FreeDOS can't be that bad :) I just hope that if I ever need spinrite myself Steve can pay back by giving me a free copy ;) ;-) ;-) ;-) You're right. It's not bad at all. You know I like it, but I'm afraid the remaining bugs (I don't mean just "my" bugs of course) may play bad jokes on us in the future if not fixed. Besides, Steve can't afford to use any DOS illegally. So if I were him, I'd choose FreeDOS too. Sorry for this rather long message of mine. Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: [problems with DOSLFN and SMARTDRV and some obscure problems for nonstandard configurations] > So, as a prospective user of the kernel, after contributing to it for more > than an year, I can conclude than it's good enough for simpler tasks not > involving writing a lot of long named files on a FAT32 partition. For more > complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more > suitable. You can find a good comparison betweent the different DOS > versions on the page of Wengier Wu (åææ, China DOS Union) > http://newdos.yginfo.net/dosfat32.htm (page is in English). Of course this is since the DOSLFN author apparently isn't interested in running it on FreeDOS and most FreeDOS developers aren't interested enough in DOSLFN (it's useless on networked drives for instance, which makes it almost useless in DOSEMU!). Same for SMARTDRV, anyway why SMARTDRV if we have LBACACHE? In any case these "China DOS Union" guys seem to think they can freely redistribute MSDOS 7.10 so if they think that's all fine and it works for what they want then I wish them good luck. PC-DOS 7.1 never seems to have been officially released but just appears to be what's used on Norton Ghost's boot disks. Remember that Steve Gibson went round trip back to FreeDOS after evaluating several other DOSes so this means that FreeDOS can't be that bad :) I just hope that if I ever need spinrite myself Steve can pay back by giving me a free copy ;) Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
> >> nor removal of phrases like "All Rights Reserved." that are useless now > > Pat sent an email to this list -- here's your chance if you really care > > about this! > > The Buenos Aires Convention (1911) that required this was superseded by > the Universal Copyright and Berne conventions. More on this at > http://www.cni.org/Hforums/cni-copyright/1999-01/0196.html Honestly I believe you're right here -- the issue is that changing copyright messages without agreement of the original author is a bit shaky IMHO. If you just get Pat's go ahead for the change then I'm all for it. Note that the GPL doesn't use "all rights reserved", it gives an example like Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. FreeDOS could, say, show the full message if you press a certain F key(as it waits for F5/F8 anyway), like this FreeDOS kernel build 2035a-WHATEVER. Copyright... This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to redistribute it under certain conditions; press F1 for details. > > It's more difficult than a simple "removal". If you'd simply replace all > > fnode references with SFT's you'll see a substantial increase in code > > size (because SFT's are "FAR"). Also fnodes are used in situations where > > SFTs can't do the job (dir operations). > > You're right - there are for example cluster fields that must be 32 bit > and not 16 bit for FAT32. Well those can be dealt with, a bit awkward though. IIRC Win98 stores these clusters in the various "SHARE" related fields. Not sure how many DOS programs (if any) depend on these on FAT32 though. Maybe SMARTDRV and DOSLFN or LFNDOS? > > However -- replacing the use of the persistent fnodes that are now in > > the HMA by SFTs is a good idea IMHO. This is just a question of time, it > > may never happen but it can happen if somebody does it and it works well. > > I see. What about including the SFT in the F-node structure and removing > all duplicating fields? As all SFTs are pointed to by a linked list, I > think that this is possible. What do you think? IMHO easiest to copy those fields across that matter, and then then delete them from the persistent fnodes. i.e. the far fnodes would be able to become different from the near ones, and xlt_fd() and save_far_fnode() would no longer use "fmemcpy" but copy individual fields. Another difference is the way that directory entries are addressed: SFT's use (sector number, entry in sector), where fnodes use (starting cluster number of dir, entry in directory). And if you don't keep the whole directory entry in memory then dir_write would have to become read/modify/write instead of simply "write". Takes a fair bit of time of course, it just depends how motivated one is. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (åææ, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). It gives to me a 404... (though the link seems interesting enough). http://www.google.com.br/search?q=cache:PIFhy-PkmJ0J:newdos.yginfo.net/dosfat32.htm+dosfat32&hl=pt Alain --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hi Lucho, Luchezar Georgiev escribiÃ: 100% agreed. Since I use "unstable" kernel every day in practice, I think it has no more bugs than the "stable" one. But during the last few weeks I noticed several more bugs and incompatibilities present in both "stable" and "unstable" branches, most of them extremely difficult to fix, namely: Could you please fill bugzilla entries with these please? So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (åææ, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). It gives to me a 404... (though the link seems interesting enough). Thank you for your attention. It's time for me to concentrate on other tasks. It's been a pleasure for me to work with you guys. I hope that FreeDOS will be THE DOS one day. But hardly "real soon now"... A pitty to hear you go, or am I misinterpretating your words? Aitor --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
At 09:19 PM 8/7/2004 +0300, Luchezar Georgiev wrote: Needless to say that these bugs and incompatibilities are only a small part of the whole picture. You already know the DOS extender compatibility problems I've reported earlier. Perhaps it's also worth mentioning that writing files under DOSLFN is significantly slower than under MS-DOS. I'd like to know of any DOS extender compatibility problems as I have looked carefully for them. All the big name extenders and several 2nd or 3rd tier ones, work fine for all the applications tested. Eric Auer remarks that DOS/4GW still has compatibility problems in Bugzilla, but he has failed to demonstrate any of them to me. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Luchezar Georgiev wrote: Hallo Bart, ... #define BUILD "2035a" #define SUB_BUILD "-UNSTABLE" oops, I see it should be BUILD 2035 with SUB_BUILD a-UNSTABLE I don't know why some people started calling 2035a-UNSTABLE plain 2035a... perhaps just too lazy to type "-UNSTABLE". But it reports that on the screen right? Any conversation regarding UNSTABLE should refer to it as UNSTABLE or 'development branch' and optionally the cvs (may equal build) date if not the latest sources. Stable series should be refered to either by its version (only valid for released ones) or also by its cvs date if not latest. Sure. It reports quite a lot of things. But if BUILD is defined as 2035 (Bart) and 2035a (Arkady),it may be used for identification too. I hate the build & version dualism (e. g. version should be 2.0.35), but I know There is not a Bart and Arkady kernel, there is only a stable and development branch. Because Arkady likes to change lots, his patches are most easily worked into the dev branch, and because Tom/Bart like fewer changes, there's are more easily worked with the stable branch. As soon as I get time (maybe next week, this week I haven't even had time for sleep) I will sync in some of Arkady's fixes into to stable and bump both up to 2035b. ... By the way, how is Arkady? Has anybody heard of him recently? I begin to worry about him! No, I had to check sourceforge archives to make sure I was still getting Kernel mailings, its been so quiet. Hopefully all's well and he is just taking a break to work on other things. Regards, Lucho (as for patch starting this discussion, I'll look at it when I get home from work tommorrow afternoon; anyway I've got to get ready ...) Jeremy --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] More kernel bugs and incompatibilities
Hello Tom et al, or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main stream kernel should concentrate on FIXING bugs, rather then introducing new ones. 100% agreed. Since I use "unstable" kernel every day in practice, I think it has no more bugs than the "stable" one. But during the last few weeks I noticed several more bugs and incompatibilities present in both "stable" and "unstable" branches, most of them extremely difficult to fix, namely: 1. While copying a directory tree containing many LFNs *without* DOSLFN loaded and *with* delayed write of SMARTDRV in a FAT32 directory, many invalid directory entries are created, which consist of parts of the contents of the copied files. Turning delayed write off makes the bug vanish. If FreeDOS ir replaced by MS-DOS or if copying to a FAT16 directory under FreeDOS, there is no bug. 2. The same test above, but *with* DOSLFN loaded, if done with the "COPY /S" command of 4DOS, which supports LFNs, causes only lost clusters and all the target files are in zero length. If done by another program which supports LFNs, for example FM, there is no bug. (FM is a Bulgarian all-in-one file manager / file editor / disk editor / CD player / calculator / Tetris / etc.etc.). Again, if FreeDOS is replaced by MS-DOS or if copying to a FAT16 directory under FreeDOS - no bug. 3. If load segment (/L option) was different than 60h, bootstrap causes a read error during the loading of the kernel if it's longer than about 62 KB. The exact value of the load segment doesn't matter, and the bug reveals for *any* value other than 60h. 4. SYS hangs up or causes an invalid opcode at the time of reading the boot sector of my ATA flash cards, if compiled by anything than Watcom. Non-Watcom versions of SYS work on all other drives. 5. DOSLFN 0.33, run off a XMSDSK RAM-disk, doesn't show the files there with "dir" in FreeDOS, but works in MS-DOS 7.10. DOSLFN 0.32 works everywhere. DOSLFN 0.33 works on any other disk in FreeDOS Needless to say that these bugs and incompatibilities are only a small part of the whole picture. You already know the DOS extender compatibility problems I've reported earlier. Perhaps it's also worth mentioning that writing files under DOSLFN is significantly slower than under MS-DOS. So, as a prospective user of the kernel, after contributing to it for more than an year, I can conclude than it's good enough for simpler tasks not involving writing a lot of long named files on a FAT32 partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and ROM-DOS 7.1 are more suitable. You can find a good comparison betweent the different DOS versions on the page of Wengier Wu (åææ, China DOS Union) http://newdos.yginfo.net/dosfat32.htm (page is in English). Thank you for your attention. It's time for me to concentrate on other tasks. It's been a pleasure for me to work with you guys. I hope that FreeDOS will be THE DOS one day. But hardly "real soon now"... Regards, Lucho (ÐÑÑÐ) --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Bart Oldeman escribió: By the way, how is Arkady? Has anybody heard of him recently? I begin to worry about him! No idea. A bit silent here indeed. True. Maybe he is on a vacation? Aitor --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
Hello Luchezar, > I didn't know that there are TWO kernel builds called 2035a... Perhaps you > should call yours 2035b where b = Bart (a = Arkady ;-) or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main stream kernel should concentrate on FIXING bugs, rather then introducing new ones. tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hello Luchezar, > OK, long live the holy conservatism that saves the FreeDOS world > from the Arkadifying hell ;-G By 100% agreed tom --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hello Bart, Actually a couple of years ago it was build 1937 for version 1.0.2 ;) Wow! Well, I hope that it can be 2.0.60 for build 2060 in just a couple of years ;-) nor removal of phrases like "All Rights Reserved." that are useless now Pat sent an email to this list -- here's your chance if you really care about this! The Buenos Aires Convention (1911) that required this was superseded by the Universal Copyright and Berne conventions. More on this at http://www.cni.org/Hforums/cni-copyright/1999-01/0196.html It's more difficult than a simple "removal". If you'd simply replace all fnode references with SFT's you'll see a substantial increase in code size (because SFT's are "FAR"). Also fnodes are used in situations where SFTs can't do the job (dir operations). You're right - there are for example cluster fields that must be 32 bit and not 16 bit for FAT32. However -- replacing the use of the persistent fnodes that are now in the HMA by SFTs is a good idea IMHO. This is just a question of time, it may never happen but it can happen if somebody does it and it works well. I see. What about including the SFT in the F-node structure and removing all duplicating fields? As all SFTs are pointed to by a linked list, I think that this is possible. What do you think? An altogether different subject, and you know very well why. You've made plenty of patches yourself and most of them went in. For which I thank you, and I hope that in time, more Arkady's patches will be accepted too. No idea. A bit silent here indeed. Arkady, please respond if you read this. How are you? Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hello Lucho, > the build & version dualism (e. g. version should be 2.0.35), but I know > that neither this, Actually a couple of years ago it was build 1937 for version 1.0.2 ;) > nor removal of phrases like "All Rights Reserved." that > are useless now, Pat sent an email to this list -- here's your chance if you really care about this! > nor removal of the f-nodes that prevent programs which > modify SFTs from working, will ever happen. It's more difficult than a simple "removal". If you'd simply replace all fnode references with SFT's you'll see a substantial increase in code size (because SFT's are "FAR"). Also fnodes are used in situations where SFTs can't do the job (dir operations). However -- replacing the use of the persistent fnodes that are now in the HMA by SFTs is a good idea IMHO. This is just a question of time, it may never happen but it can happen if somebody does it and it works well. > OK, long live the holy > conservatism that saves the FreeDOS world from the Arkadifying hell ;-G An altogether different subject, and you know very well why. You've made plenty of patches yourself and most of them went in. > By the way, how is Arkady? Has anybody heard of him recently? I begin to > worry about him! No idea. A bit silent here indeed. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Versions and builds, conservatism
Hallo Bart, #define BUILD "2035" #define SUB_BUILD "a" #define KERNEL_VERSION_STRING "1.1.35" /*#REVISION_MAJOR "." #REVISION_MINOR "." #REVISION_SEQ */ #define KERNEL_BUILD_STRING "2035a" /*#BUILD SUB_BUILD */ #define BUILD "2035a" #define SUB_BUILD "-UNSTABLE" #define KERNEL_VERSION_STRING "1.1.35a" /*#REVISION_MAJOR "." #REVISION_MINOR "." #REVISION_SEQ */ #define KERNEL_BUILD_STRING "2035a-UNSTABLE" /*#BUILD SUB_BUILD */ I don't know why some people started calling 2035a-UNSTABLE plain 2035a... perhaps just too lazy to type "-UNSTABLE". But it reports that on the screen right? Sure. It reports quite a lot of things. But if BUILD is defined as 2035 (Bart) and 2035a (Arkady),it may be used for identification too. I hate the build & version dualism (e. g. version should be 2.0.35), but I know that neither this, nor removal of phrases like "All Rights Reserved." that are useless now, nor removal of the f-nodes that prevent programs which modify SFTs from working, will ever happen. OK, long live the holy conservatism that saves the FreeDOS world from the Arkadifying hell ;-G By the way, how is Arkady? Has anybody heard of him recently? I begin to worry about him! Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: > > This is against exeflat.c of "2035a-UNSTABLE". Neither 2035a (i.e. CVS > > HEAD) nor 2035 have this problem. > > I didn't know that there are TWO kernel builds called 2035a... Perhaps you > should call yours 2035b where b = Bart (a = Arkady ;-) I was just reflecting what it reports from version.h -- that's the info Jeremy put in, neither Arkady nor myself. In CVS HEAD I see: #define BUILD "2035" #define SUB_BUILD "a" #define KERNEL_VERSION_STRING "1.1.35" /*#REVISION_MAJOR "." #REVISION_MINOR "." #REVISION_SEQ */ #define KERNEL_BUILD_STRING "2035a" /*#BUILD SUB_BUILD */ but in CVS UNSTABLE I see #define BUILD "2035a" #define SUB_BUILD "-UNSTABLE" #define KERNEL_VERSION_STRING "1.1.35a" /*#REVISION_MAJOR "." #REVISION_MINOR "." #REVISION_SEQ */ #define KERNEL_BUILD_STRING "2035a-UNSTABLE" /*#BUILD SUB_BUILD */ I don't know why some people started calling 2035a-UNSTABLE plain 2035a... perhaps just too lazy to type "-UNSTABLE". But it reports that on the screen right? Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035-Arkady) start segment must be variable
Hallo Bart, This is against exeflat.c of "2035a-UNSTABLE". Neither 2035a (i.e. CVS HEAD) nor 2035 have this problem. I didn't know that there are TWO kernel builds called 2035a... Perhaps you should call yours 2035b where b = Bart (a = Arkady ;-) Regards, Lucho --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] exeflat (2035a) start segment must be variable
On Sat, 7 Aug 2004, Luchezar Georgiev wrote: > exeflat.c of build 2035a (not 2035) has a problem. The start segment is an > argument so it's a variable and its value - 2 must be loaded into DI > instead of the constant 0x5E. Here's a fix: > > --- cvs\kernel\utils\exeflat.c2004-07-09 04:16:30.0 +0200 > +++ src\kernel\utils\exeflat.c2004-08-07 13:16:38.0 +0200 > @@ -303,6 +303,7 @@ > 0x33,0xFF,/* 27 xor di,di */ > 0xFF,0xE7,/* 29 jmp di; jmp 0 */ > }; > +*(short *)&trailer[3] = start_seg - 2; > *(short *)&trailer[15] = (short)size + 0x20; > *(short *)&trailer[20] = start_seg + header.exInitSS; > *(short *)&trailer[25] = header.exInitSP; Hi Lucho, This is against exeflat.c of "2035a-UNSTABLE". Neither 2035a (i.e. CVS HEAD) nor 2035 have this problem. Bart --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] daily tarballs no longer daily
Bart Oldeman wrote: Cron was disabled on SF, see http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1 so the daily tarballs are no longer that (in fact the last one is from July 12). Somebody would have to manually update or run a cron job from an outside machine. Or just wait until SF sorts out the problem. Well, that explains why the http://freedos.sourceforge.net/freedos.html mirror hasn't been working. I had to manually run the update last night to re-sync it. -jh -- _ This email message has been automatically encrypted using ROT-26. NOTE: I WILL BE AWAY FROM EMAIL (ON VACATION) AUG 6-24. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit - UNSTABLE
Hi Arkady, IFM> http://www.fdos.org/bootdisks/autogen/source_core.UNSTABLE.zip BTW, PKZIP can't extract file, if its name contains more than one dot. :( Now I again should binary edit this archive to replace kernel.UNSTABLE.source.zip by something like kernel-UNSTABLE-source.zip... This one can: Official Info-Zip May 2004 release unz551x3.exe26-May-2004 23:22 244K http://sunsite.cnlab-switch.ch/ftp/mirror/infozip/MSDOS/unz551x3.exe I send the URL because I know you need it ;-) Alain --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/bin autoexec.bat,1.6,1.6.2.1
On Sun, 25 Jul 2004, Kenneth J. Davis wrote: > This is largely a cvs issue regarding line endings. Several batch > files were committed with \r\n line endings from a non-EOL converting > cvs client, as such on those clients they check out as \r\n, but on > clients (such as I use) they are converted to DOS EOLs resulting in > \r\r\n. This screws up FreeCom, many editors, and any subsequent > commits show the whole file changed. The problem is now that when I checkout the batch files have \n line endings, which also screw up FreeCom. I intentionally put the batch files in with \r\n line endings because someone who checked out on Linux asked me -- most compilers work well with LF-ended C files but .bat files *have* to be CRLF for both MS and FD command.com. This is the reason why (as Martin Stromberg explained) in the DJGPP CVS repository all C files are LF but .bat files are CRLF, so I simply copied that. Seems like a catch-22 here, well at least FreeCOM could be fixed. To implement \r\n<=>\n translation in DOSEMU seems very error prone to me. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
El lun, 26-07-2004 a las 14:09, Bart Oldeman escribió: > No. The whole point of calling int2f/ax=12xx is that this stack setup is > bypassed. > > i.e. *without* any swapping in NLSFUNC you'd have > int21/ah=38 => DOS switches to internal stack => > NLSFUNC (still uses DOS stack) => int2f/ax=12xx => back in DOS at a lower > place on the same stack. > > Now it's just very easy to use too much stack in this setup and that's the > whole problem. > > > - Switch to a local stack > > - copy anything in between the original ss:sp and ss:920 to a temp area > > - call DOS ints > > - restore from temp area > > - switch to original stack > > - return > > > > Does anybody see any additional problem with this? > > you should not use a local stack when you call int2f/ax=12xx. > As RBIL states: SS = DOS DS (must be using a DOS internal stack) I understood all of this the wrong way. I thought that you were saying to call _int21_, that's the reason for the local stack. > > Excuse me if I'm a bit thick in the head. Do you mean that it makes no > > sense to implement the int 2f122[6-9b] functions in FreeDOS and it is > > better to do what you suggested in your previous post? > > No, it makes sense to implement them, but you're understanding of RBIL > apparently was wrong -- it isn't talking about switching stacks but about > pointing to a different stack frame. So, now that I know how to solve the stack problem, is my implementation of int2f/ax122[6-9] correct? (http://sourceforge.net/mailarchive/message.php?msg_id=8802703) Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit - UNSTABLE
Jim Hall wrote: Jeremy: The [EMAIL PROTECTED] alias is still pointed at Bart. Did you want me to change it to point to you? -jh Oops. Maybe I should have sent that just to Jeremy & Bart. :-) -jh -- _ This email message has been automatically encrypted using ROT-26. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: NLSFUNC and callbacks into kernal (was Re: [Freedos-kernel] Strange bug in kernel 2035)
On Tue, 27 Jul 2004, Bart Oldeman wrote: On Mon, 26 Jul 2004, Steffen Kaiser wrote: DOS has three internal stacks, how about switching to the Critical Error stack and defer any calls when the stack is in use? You'd automatically overflow into the Critical Error stack anyway. I So you can set DOS's Critical Error flag and be happy? wonder about "defer" though -- how do you defer a critical error handler, when say, you try to find a:COUNTRY.SYS without a floppy in the drive? At first sight a delayed critical error handler seems more difficult than switching stacks OK, "defer" is not the right word, how about "autofail". Or, re-enter DOS as like in case of a Critical Error. I never tested (or used) NLSFUNC in conjunction with floppies and I certainly never considered this an option. Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit - UNSTABLE
Jeremy: The [EMAIL PROTECTED] alias is still pointed at Bart. Did you want me to change it to point to you? -jh -- _ This email message has been automatically encrypted using ROT-26. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
> > This has nothing to do with switching kernel stacks, in fact if FreeDOS > > would do things this way (instead of calling DosSeek directly) it would > > use even more stack space. > > Excuse me if I'm a bit thick in the head. Do you mean that it makes no > sense to implement the int 2f122[6-9b] functions in FreeDOS and it is > better to do what you suggested in your previous post? No, it makes sense to implement them, but you're understanding of RBIL apparently was wrong -- it isn't talking about switching stacks but about pointing to a different stack frame. The only thing RBIL does here is to point out a fairly obscure implementation detail of these functions in MSDOS. None of the int2f/12 functions switch stacks. They all work on the user stack, and for quite a few this has to be equal to a kernel stack too. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: NLSFUNC and callbacks into kernal (was Re: [Freedos-kernel] Strange bug in kernel 2035)
On Mon, 26 Jul 2004, Steffen Kaiser wrote: > DOS has three internal stacks, how about switching to the Critical Error > stack and defer any calls when the stack is in use? You'd automatically overflow into the Critical Error stack anyway. I wonder about "defer" though -- how do you defer a critical error handler, when say, you try to find a:COUNTRY.SYS without a floppy in the drive? At first sight a delayed critical error handler seems more difficult than switching stacks Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Mon, 26 Jul 2004, Eduardo Casino wrote: > There are. If I understand it correctly, when calling DOS with ss:920, > the flags and return address are trashed because DOS sets ss:920 on > entry, again. No. The whole point of calling int2f/ax=12xx is that this stack setup is bypassed. i.e. *without* any swapping in NLSFUNC you'd have int21/ah=38 => DOS switches to internal stack => NLSFUNC (still uses DOS stack) => int2f/ax=12xx => back in DOS at a lower place on the same stack. Now it's just very easy to use too much stack in this setup and that's the whole problem. > - Switch to a local stack > - copy anything in between the original ss:sp and ss:920 to a temp area > - call DOS ints > - restore from temp area > - switch to original stack > - return > > Does anybody see any additional problem with this? you should not use a local stack when you call int2f/ax=12xx. As RBIL states: SS = DOS DS (must be using a DOS internal stack) Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit - UNSTABLE
Hi! 25-Июл-2004 16:46 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer) wrote to [EMAIL PROTECTED]: IFM> [Kernel + FreeCom + Sys] IFM> .UNSTABLE. is the development branch where work is initially IFM> committed, the other is the stable [HEAD] branch. source: IFM> http://www.fdos.org/bootdisks/autogen/source_core.UNSTABLE.zip Oh, God... Please, don't include both archives of kernel and FreeCOM into one archive. Especially, the FreeCOM archive is twoce longer, than kernel. Especially, kernel and FreeCOM archives are _packed_, not _stored_, thus, container archive adds nothing in sense of packing. :( I mean: 1. place FreeCOM and kernel as separate archives. 2. _if_ you place .zip archive into .zip archive, then, at least, don't pack first .zip archive (ie. use storing method). This makes better compression, somewhat nearer to .tgz. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit - UNSTABLE
Hi! 25-Июл-2004 16:46 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer) wrote to [EMAIL PROTECTED]: IFM> http://www.fdos.org/bootdisks/autogen/source_core.UNSTABLE.zip BTW, PKZIP can't extract file, if its name contains more than one dot. :( Now I again should binary edit this archive to replace kernel.UNSTABLE.source.zip by something like kernel-UNSTABLE-source.zip... --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hello again, > 2. nlsfunc would have to copy anything in between ss:sp and ss:920 >(_disk_api_tos, that's the top of the stack used here in any DOS >= > 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call > DOS. Then after the call adjust the stack pointer, then swap it back, > then return. > > 2. is probably easiest unless we also like to experiment with 3rd party > NSLFUNCs. There may be funny problems I didn't think of but can't > think of any though. There are. If I understand it correctly, when calling DOS with ss:920, the flags and return address are trashed because DOS sets ss:920 on entry, again. The one that has worked for me is: - Switch to a local stack - copy anything in between the original ss:sp and ss:920 to a temp area - call DOS ints - restore from temp area - switch to original stack - return Does anybody see any additional problem with this? Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
NLSFUNC and callbacks into kernal (was Re: [Freedos-kernel] Strange bug in kernel 2035)
On Sat, 24 Jul 2004, Bart Oldeman wrote: Hello Bart, DOS has three internal stacks, how about switching to the Critical Error stack and defer any calls when the stack is in use? Bye, -- Steffen Kaiser --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit - UNSTABLE
Hi! 25-Июл-2004 16:46 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer) wrote to [EMAIL PROTECTED]: >> see in your posts some additions. Also, don't forget to publish URL for IFM> These are fairly static URLs, and should be updated within a day of IFM> any cvs commits. At which time? For example, Bart was says, that kernel.tgz updated at 14:00GMT. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] commit - UNSTABLE
Arkady V.Belousov wrote: Hi! 25-Июл-2004 06:05 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer) wrote to [EMAIL PROTECTED]: IFM> UNSTABLE branch updated with many of Lucho's and Arkady's work. When you update archive on the site? I wish to resync my tree - I was sourceforge has cron jobs to update the source tarballs there, but cron doesn't appear to be working anymore? So I'll update them later. see in your posts some additions. Also, don't forget to publish URL for These are fairly static URLs, and should be updated within a day of any cvs commits. (I have scripts that pull the stable kernel from cvs, build, and update all the bootdisks on that page. For unstable I still need to fix the OW files to not require a manual [Enter] and add scripts to auto build.) [Kernel + FreeCom + Sys] .UNSTABLE. is the development branch where work is initially committed, the other is the stable [HEAD] branch. source: http://www.fdos.org/bootdisks/autogen/source_core.UNSTABLE.zip http://www.fdos.org/bootdisks/autogen/source_core.zip binaries: http://www.fdos.org/bootdisks/autogen/kernel.UNSTABLE.zip http://www.fdos.org/bootdisks/autogen/kernel.UNSTABLE.debug.zip http://www.fdos.org/bootdisks/autogen/kernel.zip http://www.fdos.org/bootdisks/autogen/kernel.debug.zip archive with executable. And, don't forget to include into this archive bugfixed FreeCOM (currently not required - workaround for bug in FreeCOM readded, but who knows?). When I get a chance to figure out the right SUPPL source version and update my build scripts, this will automatically be done. For right now, the command.com included works. I will try to get to that next weekend, but this weekend I wanted to try and go through the patch collection piling up. :-) Jeremy --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
Hi Bart, > This has nothing to do with switching kernel stacks, in fact if FreeDOS > would do things this way (instead of calling DosSeek directly) it would > use even more stack space. Excuse me if I'm a bit thick in the head. Do you mean that it makes no sense to implement the int 2f122[6-9b] functions in FreeDOS and it is better to do what you suggested in your previous post? (http://sourceforge.net/mailarchive/message.php?msg_id=9050842) Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/bin autoexec.bat,1.6,1.6.2.1
Arkady V.Belousov wrote: Hi! 25-Июл-2004 09:55 [EMAIL PROTECTED] (Kenneth Davis) wrote to [EMAIL PROTECTED]: KD> +++ autoexec.bat25 Jul 2004 09:55:56 - 1.6.2.1 KD> @@ -1,3 +1,3 @@ ... Hm. What here changed? Why diff shows all lines as changed? This is largely a cvs issue regarding line endings. Several batch files were committed with \r\n line endings from a non-EOL converting cvs client, as such on those clients they check out as \r\n, but on clients (such as I use) they are converted to DOS EOLs resulting in \r\r\n. This screws up FreeCom, many editors, and any subsequent commits show the whole file changed. I changed the EOLs when I was testing the kernel, as my primary testing one is for CD-ROM driver work, and I just wanted a basic one (that is shipped with the kernel) to verify booting up. Unchanged, booting produces two file not found errors for files HO and ATH (or something like that) and autoexec.bat otherwise ignored; very obscure bug, especially if you then view autoexec.bat and don't realize the \r\r issue. Jeremy --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/docs config.txt,1.5,1.5.2.1 contrib.txt,1.6,1.6.2.1 history.txt,1.78.2.2,1.78.2.3
Салям!
25-Июл-2004 17:18 Arkady V.Belousov wrote to
[EMAIL PROTECTED]:
KD>> +++ history.txt 25 Jul 2004 09:55:56 - 1.78.2.3
KD>> + Changes Tom
KD>> * inthndlr.c
KD>> - improve handling of case where eg. FindFirst(I:\*.*) fails, causes
KD>> Int24,
AVB> This patch included not completely. Trouble is, that part, which
AVB> should be included after swicth(), tom not marks by pluses.
Let me repeat his proposal as diff-file:
--- Begin Message ---
diff -ruNp old/kernel/inthndlr.c new/kernel/inthndlr.c
--- old/kernel/inthndlr.c 2004-07-25 16:54:58.0 +
+++ new/kernel/inthndlr.c 2004-07-25 18:17:00.0 +
@@ -411,6 +411,13 @@ dispatch:
}
/* Clear carry by default for these functions */
+ if (ErrorMode && lr.AH > 0x0c && lr.AH != 0x30 && lr.AH != 0x59)
+ {
+/* this patch description see below, after real_exit label */
+ErrorMode = 0;
+fnode[0].f_count = /* don't panic - THEY ARE unused !! */
+fnode[1].f_count = 0;
+ }
/* Check for Ctrl-Break */
if (break_ena || (lr.AH >= 1 && lr.AH <= 5) || (lr.AH >= 8 && lr.AH <= 0x0b))
@@ -1500,6 +1507,30 @@ exit_dispatch:
r->ES = lr.ES;
real_exit:;
+ /* PATCH !! --TE 5 JUL 04
+ what happened:
+ Application does FindFirst("I:\*.*");
+ this fails, and causes Int24
+ this sets ErrorMode, and calls Int24
+ Application decides NOT to return to DOS,
+ but instead pop the stack and return to itself
+ (this is legal; see RBIL/INT 24 description)
+ a) now the alloc()'ed fnode[] never gets free()'ed
+ b) errormode NEVER gets set back to 0 until exit()
+ I have NO idea how real DOS handles this;
+ the appended patch cures the worst symptoms
+ */
+
+ if (fnode[0].f_count | fnode[1].f_count)
+ {
+if (ErrorMode == 0)
+ put_string("near_fnodes not 0"); /* panic ?? */
+fnode[0].f_count = /* don't panic - THEY ARE unused !! */
+fnode[1].f_count = 0;
+ }
+
+ /* PATCH !! END --TE 5 JUL 04 */
+
#ifdef DEBUG
if (bDumpRegs)
{
--- End Message ---
Re: [Freedos-kernel] commit - UNSTABLE
Hi! 25-Июл-2004 06:05 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer) wrote to [EMAIL PROTECTED]: IFM> UNSTABLE branch updated with many of Lucho's and Arkady's work. When you update archive on the site? I wish to resync my tree - I was see in your posts some additions. Also, don't forget to publish URL for archive with executable. And, don't forget to include into this archive bugfixed FreeCOM (currently not required - workaround for bug in FreeCOM readded, but who knows?). --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: [Freedos-cvs] kernel/kernel dosfns.c,1.70,1.71
Hi! 25-Июл-2004 09:58 Arkady V.Belousov wrote to [EMAIL PROTECTED]: BO>> Need to check for navc!=NULL, not *nc!=0x in DosGetFree. BO>> +++ dosfns.c25 Jul 2004 00:08:34 - 1.71 BO>> - if (*nc != 0x) BO>> + if (navc != NULL) BO>> *navc = (COUNT) dos_free(dpbp); AVB> Unfortunately, this is not the last access to *navc without checking. AVB> Unfortunately, there changed UWORD *dpw, Hm. Interesting mistype. :) Should be "UWORD *spc". AVB> where FcbFatGetDrvData() passes AVB> pointer to lr.AX, whereas INT21/1B and INT21/1C should modify AL. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Sat, 24 Jul 2004, Eduardo Casino wrote: > El sáb, 24-07-2004 a las 13:50, Bart Oldeman escribió: > > > It's a difficult question. Essentially there are two ways we can go: > > 1. if the kernel very carefully minimizes stack usage on the code path > >taken and NLSFUNC itself only uses a couple bytes of stack in between > >it's possible to just do it. > > or > > 2. nlsfunc would have to copy anything in between ss:sp and ss:920 > >(_disk_api_tos, that's the top of the stack used here in any DOS >= > > 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call > > DOS. Then after the call adjust the stack pointer, then swap it back, > > then return. > > Just curious, what about a 3rd possibility: implement the 2f12xx calls > as documented in RBIL? For example, 2f1228: "sets user stack frame > pointer to dummy buffer, moves BP to AX, performs LSEEK, and restores > frame pointer". (This is the "what", my problem is "how" :) The user stack frame pointer is poined to by a global variable "user_r" in the FreeDOS kernel. It points to the user stack which is yet another stack. It sits in the SDA at 264hDWORD pointer to stack frame containing user registers on INT 21 What normally happens is that: 1. user calls int21/ah=42 2. registers are pushed on the stack (entry.asm) 3. ss:sp stored in user_r 4. ss:sp moves to DOS stack 5. DOS does the lseek using the values pushed in 2. 6. DOS updates the registers on the user stack Essentially the RBIL comments says that, in MSDOS, 2f1228 changes user_r to point to a dummy place, moves the value of BP to the "AX"-slot in the dummy user_r stack, calls steps 4-6, restores user_r, and returns. In FreeDOS that would mean something like this: case 0x28: old_user_r = user_r; user_r = &tempplace; user_r->AX = r.BP; int21_service(user_r); user_r = old_user_r; break; This has nothing to do with switching kernel stacks, in fact if FreeDOS would do things this way (instead of calling DosSeek directly) it would use even more stack space. This all goes to say that RBIL is a strange place, sometimes it doesn't report much at all (about error codes for instance), and sometimes it reports about such obscure implementation details. Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: patch: dosfns.c fcbfns.c inthndlr.c proto.h
Hi! 25-Июл-2004 00:33 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: EA> Hi Arkady! Your patch is MUCH too long. EA> I doubt that you did try to keep the diff short AT ALL. Eric, may be you test this patch instead criticizm? May be, it already fixes your problem with WHICHFAT? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] patch: inthndlr.c fcbfns.c proto.h
Hi! 24-Июл-2004 22:17 Arkady V.Belousov wrote to [EMAIL PROTECTED]: AVB> - bugfix: INT21/29: into FcbParseFname() was not passed options from AL. Forget to mention: casually :) this bugfix reduces resident code (in inthndlr.c) by ~50 bytes. :) --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Smaller tour of 32bit stuff in kernel, optimize, bugs
Hi! 22-Июл-2004 21:24 [EMAIL PROTECTED] (tom ehlert) wrote to Eric Auer <[EMAIL PROTECTED]>: >>> please provide exact code sequence where it DOES return nonsense - and >>> I'll fix it. (we are talking about ke2035 !!) >> That translates to: Provide a fix and you will have provided a fix. Helpful. te> I intended to say (as above, but didn't exactly say it): te>provide some sort of te> mov ax,XXX te> mov dx,YYY te> int 21h -->> misbehaviour (wrong return value, crash or just reboot) te>and the cavalry is set into march Eric, provide precise scenario for tom. For example: - "I have unformatted partition, unimportant which size"; - "I run WHICHFAT"; - "I get bla-bla-bla behavior instead bla-bla-bla behavior, as in MS-DOS"; - "WHICHFAT calls bla-bla-bla functions; on output expected bla-bla-bla, but received bla-bla-bla". >>> and it's better not to touch these disks at all. >> I vote for: Then you better only use the first 2 TB. te> I vote for: wait till 2TB disks arrive. see. possibly fix bugs. te> THEN remove this. _Sometime_, better to prevent such "bugfixing", especially because CHS access is only one possible way, how to handle strange geometry, and it is not the best (even as compromise between LBA and "no disk"). >>> > Track wrap protection and DMA wrap >>> > protection should be turned off (maybe add a SYS CONFIG variable!) >>> > for harddisks. te> I measured - it's irrelevant. "Irrelevant" = "doesn't changes speed"? --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
El sáb, 24-07-2004 a las 13:50, Bart Oldeman escribió: > It's a difficult question. Essentially there are two ways we can go: > 1. if the kernel very carefully minimizes stack usage on the code path >taken and NLSFUNC itself only uses a couple bytes of stack in between >it's possible to just do it. > or > 2. nlsfunc would have to copy anything in between ss:sp and ss:920 >(_disk_api_tos, that's the top of the stack used here in any DOS >= > 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call > DOS. Then after the call adjust the stack pointer, then swap it back, > then return. Just curious, what about a 3rd possibility: implement the 2f12xx calls as documented in RBIL? For example, 2f1228: "sets user stack frame pointer to dummy buffer, moves BP to AX, performs LSEEK, and restores frame pointer". (This is the "what", my problem is "how" :) > 2. is probably easiest unless we also like to experiment with 3rd party > NSLFUNCs. There may be funny problems I didn't think of but can't > think of any though. NLSFUNC is very specific of each DOS variant. The internal nls structures are different. Regards, Eduardo. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: Smaller tour of 32bit stuff in kernel, optimize, bugs
Hi! 21-Июл-2004 23:33 [EMAIL PROTECTED] (Eric Auer) wrote to [EMAIL PROTECTED]: >> there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32. >> end of story. EA> Compiler weakness :-P. Caused by language(s) nature (which require to automatically promote integral types in expressions to common base). --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Strange bug in kernel 2035
On Sat, 24 Jul 2004, Eduardo Casino wrote: > Tom, your patch seems to cause some problems (now the wrong DS is passed > to some nlsfunc calls. It happens with a modified nls.c, I can send you > the code and the details if you are interested) If you don't initialize r.ds in a call to intr there is garbage in there. r.ds = FP_SEG(&nlsInfo) is also necessary if you go that route. Using direct assembly DS will just stay that. > Now, guys, if you could only give me a hint on how to implement this: > > http://sourceforge.net/mailarchive/message.php?msg_id=8809361 It's a difficult question. Essentially there are two ways we can go: 1. if the kernel very carefully minimizes stack usage on the code path taken and NLSFUNC itself only uses a couple bytes of stack in between it's possible to just do it. or 2. nlsfunc would have to copy anything in between ss:sp and ss:920 (_disk_api_tos, that's the top of the stack used here in any DOS >= 4.0) to a temp area (max 384 bytes), set sp to 920, and with that call DOS. Then after the call adjust the stack pointer, then swap it back, then return. 2. is probably easiest unless we also like to experiment with 3rd party NSLFUNCs. There may be funny problems I didn't think of but can't think of any though. > In return, I promise you a tour through the best tapas bars in Madrid > next time you come. I'll pay the bill, of course! ;-) Madrid is a long way and a lot warmer than here from what I heard :) Although 40 C is too hot. Greetings from Auckland NZ (10 C, but clear skies). Bart --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
