home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 2 BBS
/
02-BBS.zip
/
FSC.ZIP
/
FSC-0021.ZZZ
< prev
next >
Wrap
Text File
|
1988-08-03
|
2KB
|
37 lines
Message #102
Date: 01 Aug 88 15:19:00
From: Rick Moore on 132/101, BBS Source Ar of New England-N, Nashua NH
To: All on 105/6, DawgGone Disg of VanPort Net, Portland OR
Subj: VFOSSIL errors
A couple of clarifications to the FSC-0021 document, until a new one comes
out. First, there is an error in line 361, the first parameter to
VioWriteTTY. It should be a pointer (as the text says), not a word.
Second, some confusion caused by my use of the word "reentrant" in the
desription of VioWriteTTY. The two forms of VioWriteTTY (depending on the
state of the ANSI flag) are exactly equivalent to FOSSIL calls 13h and 15h.
If ANSI is true, then use of MS/DOS and ANSI.SYS should be assumed. If
ANSI is false, then use of BIOS int 10h, function 0Eh should be assumed.
True reentrancy is not required (and given memory management with MS/DOS is
a pipe-dream anyway). Thanks to Bob Hartman for pointing these out to me.
I encourage everyone interested in implementing a VFOSSIL or using one in a
program to file-request "VFOSSIL" from 115/333 (Randy Bush also has it as
FSC-0021.ARC on 105/6). Please inform me of any typo's or logic errors
a.s.a.p., so that I can get out a corrected version. Also, please don't
waste your time suggesting major logic changes in the way VFOSSIL is
designed. I also could do it better, but I (and the person who suggested
it to me) feel that upward compatibility with OS/2's VIO API is a major
plus for VFOSSIL as it is defined. And to be truthful, MicroSoft seems to
have (accidently, I'm sure) come up with a pretty decent design for
machine-independent, memory mapped video.
--- QuickBBS v2.02
* Origin: Home Of The FOSSIL Spec (1:115/333)
SEEN-BY: 11/0 13/9 16/23 105/6 106/506 2000 107/312 109/639 115/333
SEEN-BY: 123/2 124/108 132/101 113 141/491 150/603 161/2 265/7
SEEN-BY: 321/202 322/1