Re: [Freedos-kernel] [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038

[Christian M. <cm...@bt...>]

>> Simple: If you only use WIN /S then you can use the
>> stable 2036 or stable 2038 kernel. The latter is on
>> http://rugxulo.googlepages.com/ as binary snapshot.
>>
>> There are a few pending improvements before 2038 can
>> be put on "sourceforge file releases"... The sources
>> already are on sourceforge in our svn, of course :-)
>
> If there's a "stable" 2038, then that should get put on ibiblio for
> general release as soon as possible. If it's on rugxulo's pages, then
> very few people will know about it (heck, *I* didn't know about it -
> see my other email.)
>
> 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  
which two are already provided in source form. He doesn't exactly have to  
"wait" for these, we've completely described them. (The first one on the  
list, others in the FreeDOS bugtracker or old private e-mails.) Since it  
seems Eric doesn't exactly want to be the kernel maintainer, you need  
someone else for that.

The mentioned patches are:

- 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.

- CALL 5 interface is broken, and probably crashes the system. 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 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've CCed the Freedos-kernel list, too.

Regards,
Christian