Re: bug in pic_prot.diff (was Re: Bootfile)

[Stas Sergeev <stssppnn@yahoo.com>]

Hello.

Bart Oldeman wrote:
>> locks up. That looks like a problem. The attached patch fixes it: now
>> setting $_pic_watchdog to any reasonable value (within a range of 1-100
>> approx) will work for that game. 
>  Hmm why do you now need to enable the hack in the first place where it 
>  was unnecessary before? That doesn't sound like a good thing to me.
Yes, but this is not as straightforward.
There was a big discussion about a year
ago in a (unfortunately not archived
these days) dosemu-devel@ about that issue,
where the several possibilities were discussed:
Eric was standing for the time-based
measurements, which are, unfortunately,
not reliable with the current timer
precision. I was standing for the hlt-
based protection and Larry at one point
proposed to make that optional, which
is now done. As I was a proponent of a
hlt-based protection, I have made it by
default, and optionally we can enable a
time-based watchdog.
The problem is that the both approaches
are the hacks:(
It was tested and proved (at least I
hope so:) that the hlt-based approach
satisfies a majority of apps out there,
however some (counted by fingers) are
still in need of a time-based approach.
Before it was used a much weaker protection
(also a hlt-based, but flawed), and many
apps used to ocasionally crash. Now the
behaveour is at least predictable and for
the programs which can't get along with
the current scheme there is an optional
detour.
Eric wanted the time-based approach to
be enabled by default and Larry agreed
but noted that this can potentially harm
all the programs. I also think it can harm
sometimes (esp. with the current state
of an interrupt handling for DPMI!)
that's why I decided to disable it by
default.
The choice here is as follows: either
we want all the programs to work, but
potentially unreliably, or we want to
work reliably an absolute majority of
progs, but some will not work at all,
then the option.
So when the option exists, the
default value is not so important after
all. We can set it to some large value
by default if it is really necessary
for the any noticeable amount of progs,
but it really seems like it is not.
Alternatively we can always track a
timeouts and, in case $_pic_watchdog
is disabled and the timeout is frightening,
we throw an error message to hint the
user to try enabling the option if he
have a lock-up.

>> However I have found my test-case for that problem screwed up by an 
>> XMS changes of 1.1.4.1.
> i'll look at the XMS changes again to see if I missed something there.
Would be great. Let me know in case you
need a logs or a test-case.