1. set_vector bug
I discovered a problem with set_vector when using Michael Bolin's
keyread.e. Sometimes keyread.e will crash, with a type-check error in
set_vector (which is in machine.e). The problem seems to be that the
code_segment sometimes does not fit in a Euphoria integer. Better
change that to an atom in the next release, Robert. DOS32 code segment
descriptors are 32-bits, not 16 as noted near the get_segment code in
call_mach.ex.
--
_____ _____ _____
________ /\ \ /\ \ /\ \
/ \ \ / \____\ / \____\ / \____\
/ _ \____\ / / ___/_ / /____/ / / ___/_
/ / \ |___| / / /\____\ / \ \ / / /\____\
\ \_/ / / \ \/ / ___/_\ \ \ \ \/ / ___/_
\ /____/ \ / /\ \\/\ \ \ \ / /\ \
\ \ \ \ \/ \____\ \ \ \ \ \/ \____\
\ \ \ \ / / \ \____\ \ / /
\ \____\ \ / / \ / / \ / /
\ / / \ / / \/____/ \ / /
\/____/ \/____/xseal at harborside.com\/____/
2. Re: set_vector bug
Pete Eberlein reported:
> I discovered a problem with set_vector when using Michael Bolin's
> keyread.e. Sometimes keyread.e will crash, with a type-check
> error in set_vector (which is in machine.e). The problem seems
> to be that the code_segment sometimes does not fit in a
> Euphoria integer.
Check that you have the latest version of keyread.e.
I fixed a bug in keyread.e on November 1/97 and re-uploaded it
to the Archive. If it's the fixed version it should have
"Rob Craig" somewhere in a comment beside the fixed code.
Without the fix, it may run for quite a while before causing
the type_check error that you saw.
The problem is that Michael copied a bug that I had in
hardint.ex where it tries to get the code segment number
by reading 4 bytes, when it should only read 2 bytes.
That bug has since been corrected in 2.0 alpha, but
Michael and a few others had already copied the
v1.5 hardint.ex.
> Better change that to an atom in the next release, Robert.
> DOS32 code segment descriptors are 32-bits, not 16 as
> noted near the get_segment code in call_mach.ex.
A protected-mode address consists of a 16-bit segment
number and a 32-bit offset within the segment.
Regards,
Rob Craig
Rapid Deployment Software
3. Re: set_vector bug
- Posted by Pete Eberlein <xseal at HARBORSIDE.COM>
Jan 05, 1998
-
Last edited Jan 06, 1998
Robert Craig wrote:
>
> Pete Eberlein reported:
> > I discovered a problem with set_vector when using Michael Bolin's
> > keyread.e. Sometimes keyread.e will crash, with a type-check
> > error in set_vector (which is in machine.e). The problem seems
> > to be that the code_segment sometimes does not fit in a
> > Euphoria integer.
>
> Check that you have the latest version of keyread.e.
> I fixed a bug in keyread.e on November 1/97 and re-uploaded it
> to the Archive. If it's the fixed version it should have
> "Rob Craig" somewhere in a comment beside the fixed code.
> Without the fix, it may run for quite a while before causing
> the type_check error that you saw.
I already have the latest (fixed) version. It's still crashing,
repeatedly, with a type-check error in set_vector.
> The problem is that Michael copied a bug that I had in
> hardint.ex where it tries to get the code segment number
> by reading 4 bytes, when it should only read 2 bytes.
> That bug has since been corrected in 2.0 alpha, but
> Michael and a few others had already copied the
> v1.5 hardint.ex.
>
> > Better change that to an atom in the next release, Robert.
> > DOS32 code segment descriptors are 32-bits, not 16 as
> > noted near the get_segment code in call_mach.ex.
>
> A protected-mode address consists of a 16-bit segment
> number and a 32-bit offset within the segment.
I'm running in a win95 dos window and when I print out the code_segment
variable, it is _obviously_ a 32-bit value.
> Regards,
> Rob Craig
> Rapid Deployment Software
I changed machine.e to:
type far_addr(sequence a)
-- protected mode far address {seg, offset}
return length(a) = 2 and machine_addr(a[1]) and machine_addr(a[2])
end type
and now it works fine.
--
_____ _____ _____
________ /\ \ /\ \ /\ \
/ \ \ / \____\ / \____\ / \____\
/ _ \____\ / / ___/_ / /____/ / / ___/_
/ / \ |___| / / /\____\ / \ \ / / /\____\
\ \_/ / / \ \/ / ___/_\ \ \ \ \/ / ___/_
\ /____/ \ / /\ \\/\ \ \ \ / /\ \
\ \ \ \ \/ \____\ \ \ \ \ \/ \____\
\ \ \ \ / / \ \____\ \ / /
\ \____\ \ / / \ / / \ / /
\ / / \ / / \/____/ \ / /
\/____/ \/____/xseal at harborside.com\/____/
4. Re: set_vector bug
Pete Eberlein writes:
> I'm running in a win95 dos window and when I print out the
> code_segment variable, it is _obviously_ a 32-bit value.
The only place in the *corrected* keyread.e where
code_segment is assigned a value is on the following line
(the original, incorrect code has been commented out):
-- code_segment = bytes_to_int(peek({segment,4}))
code_segment = peek(segment) + 256 * peek(segment+1)
-- Rob Craig Nov 1/97
Since peek() always returns a value from 0 to 255, there
is no way that you could get a code segment greater than
65535, *unless* you are somehow picking up the *old*
keyread.e. Please check carefully. Maybe the new one
is in your euphoria\include, but the old one is in your
current directory.
> I changed machine.e to:
> type far_addr(sequence a)
> -- protected mode far address {seg, offset}
> return length(a) = 2 and machine_addr(a[1])
> and machine_addr(a[2])
> end type
> and now it works fine.
This will work in most cases because only the low-order 16 bits
of the segment are actually used by set_vector and they will be
correct. However, I think your program will still fail if the
highest-order (32nd) bit happens to be set, due to the way that set_vector
has been coded inside ex.exe.
Regards,
Rob Craig
Rapid Deployment Software
