Hi Christian,

>> If you're waiting for further improvements to 2038 before you release
>> 2038, then you're doing this wrong. [...] I'd strongly recommend
>> making 2038 available, and putting the "few pending improvements" in
>> 2039.
> The problem is that Eric holds back at least three necessary patches, of  

There are also patches waiting for feedback / review / testing. Saying
you have to modify this like that is one thing, discussion is another.


- handling of floppy before disk is inserted / unformatted partitions

- initdisk CHS geometry fix and BSS init fix from RayeR

- int 21.1c non-FAT / non-existing drive handling fix from Tom

> seems Eric doesn't exactly want to be the kernel maintainer, you need  
> someone else for that.

Uhm you do not exactly motivate me but I can repeat the state
of things: The 2038 kernel needs mainly doc updates plus some
feedback for a few small pending patches. The lists are too
silent on that. Of course I could just push the patches and
assume they will work, but that is the non-preferred choice.

> The mentioned patches are:

None of those patches is necessary for the 2038 kernel but on
the other hand some of them are definitely useful, yes :-).

> - Terminating self-owning PSPs (parent PSP field set to the PSP) doesn't  
> work. There's a patch for this in inthndlr.c but it's wrong and leads to  
> crashes. The patch in inthndlr.c (below case 0x4c of the main Int21  
> handler) has to be removed, and the condition of a self-owning PSP has to  
> be handled like a TSR termination in the return_user function in task.c.  
> 2037 is affected by this, too.

Afair, self-owning PSPs happen in shells and in DEBUG etc, but
I do not remember having problems with leaving DEBUG. Leaving
the main SHELL is not a good idea anyway. Plus the origins of
your inthndlr.c / task.c patch are a bit fishy copyright-wise.

> - CALL 5 interface is broken, and probably crashes the system.

Note that only CP/M programs use this, software from the seventies.

> The Assembly code in entry.asm that handles such calls is screwed
> up. I can provide working replacement code or patch it to work how
> it's supposed to. 2037 is affected by this, too.

The patch was long ago and I remember the discussion about it
was aborted too early. It should have been on the list, too.
I believe it was a "do what I say or forget it" request ;-).

> - The seek position (and various other fields) of the SFT isn't declared  
> as unsigned. Eric reported that the seek function reports errors using  
> negative return values. This has to be changed so that it can work with  
> files up to 4 GiB. Depending on when the seek function is called (whether  
> it's already determined that the handle references a valid SFT, and that  
> the origin in al is valid) you might just remove any error reporting of  
> it, since the actual seek operation never returns errors in MS-DOS (as  
> mentioned in RBIL and UDOS too). 2037 seems not to be affected by this, at  
> least the case 0x42 in inthndlr.c should work with larger seek positions.

I agree that supporting files above 2 GB size is high on the
wishlist and reasonably easy to implement. Will work on it :-)

> I've CCed the Freedos-kernel list, too.

Okay, so I guess I have to CC both lists, too :-)


Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
Freedos-user mailing list

Reply via email to