Mail Archives: opendos/1997/03/18/02:27:54
On 17 Mar 97 at 19:38, yeep wrote:
> > How to minimize the amount of information presented where the user isn't
> > overwhelmed with everytime being presented at once. While that would
> take
> > care of the GUI manager, what about the programs to run under them?
> It would be one helluva challenge!!!
Indeed.
> Because Micro$oft declared that they'll no longer support DOS, I assume
> they'll only support Windows, a GUI!!!
> So how do they handle this?
> Or do they just don't care about the sight impaired?
It would seem so.
Technology exists to enable. JCBs mean disabled people can happily move mountains.
mputers are perhaps the greatest technological leap we have ever made; since
they process information, they should be able to present information to people
who have problems accepting information (because they can't see, or they speak
a foreign language, are the two main reasons applicable here). They should
make it no harder for a blind person to work in an office than for a seeing person.
They don't! And whose fault is it? Not the programmers as such - they
don't have time to make their software work with many different
output technologies.
IMHO, it's the platform developer's fault; people who design GUI APIs, people who
design character sets and operating systems, and the people who design language
standard libraries.
Well, here we stand. We have the sources of a DOS kernel emerging. We have
an unparalleled opportunity to shape a computing platform that already works
on most machines out there.
So let's not waste it. Let's design a platform that provides the kind of GUI that
will be of some use to blind people.
Foreign people are a different matter altogether; we can but provide OS and library
level support for language files, so it's trivial (unavoidable?) for the programmer
to write software that deals with different languages easily.
EG: OpenDOS extended linguistic API features
- Provide sorting tables for current character set and all that stuff DOS does anyway
- Standard LANGUAGE environment variables, takes 2 letter code like
KEYB (UK, US, GR, FR, etc)
- C library routines (libopen.a?) to access language file:
char *od_string(char *ID);
- usage: puts(string("TEXT:out of memory");
(entire printf family redefined w. extended API)
- Utility to scan source files for the string "TEXT:*", to extract a list of all language
ID strings and autogenerate an empty language file containing them. This makes it real easy
to add language strings; otherwise, the programmer has to synchronise the names in his source and
the language files himself
- The printf family is redefined thus:
od_printf("The address of %s:name% is %s:address%","name","Alaric","address","alaric AT abwillms DOT demonc DOT co DOT uk");
Thus, the same argument ordering can be used with format strings in a language that expects
the words in a different order - more general than standard printf positional notation.
This printf could intelligently decide when to use direct screen writes or connect to
fast 32 bit stream drivers, also.
- The C library automatically opens a language file based on the language code it finds in
the environment, and the name of the application, when this call is made:
od_init_international("app name");
ABW
--
Alaric B. Williams (alaric AT abwillms DOT demon DOT co DOT uk)
---<## OpenDOS FAQ ##>---
Plain HTML: http://www.delorie.com/opendos/faq/
- Raw text -