1. set_vector bug
- Posted by Pete Eberlein <xseal at HARBORSIDE.COM> Jan 05, 1998
- 553 views
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
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Jan 06, 1998
- 556 views
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
- 555 views
- 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
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Jan 06, 1998
- 575 views
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