Re: Running DOS screen access software under Linux

[AARON HOWELL <a.howell@student.qut.edu.au>]

On Mon, 23 Jun 1997, Whistler wrote:

> 
> 
> If you have ever coded in linux and in dos you will know that most of what
> you think you know about c and c++ goes right out the window when you port
> it to linux.  first off the screen access portion of the code would be
> history which is most of speech access software.  Then The way you
> allocate memory depending on what kind of c coder you are (safe or not)
> has to be changed or your in a hell of a lot of trouble.  third you have
> to remember dos is a single user environment and a dos app that you
> compile in linux will have no idea what to do with 8 sessions of pine and
> 4 sessions of some other program running.  I could go on for days but I am
Some of this bares a little clarification.
Yes, the screen accessing portion of your screen reader would need to be
rewritten, however linux's virtual console interface makes this task
considerably easier than it is under dos, since text based screens are all
located in memory. This makes reading text off any console easy.
Speech access itself is a seperate issue, the *optimal* way to implement
speech under linux would be to design a device, say, /dev/speech, which is
similar in function to /dev/dsp. That is, it has a given set of ioctls,
rateup, ratedown, volumeup, etc, and the actual gots of addressing the
speech hardware in use on a particular system is configured in at kernel
compile (or module load) time. This is how it works in the sound driver,
to linux apps, it doesn't matter what sort of sound card you're using, the
app just calls the appropriate ioctl to perform the task it wants done and
the kernel takes care of the rest.
As far as the comment regarding multiple sessions goes, its much the same
as multiple windows under dos. Each session is seperate from the other, so
the screen reader should speak what's active on the current console, and
completely ignore all the others, until the user switches to them, which
the reader would detectand handle.
An alternative would be to put the reader itself in user space, and have
it activate say on a given users login, though this has the disadvantage
of not giving access to messages that appear on the console while the user
is not logged in etc.
Just a few thoughts.
Aaron

> ken /whistler

-----------------------------------------------------------------------------
Aaron Howell.	Q.U.T Equity Department, Technical Support/Training.
work: a.howell@qut.edu.au	Linux/Networking Support.
home: a.howell@student.qut.edu.au	phone +61-19-956-467
www: http://www2.cnl.com.au/~aaron	irc: DaRkAnGeL
Support the efforts of the Coalition Against Unsolicited Commercial Email. 
http://www.cauce.org for details. help stamp out internet junkmail.

---
Send your message for blinux-list to blinux-list@redhat.com
Blinux software archive at ftp://leb.net/pub/blinux
Blinux web page at http://leb.net/blinux
To unsubscribe send mail to blinux-list-request@redhat.com
with subject line: unsubscribe