disabling the linux console/display driver and manipulating cursor.
SAM...@worldnet.att.net
hello:
I have successfully memmory mapped the vga text mode buffer into my
running programs. I can now display chars and attributes at any location on
the console screen.Unfortunately I have to update the vga start display
address register at each attempt to update the screen. I believe the linux
console/display driver is still running in the background.
How can I disable the linux console/display driver so that my programs
truly have control of the display.?????
Manipulation of the port addresses where the cursor resides yields
unproductive results. Could this be attributed to the linux display driver
running in the background?
Does anyone have any info on the ioctl() calls of vt.h and kd.h. The linux
programmers guide does not explain any of them nor does the man pages.
Please assist me, for I am nearing completion of my project -- all that
remains is to temporarily disable the driver so that it does not interfere
with my program and to manipulate the cursors.
thanks in advance
send replies to my email to gurantee i recieve your message
SAM...@worldnet.att.net
p.s DO NOT recommend I use ncurses -- My program is to function without it.
Also, Do not bother questioning X compatibility as this program is not
meanth to be run from X.
T.E.Dickey
In comp.os.linux.development.apps SAM...@worldnet.att.net wrote:
If you insist on proceeding in complete ignorance of what everyone else is
doing, why do you need our help?
regards.
: How can I disable the linux console/display driver so that my programs
: truly have control of the display.?????
--
Thomas E. Dickey
dic...@clark.net
http://www.clark.net/pub/dickey
Kaz Kylheku
In article <6cld8p$p...@bgtnsc02.worldnet.att.net>,
<SAM...@worldnet.att.net> wrote:
>How can I disable the linux console/display driver so that my programs
>truly have control of the display.?????
Don't do this. Linux users will hate your program.
>Manipulation of the port addresses where the cursor resides yields
>unproductive results. Could this be attributed to the linux display driver
>running in the background?
You are still thinking within an MS-DOS mentality. Use a library such as
ncurses.
>Does anyone have any info on the ioctl() calls of vt.h and kd.h. The linux
Yes, a Linux programming newsgroup, such as comp.linux.development.system.
>programmers guide does not explain any of them nor does the man pages.
Most things you want to do can be done by sending the right escape sequences
to the console. There is a simple extension mechanism whereby sequences
of the from <ESC>[arg1;arg2;arg3;...] are routed to a switch which
takes arg1 as a command, and the rest of the args as parameters to
the command. For example, there is a code for changing the pitch and
duration of the bell: <ESC>[10;<hertz_value>]. Many capabilities which
cannot be obtained using ordinary ANSI escape sequences are available this
way.
>Please assist me, for I am nearing completion of my project -- all that
>remains is to temporarily disable the driver so that it does not interfere
>with my program and to manipulate the cursors.
Please ask in a Linux programming newsgroup. Comp.lang.c is dedicated to the C
language, not to system specific extensions.
Bill Currie
So, who get's a dos originated linux editor out the door first?:) Mine's
to the point where I'm fixing little (?) bugs (wierd incompatibilities,
mostly).
SAM...@worldnet.att.net wrote:
>
> hello:
>
> I have successfully memmory mapped the vga text mode buffer into my
> running programs. I can now display chars and attributes at any location on
> the console screen.Unfortunately I have to update the vga start display
> address register at each attempt to update the screen. I believe the linux
> console/display driver is still running in the background.
Hmm, well, yes, I also believe the consol driver is still running;
however, I noticed that Linux only ever updates the page start address
when it moves the cursor or maybe even only when it scrolls the screen.
This means that so long as no file based output goes to the screen (eg
printf), linux shouldn't update the screen address under you. I don't
know, but there may be some termio settings you can use to disable
output. Also, make sure input echo is OFF (done through termio
settings). The dosemu sources are a good reference.
HTH
Bill
--
Leave others their otherness
Kaz Kylheku
In article <34F0C5...@tssc.co.nz>, Bill Currie <bcu...@tssc.co.nz> wrote:
>Hmm, well, yes, I also believe the consol driver is still running;
The driver isn't a process; it does not ``run''. The driver is just some
code in the kernel, with associated data structures which maintain the
state of the consoles. This code is invoked whenever you perform some
I/O or control operation on the console.
John Smith
Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
>In article <6cld8p$p...@bgtnsc02.worldnet.att.net>,
> <SAM...@worldnet.att.net> wrote:
>>How can I disable the linux console/display driver so that my programs
>>truly have control of the display.?????
>
>Don't do this. Linux users will hate your program.
I wouldn't, I fact I would like direct access to console text functions as
well.
>
>>Manipulation of the port addresses where the cursor resides yields
>>unproductive results. Could this be attributed to the linux display driver
>>running in the background?
>
>You are still thinking within an MS-DOS mentality. Use a library such as
>ncurses.
MS-DOS still has much better looking and functioning programs so Linux, in
this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
while much better also isn't good enougth. Why are we, with todays modern
operating systems, being forced to program our text programs for the lowest
common denominator the "DUMB TERMINAL". And then people wonder why DOS beat
out UNIX. Users aren't going to care, if even beleave, that Linux is a
better OS than DOS if Linux programs look like crap and primative when
compared to DOS equivalents. As a programmer and a user I can state with
certainty that Linux needs to allow access to low level console functions
including display, mouse, & keyboard.
>
>>Does anyone have any info on the ioctl() calls of vt.h and kd.h. The linux
>
>Yes, a Linux programming newsgroup, such as comp.linux.development.system.
>
>>programmers guide does not explain any of them nor does the man pages.
>
>Most things you want to do can be done by sending the right escape
sequences
>to the console. There is a simple extension mechanism whereby sequences
>of the from <ESC>[arg1;arg2;arg3;...] are routed to a switch which
>takes arg1 as a command, and the rest of the args as parameters to
>the command. For example, there is a code for changing the pitch and
>duration of the bell: <ESC>[10;<hertz_value>]. Many capabilities which
>cannot be obtained using ordinary ANSI escape sequences are available this
>way.
Yes I know and many a user has thought that his machine was frozen when it
was just the console that was frozen because the user had accidently pressed
Ctrl+S.
John Smith
IF you solve this please post how you did this on the newsgroup, I have been
searching for ways to directly write to the console for a while now. Have
you looked at libSVGA's source?
SAM...@worldnet.att.net wrote in message
<6cld8p$p...@bgtnsc02.worldnet.att.net>...
>hello:
>
>
> I have successfully memmory mapped the vga text mode buffer into my
>running programs. I can now display chars and attributes at any location on
>the console screen.Unfortunately I have to update the vga start display
>address register at each attempt to update the screen. I believe the linux
>console/display driver is still running in the background.
>
>How can I disable the linux console/display driver so that my programs
>truly have control of the display.?????
>
>Manipulation of the port addresses where the cursor resides yields
>unproductive results. Could this be attributed to the linux display driver
>running in the background?
>
>Does anyone have any info on the ioctl() calls of vt.h and kd.h. The linux
>programmers guide does not explain any of them nor does the man pages.
>
>
>Please assist me, for I am nearing completion of my project -- all that
>remains is to temporarily disable the driver so that it does not interfere
>with my program and to manipulate the cursors.
>
>
Jens Dittmar
>> You are still thinking within an MS-DOS mentality. Use a library
>> such as ncurses.
> MS-DOS still has much better looking and functioning programs so Linux,
> in this respect, could use a little DOS mentality.
You're just using the wrong programs. :)
> Why are we, with todays modern operating systems, being forced to program
> our text programs for the lowest common denominator the "DUMB TERMINAL".
You aren't. Control of terminals with extended capabilities is what
ncurses is made for, so Kaz is right.
> And then people wonder why DOS beat out UNIX.
Are you drunk? ;) DOS seems rather dead to me but UNIX had been refusing
to die for more than two decades...
> As a programmer and a user I can state with certainty that Linux needs to
> allow access to low level console functions including display, mouse, &
> keyboard.
As a programmer and user I can state it doesn't. :) Seems that opinions
can differ. For myself I wouldn't like to use such a program, it would fail
at the first remote session where ncurses usually works fine. Before you
ask: No, I do not use svgalib software - for the same reasons - and I know
I'm not alone.
Jens
Will Rose
John Smith (sm...@nowhere.com) wrote:
[...]
: MS-DOS still has much better looking and functioning programs so Linux, in
: this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
: while much better also isn't good enougth. Why are we, with todays modern
: operating systems, being forced to program our text programs for the lowest
: out UNIX. Users aren't going to care, if even beleave, that Linux is a
: better OS than DOS if Linux programs look like crap and primative when
: certainty that Linux needs to allow access to low level console functions
: including display, mouse, & keyboard.
Multiplexing displays, mice, and keyboards isn't a trivial task. X is
admittedly baroque, but if that's what you need to do, that's what you
need to use. If you want MS-DOS, you know where to find it.
Roy Stogner
On Sat, 28 Feb 1998 14:56:49 -0500, John Smith <sm...@nowhere.com> wrote:
>Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
>>You are still thinking within an MS-DOS mentality. Use a library such as
>>ncurses.
>MS-DOS still has much better looking and functioning programs so Linux, in
>this respect, could use a little DOS mentality.
There is no rational justification for this statement. "Better
looking?" I'm running a Linux terminal program from 500 miles away,
in full color and my choice of fonts, in a 30 row by 80 column window
from a cute little shareware Win95 program. When I'm at a terminal
with a bigger screen, I run the same program in 100x45 size. When I'm
at a computer with an X server, I run the same program with automatic
resizing and mouse support. When I'm at a computer with nothing but a
stupid Win95 telnet client, I run the same program in black and white
at 80x25. Next year I may be running the same program on an Alpha;
maybe the guy next to me will be running it on a Merced. Are you
going to learn how to do direct video access on those too?
"Better functioning?" This is even worse. I'm multitasking,
suspending, piping in input, mouse cut-n-pasting, remotely
administering a web site while learning CGI-scripting, choosing
between different news readers that (surprise, surprise) use the same
.newsrc type files to keep me from hitting the same messages twice,
choosing between different mail readers that use the same folder...
er, this has to be a troll. I'm going to make up a permanent list of
"Stuff I can do in Linux but not in DOS/Windows" one of these days
simply to be able to cut and paste it to posts like this.
>And ncurses SUCKS. SLang while much better also isn't good enougth.
>Why are we, with todays modern operating systems, being forced to
>program our text programs for the lowest common denominator the "DUMB
>TERMINAL".
Sucks by what measure? I've only used the API once for a simple
program, so I suppose that may be a problem... but if so, then write
your own cute front end. The functionality of ncurses beats out
anything under DOS.
>And then people wonder why DOS beat out UNIX.
Nobody wonders why DOS beat out Unix; DOS beat out Unix because it
came preinstalled on a hundred million cheap clonable computers.
It's not too complicated to figure out.
By the way, if you want to play the "DOS beat out UNIX" game, I'll
promise to only run Linux for the next year if you'll only run DOS.
You game?
---
Roy Stogner
Kaz Kylheku
In article <6d9q3e$q...@camel20.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>
>Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
>>>truly have control of the display.?????
>>
>
>
>I wouldn't, I fact I would like direct access to console text functions as
>well.
People who run X would just *love* having to switch to a console window
just to run your program, then.
>MS-DOS still has much better looking and functioning programs so Linux, in
>this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
Those text-based Linux installation programs sure look nice and colorful;
how about those ``3D'' pushbuttons of the RedHat installer?
>while much better also isn't good enougth. Why are we, with todays modern
I'm afraid you don't know what you are talking about. Ncurses is a terminal
control library, s-lang is an interpreter for a small stack-based language
which was developed as a way to complete and extend the JED editor.
>operating systems, being forced to program our text programs for the lowest
>common denominator the "DUMB TERMINAL". And then people wonder why DOS beat
>out UNIX. Users aren't going to care, if even beleave, that Linux is a
>better OS than DOS if Linux programs look like crap and primative when
>compared to DOS equivalents. As a programmer and a user I can state with
>certainty that Linux needs to allow access to low level console functions
>including display, mouse, & keyboard.
As an experienced UNIX user, I can state with certainty that this is a bad
idea. There are already ways to manipulate color and get mouse input without
going to the bare hardware or OS-specific ioctl's. It's possible to write a
program which can use ANSI color, and get mouse input, and have it work under
`xterm' as well as the Linux console. If you go for the bare metal, it will
not work in `xterm', nor will it be portable to anything but Linux.
Once your user starts using XWindow, he won't be able to run your program.
Or if your user has Linux on a non-PC, he might also not be able to use
your program, even in a console!
>>to the console. There is a simple extension mechanism whereby sequences
>>of the from <ESC>[arg1;arg2;arg3;...] are routed to a switch which
>>takes arg1 as a command, and the rest of the args as parameters to
>>the command. For example, there is a code for changing the pitch and
>>duration of the bell: <ESC>[10;<hertz_value>]. Many capabilities which
>>cannot be obtained using ordinary ANSI escape sequences are available this
>>way.
>
>Yes I know and many a user has thought that his machine was frozen when it
>was just the console that was frozen because the user had accidently pressed
>Ctrl+S.
That is a function of the terminal driver (XON/XOFF flow control), and can be
turned off in a POSIX standard way. How do you suppose the Emacs editor is
able to treat `Ctrl-S' as a command (bad idea as it may be)?
XON/XOFF flow control is in all flavors of the terminal driver, whether it's a
pseudo tty, or a serial line, etc.
You can also set it up so that _any_ character will restart the paused output,
not just the Ctrl-Q XOFF character.
Get some clues!
Albert D. Cahalan
royst...@SPAMiname.com (Roy Stogner) writes:
> "Better functioning?" This is even worse. I'm multitasking,
> suspending, piping in input, mouse cut-n-pasting, remotely
...
>> And ncurses SUCKS. SLang while much better also isn't good enougth.
>> Why are we, with todays modern operating systems, being forced to
>> program our text programs for the lowest common denominator the "DUMB
>> TERMINAL".
>
> Sucks by what measure? I've only used the API once for a simple
> program, so I suppose that may be a problem... but if so, then write
> your own cute front end. The functionality of ncurses beats out
> anything under DOS.
If everything works so great, explain how a text-mode app can
detect the following:
<Shift down><PageDown><DownArrow><Shift up> Standard text selection.
<Alt down><Alt up> Go to menu bar.
<Alt down><Ctrl down><F2><Alt up><Ctrl up> Invoke some function.
<Alt down><Ctrl down><Backspace><Alt up><Ctrl up> Delete column.
<Ctrl down><DownArrow><Crtl up> Download
<NumLock> For on-screen status.
Going into raw keyboard mode is admission of failure of course,
since that won't work. Now I'd like to know how to _reliably_ tell
these keys apart:
Control-H
backspace
delete (in group of 6 keys)
delete (on number pad)
How about these _different_ key sequences:
Esc Space (typed quickly, so no race conditions!)
Alt-Space
Ctrl-Shift-2
(yeah, I know the weak spots -- no DOS newbie here!)
Note that I haven't even asked about anything really strange
involving SysRq, ScrollLock, Break, Pause, PrintScreen, the
menu key, the left window key, or the right window key.
OK, now I want a real mouse cursor in text mode, like Norton Utilities
for DOS has. By that I mean the program plays with the font to generate
an arrow that floats over the text as I move the mouse.
The following is insane, but DOS can do it:
Lets say I wanted bright white text on a background of dark blue and
black blotches. I want to quickly scroll the background underneath
the text. Obviously, the cursor has to stay in one spot so that the
user can edit text. This needs to run on a DX4-100 at least, which
is more powerful that DOS would need and far more powerful than the
Unix machines of 15 years ago.
Leslie Mikesell
In article <6d9q3e$q...@camel20.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>
>>>How can I disable the linux console/display driver so that my programs
>>>truly have control of the display.?????
>>
>>Don't do this. Linux users will hate your program.
>
>I wouldn't, I fact I would like direct access to console text functions as
>well.
I almost never work at the console of the machines where the programs
are running, so if anything ever did direct console access it would
be invisible to me. Why would anyone consider it a good thing to
not work remotely?
>MS-DOS still has much better looking and functioning programs so Linux, in
>this respect, could use a little DOS mentality.
Huh? Perhaps you aren't running X.
>And ncurses SUCKS. SLang
>while much better also isn't good enougth. Why are we, with todays modern
>operating systems, being forced to program our text programs for the lowest
>common denominator the "DUMB TERMINAL".
Ummm, perhaps so you can run the program with anything that does terminal
emulation???
>And then people wonder why DOS beat
>out UNIX.
Nobody who is aware of the price of each at the time DOS was a reasonable
choice wonders this.
>Users aren't going to care, if even beleave, that Linux is a
>better OS than DOS if Linux programs look like crap and primative when
>compared to DOS equivalents.
So use X.
>As a programmer and a user I can state with
>certainty that Linux needs to allow access to low level console functions
>including display, mouse, & keyboard.
And as a user who runs programs from many different machines in different
windows at the same time I can state with certainty that you are wrong.
>Yes I know and many a user has thought that his machine was frozen when it
>was just the console that was frozen because the user had accidently pressed
>Ctrl+S.
This is correct behaviour as well. If you don't like being able to pause
scrolling output or work over a serial line with flow control put
'stty -ixon -ixoff' in your .profile or .bashrc. There is nothing
OS-specific about the meaning of xoff.
Les Mikesell
l...@mcs.com
John Smith
Jens Dittmar wrote in message ...
>>>>>> John Smith writes:
>> Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
>
>>> You are still thinking within an MS-DOS mentality. Use a library
>>> such as ncurses.
>
>> MS-DOS still has much better looking and functioning programs so Linux,
>> in this respect, could use a little DOS mentality.
>
> You're just using the wrong programs. :)
>
>> Why are we, with todays modern operating systems, being forced to program
>> our text programs for the lowest common denominator the "DUMB TERMINAL".
>
> You aren't. Control of terminals with extended capabilities is what
>ncurses is made for, so Kaz is right.
>
>> And then people wonder why DOS beat out UNIX.
>
> Are you drunk? ;) DOS seems rather dead to me but UNIX had been refusing
>to die for more than two decades...
>
Actually DOS still survives in Windows 95 and I was speaking more in terms
of the time about 3 years ago when the battle, in the business world, was
between DOS or UNIX based machines. Eventually DOS based machine took over
where they could, except in places where DOS was unfesable or unusable.
This take over of DOS machines over UNIX terminal was largely due to more
user friendly programs under DOS. Have you seen Lotus 123 for UNIX?
>> As a programmer and a user I can state with certainty that Linux needs to
>> allow access to low level console functions including display, mouse, &
>> keyboard.
>
> As a programmer and user I can state it doesn't. :) Seems that opinions
>can differ. For myself I wouldn't like to use such a program, it would fail
>at the first remote session where ncurses usually works fine. Before you
>ask: No, I do not use svgalib software - for the same reasons - and I know
>I'm not alone.
>
> Jens
I do not really want remote session control of such programs at this time.
If I want or need remote session control I will switch to ncurses or slang.
And I figure that most Linux users with personal Linux systems do not use
remote sessions very often so many of them would happily use a program that
can only run on the console (for example, svga software). Eventually I can
envision a special Linux telnet which will allow remote "console" sessions
providing mouse, keyboard, and graphics control functions to programs
running remotely. An improved telnet if you will. And the SVGA comment was
to point the questioner to a possible resolution to his problem.
John Smith
Will Rose wrote in message <88870706...@optional.cts.com>...
>John Smith (sm...@nowhere.com) wrote:
>[...]
>: MS-DOS still has much better looking and functioning programs so Linux,
in
>: this respect, could use a little DOS mentality. And ncurses SUCKS.
SLang
>: while much better also isn't good enougth. Why are we, with todays
modern
>: operating systems, being forced to program our text programs for the
lowest
>: common denominator the "DUMB TERMINAL". And then people wonder why DOS
beat
>: out UNIX. Users aren't going to care, if even beleave, that Linux is a
>: better OS than DOS if Linux programs look like crap and primative when
>: compared to DOS equivalents. As a programmer and a user I can state with
>: certainty that Linux needs to allow access to low level console functions
>: including display, mouse, & keyboard.
>
>Multiplexing displays, mice, and keyboards isn't a trivial task. X is
>admittedly baroque, but if that's what you need to do, that's what you
>need to use. If you want MS-DOS, you know where to find it.
True, but Linux is an ongoing project and incorporation of virtual consoles,
each with their own virtual mouse, keyboard, & display is a practical goal
with many possibilities.
>
>
>will
>c...@crash.cts.com
>
John Smith
Roy Stogner wrote in message ...
>On Sat, 28 Feb 1998 14:56:49 -0500, John Smith <sm...@nowhere.com> wrote:
>>Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
>>>You are still thinking within an MS-DOS mentality. Use a library such as
>>>ncurses.
>
>>MS-DOS still has much better looking and functioning programs so Linux, in
>>this respect, could use a little DOS mentality.
>
>There is no rational justification for this statement. "Better
>looking?" I'm running a Linux terminal program from 500 miles away,
>in full color and my choice of fonts, in a 30 row by 80 column window
>from a cute little shareware Win95 program. When I'm at a terminal
>with a bigger screen, I run the same program in 100x45 size. When I'm
>at a computer with an X server, I run the same program with automatic
>resizing and mouse support. When I'm at a computer with nothing but a
>stupid Win95 telnet client, I run the same program in black and white
>at 80x25. Next year I may be running the same program on an Alpha;
>maybe the guy next to me will be running it on a Merced. Are you
>going to learn how to do direct video access on those too?
Not every program needs to run in all remote sessions. And nothing you said
goes against my statement.
>
> "Better functioning?" This is even worse. I'm multitasking,
>suspending, piping in input, mouse cut-n-pasting, remotely
>administering a web site while learning CGI-scripting, choosing
>between different news readers that (surprise, surprise) use the same
>.newsrc type files to keep me from hitting the same messages twice,
>choosing between different mail readers that use the same folder...
>er, this has to be a troll. I'm going to make up a permanent list of
>"Stuff I can do in Linux but not in DOS/Windows" one of these days
>simply to be able to cut and paste it to posts like this.
>
Again nothing you have said goes against my statement.
>>And ncurses SUCKS. SLang while much better also isn't good enougth.
>>Why are we, with todays modern operating systems, being forced to
>>program our text programs for the lowest common denominator the "DUMB
>>TERMINAL".
>
>Sucks by what measure? I've only used the API once for a simple
>program, so I suppose that may be a problem... but if so, then write
>your own cute front end. The functionality of ncurses beats out
>anything under DOS.
>
I would be glad to, but the current kernel limits what can be done. And
under DOS you can have programs with mouse, extended keyboard access, and
extended display access which ncurses doesn't and probably cannot provide.
>>And then people wonder why DOS beat out UNIX.
>
>Nobody wonders why DOS beat out Unix; DOS beat out Unix because it
>came preinstalled on a hundred million cheap clonable computers.
>It's not too complicated to figure out.
>
Well UNIX wouldn't have been able to run on the original PCs so that is an
unfair comparison. I was thinking mostly of the situation in the business
world where the choice was between a DOS machine or a dumb terminal.
Compare the ease of use of both Wordperfect and Lotus 123 under their UNIX
and DOS versions. The extended keyboard, display, and mouse functionality
of DOS gives the DOS versions of these programs a definate edge.
>By the way, if you want to play the "DOS beat out UNIX" game, I'll
>promise to only run Linux for the next year if you'll only run DOS.
>You game?
>---
And I am not playing any game, you are.
>Roy Stogner
John Smith
Kaz Kylheku wrote in message ...
>In article <6d9q3e$q...@camel20.mindspring.com>,
>John Smith <sm...@nowhere.com> wrote:
>>
>>Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
>>>In article <6cld8p$p...@bgtnsc02.worldnet.att.net>,
>>> <SAM...@worldnet.att.net> wrote:
>>>>How can I disable the linux console/display driver so that my programs
>>>>truly have control of the display.?????
>>>
>>>Don't do this. Linux users will hate your program.
>>
>>
>>I wouldn't, I fact I would like direct access to console text functions as
>>well.
>
>People who run X would just *love* having to switch to a console window
>just to run your program, then.
>
Well thats why this functionality needs to be added into the kernel. I
would not need direct access if these functions were aready provided in a
simple and robust manner. And enhanced virtual console would do.
>>MS-DOS still has much better looking and functioning programs so Linux, in
>>this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
>
>Those text-based Linux installation programs sure look nice and colorful;
>how about those ``3D'' pushbuttons of the RedHat installer?
>
Look at the finer details and you might see what I am talking about. For
example where are the transparent shadows under the text windows which are
so common under DOS programs. This might be a minor detail but this minor
detail can make a program appear significantly more professional and
advanced. And the Linux console programs' functionality is limited by
limitations in availible functions that affect the display, keyboard, and
mouse control.
>>while much better also isn't good enougth. Why are we, with todays modern
>
>I'm afraid you don't know what you are talking about. Ncurses is a terminal
>control library, s-lang is an interpreter for a small stack-based language
>which was developed as a way to complete and extend the JED editor.
>
? This says nothing.
>>operating systems, being forced to program our text programs for the
lowest
>>common denominator the "DUMB TERMINAL". And then people wonder why DOS
beat
>>out UNIX. Users aren't going to care, if even beleave, that Linux is a
>>better OS than DOS if Linux programs look like crap and primative when
>>compared to DOS equivalents. As a programmer and a user I can state with
>>certainty that Linux needs to allow access to low level console functions
>>including display, mouse, & keyboard.
>
>As an experienced UNIX user, I can state with certainty that this is a bad
>idea. There are already ways to manipulate color and get mouse input
without
>going to the bare hardware or OS-specific ioctl's. It's possible to write a
>program which can use ANSI color, and get mouse input, and have it work
under
>`xterm' as well as the Linux console. If you go for the bare metal, it will
>not work in `xterm', nor will it be portable to anything but Linux.
>
I am not looking for such program to run under xterm nor for it to be
universally portable. If such functionality is eventually added to the
kernel a "Linux console" program can be written to allow such programs to
run under X Windows such as DOS programs can do under Win95/NT and OS/2.
>Once your user starts using XWindow, he won't be able to run your program.
>
>Or if your user has Linux on a non-PC, he might also not be able to use
>your program, even in a console!
>
If you means non-x86 this might be true. Of course an x86-console emulator
could be written.
>>>to the console. There is a simple extension mechanism whereby sequences
>>>of the from <ESC>[arg1;arg2;arg3;...] are routed to a switch which
>>>takes arg1 as a command, and the rest of the args as parameters to
>>>the command. For example, there is a code for changing the pitch and
>>>duration of the bell: <ESC>[10;<hertz_value>]. Many capabilities which
>>>cannot be obtained using ordinary ANSI escape sequences are available
this
>>>way.
>>
>>Yes I know and many a user has thought that his machine was frozen when it
>>was just the console that was frozen because the user had accidently
pressed
>>Ctrl+S.
>
>That is a function of the terminal driver (XON/XOFF flow control), and can
be
>turned off in a POSIX standard way. How do you suppose the Emacs editor is
>able to treat `Ctrl-S' as a command (bad idea as it may be)?
>XON/XOFF flow control is in all flavors of the terminal driver, whether
it's a
>pseudo tty, or a serial line, etc.
>
>You can also set it up so that _any_ character will restart the paused
output,
>not just the Ctrl-Q XOFF character.
>
Yes I know this is a function of the terminal driver, an annoying one amoung
others. That why I would like an "enhanced" console with an althernate mode
for user freindly programs.
>Get some clues!
Perhaps you should. You have only critizied me because I have stated the
Linux has a weakness. Don't take Linux down the Amiga and Machintosh path
where eventually its only users will be rabit fanatics. Things improve
only when critizism is allowed.
John Smith
Leslie Mikesell wrote in message <6dced3$9m$1...@Jupiter.Mcs.Net>...
>In article <6d9q3e$q...@camel20.mindspring.com>,
>John Smith <sm...@nowhere.com> wrote:
>>
>>>>How can I disable the linux console/display driver so that my programs
>>>>truly have control of the display.?????
>>>
>>>Don't do this. Linux users will hate your program.
>>
>>I wouldn't, I fact I would like direct access to console text functions as
>>well.
>
>I almost never work at the console of the machines where the programs
>are running, so if anything ever did direct console access it would
>be invisible to me. Why would anyone consider it a good thing to
>not work remotely?
>
I suspect that you are a minority as I beleave that most Linux user are
probably running it on their personal home machine. And after the
implementations that I would like I envision a special "remote console"
which would allow such programs to run remotely with all their functality
and usability intact.
>>MS-DOS still has much better looking and functioning programs so Linux, in
>>this respect, could use a little DOS mentality.
>
>Huh? Perhaps you aren't running X.
I am comparing DOS and Linux's console mode. And X has its own limitations.
And what about Linux machines running CGA or are too low end to run X?
Besides console mode has its own advangtages.
>
>>And ncurses SUCKS. SLang
>>while much better also isn't good enougth. Why are we, with todays modern
>>operating systems, being forced to program our text programs for the
lowest
>>common denominator the "DUMB TERMINAL".
>
>Ummm, perhaps so you can run the program with anything that does terminal
>emulation???
>
Ummm, I do not need to run programs from anywhere. Neither do most people.
>>And then people wonder why DOS beat
>>out UNIX.
>
>Nobody who is aware of the price of each at the time DOS was a reasonable
>choice wonders this.
>
I am thinking of the battle in the business world between UNIX servers with
dumb terminals verses DOS based machines. Just compare Wordperfect's and
Lotus' UNIX and DOS versions. The DOS versions are much more user friendly.
>>Users aren't going to care, if even beleave, that Linux is a
>>better OS than DOS if Linux programs look like crap and primative when
>>compared to DOS equivalents.
>
>So use X.
>
I do not want to write an X program.
>>As a programmer and a user I can state with
>>certainty that Linux needs to allow access to low level console functions
>>including display, mouse, & keyboard.
>
>And as a user who runs programs from many different machines in different
>windows at the same time I can state with certainty that you are wrong.
>
The inclusion of low level functions will not affect your programs. Only
programs which wish to take advantage of the extended console would be
affected, until the "remote console" program which I envision appears.
>>Yes I know and many a user has thought that his machine was frozen when it
>>was just the console that was frozen because the user had accidently
pressed
>>Ctrl+S.
>
>This is correct behaviour as well. If you don't like being able to pause
>scrolling output or work over a serial line with flow control put
>'stty -ixon -ixoff' in your .profile or .bashrc. There is nothing
>OS-specific about the meaning of xoff.
>
> Les Mikesell
> l...@mcs.com
Yes but the console has no need of XON/XOFF along with other serial specific
attributes which currently exist. And there is still the limitation in
detecting Alt & shift key presses and key combinations.
R!ch
On Mon, 2 Mar 1998, John Smith wrote:
> Not every program needs to run in all remote sessions. And nothing you said
> goes against my statement.
Not every program *needs* to run remotely, granted. But well written
software should be *able* to run remotely. That's one of the advantages
of UNIX, remember?
> I would be glad to, but the current kernel limits what can be done. And
You have the kernel source: modify it.
> under DOS you can have programs with mouse, extended keyboard access, and
> extended display access which ncurses doesn't and probably cannot provide.
And these program can *only* run on DOS. There's this programming concept
called "portability", I suggest you look it up sometime... ;-)
--
R!ch (Email is flakey at present: use rich...@keaton.uk.sun.com)
If it ain't analogue, it ain't music.
#include <disclaimer.h> \\|// - ?
(o o)
/==================================oOOo=(_)=oOOo========\
| Richard Teer richar...@uk.sun.com |
| |
| |
| WWW: www.rkdltd.demon.co.uk |
| .oooO |
| ( ) Oooo. |
\===================================\ (==( )==========/
\_) ) /
(_/
John E. Davis
On Sun, 01 Mar 1998 07:18:36 GMT, Kaz Kylheku <bi...@cafe.net>
wrote:
>I'm afraid you don't know what you are talking about. Ncurses is a terminal
>control library, s-lang is an interpreter for a small stack-based language
>which was developed as a way to complete and extend the JED editor.
Not quite. The S-Lang library also contains an independent screen
management library that is a multi-platform (WIN32, Unix, VMS, OS2)
alternative to ncurses. Programs that use the slang screen management
routines include SLRN, SLSC, MOST, MC, DOSEMU, MUTT, and LYNX. The
currently available version of JED do not use this feature, but the
next release will.
--John
Will Rose
: unfair comparison. I was thinking mostly of the situation in the business
: world where the choice was between a DOS machine or a dumb terminal.
: and DOS versions. The extended keyboard, display, and mouse functionality
: of DOS gives the DOS versions of these programs a definate edge.
I'm not sure that even MSDOS later than 1.0 would run on the original
PCs; but from an XT on, there were several Unices available. They
were expensive compared to MSDOS, and had more functionality than
people needed, so they didn't catch on.
T.E.Dickey
In comp.os.linux.development.apps John Smith <sm...@nowhere.com> wrote:
: I would be glad to, but the current kernel limits what can be done. And
: under DOS you can have programs with mouse, extended keyboard access, and
: extended display access which ncurses doesn't and probably cannot provide.
+ ncurses uses the gpm library on console to support mouse.
+ ncurses applications work properly with the keyboard, as set by
'setterm'.
+ the console driver supports all of those nice extra characters
(and you can get at them with a program that uses ncurses, but
it's not a portable feature, hence not well supported - but still
doable with less effort than you're planning).
Jarkko L T Lehto
In article <6d9q3e$q...@camel20.mindspring.com>,
"John Smith" <sm...@nowhere.com> writes:
Have you used GGI already? Try it before you go to that direct access
grab!
Jarkko L T Lehto
In article <m21zwn5...@dittmar.pci.uni-leipzig.de>,
dit...@sonne.tachemie.uni-leipzig.de (Jens Dittmar) writes:
> As a programmer and user I can state it doesn't. :) Seems that opinions
> can differ. For myself I wouldn't like to use such a program, it would fail
> at the first remote session where ncurses usually works fine. Before you
> ask: No, I do not use svgalib software - for the same reasons - and I know
> I'm not alone.
Yups. I agree. SVGAlib sucks hard! It uses direct access functions, i
guess. And anyhow EVERYBODY, try GGI out, it's "The Right Thing To Do" :)
Jarkko L T Lehto
In article <vc7iupy...@saturn.cs.uml.edu>,
acah...@saturn.cs.uml.edu (Albert D. Cahalan) writes:
> If everything works so great, explain how a text-mode app can
> detect the following:
>
> <Shift down><PageDown><DownArrow><Shift up> Standard text selection.
FYI, there is no such thing as "standard text selection" that's just ms
crab!
Chris Engebretson
|> MS-DOS still has much better looking and functioning programs
|> so Linux, in this respect, could use a little DOS mentality.
|> And ncurses SUCKS. SLang while much better also isn't good
|> enougth. Why are we, with todays modern operating systems, being
|> forced to program our text programs for the lowest common
|> denominator the "DUMB TERMINAL". And then people wonder why DOS
|> beat out UNIX.
Kudos on a most brilliant troll! Will you now be going to
rec.pets.cats to ask for the recipe for Kitten Tacos?
Regards,
--
Chris Engebretson - Raytheon STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6940
http://edcwww.cr.usgs.gov/ mailto:enge...@sg1.cr.usgs.gov
Opinions are not those of Raytheon Systems Company or the USGS.
Jens Dittmar
>>>>> John Smith writes:
> This take over of DOS machines over UNIX terminal was largely due to more
I think it was due to the price. I really cannot see any point where DOS
is superior to any Unix, not even considering applications.
> Have you seen Lotus 123 for UNIX?
I haven't even seen 123 for DOS. :) If there would be no Linux I would
have chosen *BSD, if there were no BSD too I had spent some money. DOS was
never an option because it is nothing more than a bootloader for games -
useless for daily work.
> And I figure that most Linux users with personal Linux systems do not use
> remote sessions very often so many of them would happily use a program
> that can only run on the console (for example, svga software).
Regarding the fact that most 'Linux users with personal Linux systems'
prefer X they probably would avoid console-only programs.
> Eventually I can envision a special Linux telnet which will allow remote
> "console" sessions providing mouse, keyboard, and graphics control
> functions to programs running remotely. An improved telnet if you will.
Why to create one more incompatible technique nobody needs? Ever heard of
X? And why the hell do you want to restrict to Linux? I don't get it...
Jens
Mark Brown
"John Smith" <sm...@nowhere.com> writes:
> MS-DOS still has much better looking and functioning programs so Linux, in
> this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
> while much better also isn't good enougth. Why are we, with todays modern
> operating systems, being forced to program our text programs for the lowest
> common denominator the "DUMB TERMINAL". And then people wonder why DOS beat
ncurses doesn't quite confine you to quite that level. Try telling vi
you're running a *really* dumb terminal, and it'll refuse to run.
> out UNIX. Users aren't going to care, if even beleave, that Linux is a
> better OS than DOS if Linux programs look like crap and primative when
> compared to DOS equivalents. As a programmer and a user I can state with
> certainty that Linux needs to allow access to low level console functions
> including display, mouse, & keyboard.
I've never looked, but I suspect that whatever svgalib and X use to
talk to the display hardware will probably still work even if you
don't use graphics mode. Same thing ought to go for the keyboard.
gpm provides mouse access, so you should be able to go and do what you
want.
Of course, you immediately loose all the nice hardware abstraction, so
people who don't use the console - people using X and/or logging in
remotely and the like - won't be able to use your program, nor will
Linux users who don't happen to have the appropriate hardware. As for
users on other operating systems...
[Followups to comp.os.linux.development.apps]
--
Mark Brown mailto:bro...@tardis.ed.ac.uk (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
http://www.ed.ac.uk/~filmsoc/
Kaz Kylheku
In article <6ddp6e$n...@camel19.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>
>Kaz Kylheku wrote in message ...
>>In article <6d9q3e$q...@camel20.mindspring.com>,
>>John Smith <sm...@nowhere.com> wrote:
>>>
>>>Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
>>>>In article <6cld8p$p...@bgtnsc02.worldnet.att.net>,
>>>> <SAM...@worldnet.att.net> wrote:
>>>>>How can I disable the linux console/display driver so that my programs
>>>>>truly have control of the display.?????
>>>>
>>>>Don't do this. Linux users will hate your program.
>>>
>>>
>>>I wouldn't, I fact I would like direct access to console text functions as
>>>well.
>>
>>People who run X would just *love* having to switch to a console window
>>just to run your program, then.
>>
>
>Well thats why this functionality needs to be added into the kernel. I
>would not need direct access if these functions were aready provided in a
>simple and robust manner. And enhanced virtual console would do.
You need to have a clue before you are allowed to say that this or that needs
to go into the kernel.
The xterm is an independent X window program which works on all kinds of
systems, not just Linux. In fact it predates Linux.
Nothing you can do in the kernel will enhance your ability to communicate
between an application and xterm's terminal emulation code.
>>>MS-DOS still has much better looking and functioning programs so Linux, in
>>>this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
>>
>>Those text-based Linux installation programs sure look nice and colorful;
>>how about those ``3D'' pushbuttons of the RedHat installer?
>>
>
>Look at the finer details and you might see what I am talking about. For
>example where are the transparent shadows under the text windows which are
>so common under DOS programs. This might be a minor detail but this minor
Such shadows are done simply by giving the underlying characters the
right attribute to darken their background. In any case, there was
a time where these type of user interface was common place, but that time is
long gone.
>detail can make a program appear significantly more professional and
>advanced. And the Linux console programs' functionality is limited by
>limitations in availible functions that affect the display, keyboard, and
>mouse control.
Maybe you need to reconsider what is ``professional'' and ``advanced''.
To me, that means feature-rich, and free of defects.
>I am not looking for such program to run under xterm nor for it to be
>universally portable.
Like I said, DOS mentality.
> If such functionality is eventually added to the
>kernel a "Linux console" program can be written to allow such programs to
>run under X Windows such as DOS programs can do under Win95/NT and OS/2.
X is independent of the Linux kernel. It runs as a separate process. X
applications talk to the X server through a communication socket; the
applications may even be on a separate machine from the X server (a central
design issue in X).
The kernel simply acts as a provider of the communication mechanism, passing
raw bytes to and fro. There is really nothing you could do in the kernel that
would leverage more functionality from xterm.
Of course, you could write a whole subsystem in the program which would
provide the functionality of the console, but display the characters as
bitmaps in an X window. But then you no longer have a text mode application
through a terminal emulator, but a GUI application. It won't run in an xterm;
instead, it will pop up its own window. This leads to the gain of some new
flexibilities, but to a loss of others. For example, you can no dial in to a
remote machine and run the same program there; it requires a connection to
your X display.
>>Once your user starts using XWindow, he won't be able to run your program.
>>
>>Or if your user has Linux on a non-PC, he might also not be able to use
>>your program, even in a console!
>>
>
>If you means non-x86 this might be true. Of course an x86-console emulator
>could be written.
Fortunately for you, there are DOS emulators already (like DOSEmu), so that
you can continue to work in your preferred paradigm. Just grab a pointer to
b800:0000 and off you go!
>Yes I know this is a function of the terminal driver, an annoying one amoung
>others. That why I would like an "enhanced" console with an althernate mode
>for user freindly programs.
I just said you can turn this off with a simple system call. You can disable
the Xon/Xoff flow control completely, or you can arrange for _any key_ to
restart the paused output. It's not an issue, get over it.
>>Get some clues!
>
>Perhaps you should. You have only critizied me because I have stated the
>Linux has a weakness.
Such as what? The inability to turn off Ctrl-S as a way of pausing
console output?
Umm no, it's you who has a weakness. You are trying to squeeze a square
peg into a round hole.
Anyway, what you are trying to do _can_ be done. You can get raw input from
the Linux console. How do you think that Linux games like SVGA Quake can
detect that you are holding down ``Shift'' or ``Ctrl''?
Use the source, Luke.
Don't take Linux down the Amiga and Machintosh path
>where eventually its only users will be rabit fanatics. Things improve
>only when critizism is allowed.
Reality check: nobody cares about console applications; you seem to be
occuping this middle ground that has been abandoned by ``professsional''
application developers by sometime in the late 80's. Nowadays, unsophisticated
users want real GUI applications, not spiffed-up text displays.
The power users who continue to use text consoles can see beyond a colorful
personality with shadowed buttons, and are more interested in raw
functionality; the dummies have moved on. You can have that colorful
personality with mouse support and all. It's just that a few details are
difficult, or impossible to do portably. You mentioned, for instance, that
you would like the pressing and releasing of 'Alt' to trigger a menu. This
may be a ``Microsoft standard '' way of doing things, but is not generally
accepted and is foreign to the Linux culture. The alt key is a ``modifier'',
which means that it should be used with another key. There is a bit of a
convention which terminal emulators follow that an alt-modified key is sent
with its eighth bit set, so that Alt-Shift-A comes out as 0x41 | 0x80, or
0xC1. these terminals won't generate a character which just means ``Alt was
pressed''. You might have to compromise a little and allow Alt- commands, but
not Alt by itself as a command.
Kaz Kylheku
In article <vc7iupy...@saturn.cs.uml.edu>,
Albert D. Cahalan <acah...@saturn.cs.uml.edu> wrote:
>The following is insane, but DOS can do it:
>Lets say I wanted bright white text on a background of dark blue and
>black blotches. I want to quickly scroll the background underneath
>the text. Obviously, the cursor has to stay in one spot so that the
>user can edit text. This needs to run on a DX4-100 at least, which
>is more powerful that DOS would need and far more powerful than the
>Unix machines of 15 years ago.
MS-DOS can do that? Name the MS-DOS interrupt which provides this service,
please.
Kaz Kylheku
In article <6dced3$9m$1...@Jupiter.Mcs.Net>, Leslie Mikesell <l...@MCS.COM> wrote:
>This is correct behaviour as well. If you don't like being able to pause
>scrolling output or work over a serial line with flow control put
>'stty -ixon -ixoff' in your .profile or .bashrc. There is nothing
>OS-specific about the meaning of xoff.
Or 'stty ixany' if you like pausing with Ctrl-S, but don't like hunting
for Ctrl-Q to restart the output.
Kaz Kylheku
In article <6ddqgo$9...@camel19.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>I suspect that you are a minority as I beleave that most Linux user are
>probably running it on their personal home machine. And after the
>implementations that I would like I envision a special "remote console"
>which would allow such programs to run remotely with all their functality
>and usability intact.
It was done in 1984 at MIT. They called the project `XWindow', or X,
and had it out the door by sometime around 1986. Of course, by then computing
machinery was so sophisticated that they made it pixel based rather than text
based.
With X, the user can effectively have a graphical console to a remote machine.
The client/server X protocol provides the location transparency.
I'm afraid you are at least twenty years behind the times with your idea
of a remotable console display.
>>>MS-DOS still has much better looking and functioning programs so Linux, in
>>>this respect, could use a little DOS mentality.
>>
>>Huh? Perhaps you aren't running X.
>
>I am comparing DOS and Linux's console mode. And X has its own limitations.
Yeah, but a program which is specific to PC display or keyboard hardware
doesn't, right?
>And what about Linux machines running CGA or are too low end to run X?
>Besides console mode has its own advangtages.
Where can you get a CGA adapter these days? Maybe you can rip one out of an
old PC/XT, if you can find one. If you can't afford 50 bucks for a SVGA video
card, why would you complain that your text boxes on the screen don't have
shadows under them? With the poor quality of a CGA adapter, such things are
hard to read anyway.
>Ummm, I do not need to run programs from anywhere. Neither do most people.
But most people have CGA adapters in their Pentiums, right? And most people
demand pretty text-based applications?
>>>And then people wonder why DOS beat
>>>out UNIX.
>>
>>Nobody who is aware of the price of each at the time DOS was a reasonable
>>choice wonders this.
>>
>
>I am thinking of the battle in the business world between UNIX servers with
>dumb terminals verses DOS based machines. Just compare Wordperfect's and
>Lotus' UNIX and DOS versions. The DOS versions are much more user friendly.
I wouldn't use ``user friendly'' in the same sentence as ``Word Perfect''---
at least when talking about version 5 or prior. Blank screen, lame function
keys. The UNIX versions of text-based WP are/were about as unfriendly as the
DOS versions. I've actually seen/used them.
>Yes but the console has no need of XON/XOFF along with other serial specific
>attributes which currently exist. And there is still the limitation in
>detecting Alt & shift key presses and key combinations.
It's called object oriented design. Because a Console ``is a kind of'' tty
device, it inherits the properties from that base class, including XOn/Xoff,
variable baud rate, etc. The console surely doesn't need a baud rate,
but it has one by way of ``inheritance''. Thus programs which don't care
which particular derived ``kind of'' tty they are talking to can depend
on that baud rate to be there, and for methods related to the baud rate
to do something sensible.
Xon/Xoff _is_ useful in a console, however, believe it or not. You can use
Ctrl-S to pause output. Why do you suppose it works in DOS? Even the Apple II
supported Ctrl-S as a way of pausing output even though its console wasn't a
serial tty that could be flooded.
Peter Seebach
In article <6d9q3e$q...@camel20.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>MS-DOS still has much better looking and functioning programs so Linux, in
>while much better also isn't good enougth. Why are we, with todays modern
>operating systems, being forced to program our text programs for the lowest
>common denominator the "DUMB TERMINAL".
Because it's still one of the most common interfaces. I'm typing on a
console, right? Well, sort of - it's actually an emulated console, and
a lot of the programs I'm running are actually running about 850 miles
from me. So, while it sounds cool at first, it *sucks* to have everything
need access to the hardware.
A good ncurses-based interface can do everything this console supports -
and can do it remotely, too.
I spend more time in emulated windows than on "real" consoles. I may
not be typical, but, for this market, I probably am.
>And then people wonder why DOS beat
>out UNIX.
No, they don't. It's because Bob in Accounting got something from the
company that made the typewriter he was replacing in 1980.
>As a programmer and a user I can state with
>certainty that Linux needs to allow access to low level console functions
>including display, mouse, & keyboard.
It's called X. If you want a display driver, you know where to find it.
-s
--
Copyright '98, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Not speaking for my employer. Questions on C/Unix? Send mail for help.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Peter Seebach
In article <Ep76u...@igsrsparc2.er.usgs.gov>,
Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
>Kudos on a most brilliant troll! Will you now be going to
>rec.pets.cats to ask for the recipe for Kitten Tacos?
That'd be a pretty weak troll. I actually got a couple bites last year
on "what's this strange fungus growing over most of my cat's body, but
not on the pads of its feet? I shaved it off, but it grew back. The
cat licks it a lot."
I've got a great one for this year; I can hardly wait for April to begin.
Kaz Kylheku
In article <6ddqgo$9...@camel19.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>And what about Linux machines running CGA or are too low end to run X?
>Besides console mode has its own advangtages.
By the way, it's possible to run Linux without even a CGA or MDA adapter.
If you have _no_ adapter at all, it's possible to use a terminal
hooked up to your serial port as a console.
I actually know a number of people who have such terminals (including myself),
but nobody who has a CGA video card. A terminal can coexist with your
existing video card; a CGA card cannot. If your monitor or video card
blows up, you can still log in to your machine using the attached terminal.
Dann Corbit
Peter Seebach wrote in message ...
>In article <Ep76u...@igsrsparc2.er.usgs.gov>,
>Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
>>Kudos on a most brilliant troll! Will you now be going to
>>rec.pets.cats to ask for the recipe for Kitten Tacos?
>
>That'd be a pretty weak troll. I actually got a couple bites last year
>on "what's this strange fungus growing over most of my cat's body, but
>not on the pads of its feet? I shaved it off, but it grew back. The
>cat licks it a lot."
>
>I've got a great one for this year; I can hardly wait for April to begin.
The whole problem with a cat troll of that nature is that there is no 'I hate
cats' newsgroup to crosspost. Now, a 'cats are better than dogs because..'
post, crossposted to alt.pets.dogs might be good. Even better, if
crossposting to both groups might be 'I have been feeding my cougar-hunting
dog kittens to get him in the mood. Is this an effective way to get him to be
more aggressive?' Of course, animal rights and hunting groups should be
included, along with philosophy and maybe a few odd religious groups.
--
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-FAQ ftp: ftp://rtfm.mit.edu, C-FAQ Book: ISBN 0-201-84519-9
Try "C Programming: A Modern Approach" ISBN 0-393-96945-2
Want Software? Algorithms? Pubs? http://www.infoseek.com
samuel igwe
Many people are divided when it comes to this issue of direct access to
low level hardware.
personally, I have always loved DOS, irregardless of its problems. There
is no substitute in my opinion for direct access.
Speed and size are the main benefits. I am a devoted console user who
detests the overhead of Xwindows. Ultimately, many will argue that in
this age of Pentium II systems there is little or no loss in speed with
graphics only apps. I have a 486 dx4 and have no desire to upgrade any
time soon.
In short, it seems odd that this sort of question creates such a
response as I have seen in these newsgroup(s). For me it changes
notting, I have already completed my textmode library that is smaller
and magnitude of times more efficient that ncurses or any similar
library for the console in text mode. It cannot be used in
Xwindows,xterms nor from remote logins as I am not concerned with any of
those. I am on the console 97.9% of the time.
These portable libraries are not the solution. There are many aspects of
hardware devices that these libraries never address. All these things
are available to me with direct access -=- even at the cost of setuid
root.
I have already begun writing the clone of DOS edit.exe for which this
library was written. The editor is one of many console applications I
have in mind. It is geared towards those of us wishing to run an
equivalent to the Dos editor (ver 6.0+) in the linux console.
This is no attempt to convert anyone. If you want to live in the world
of black and white tty screens, terminal input restricted libraries and
programs requiring massive processor speed and storage just to maintain
portability among unix like systems -- let it be your choice.
Much to your sorrow!.
I will not allow anyone to restrict me.
I PAID for the various hardware devices in my computer and do not feel
that I have to be restricted to utilizing them in X.
if you have a problem with that DOS like mentality -- "get stuffed"!!
SAMUEL IGWE
Albert D. Cahal
> > Sucks by what measure? I've only used the API once for a simple
> > program, so I suppose that may be a problem... but if so, then write
> > your own cute front end. The functionality of ncurses beats out
> > anything under DOS.
>
--
Unix [chapter 6, verse 2]
Our OS who arth in cpu,
UNIX be thy name,
Thy programs run, thy syscalls done,
In Kernel as it is in user.
Amen.
samuel igwe
John
I am glad someone like you seems to see the big picture. Let the rest of
them suffer under Xwindows. Blast them all.
The console will ALWAYS have its advantages over X.
I am one of a majority of linux/freebsd users running our systems on a
personal home machine.
We have no need nor desire for remote logins, nor programs that work in
X and xterms.
I personally care notting for portability across differing hardware
architectures. If theres a problem the user should write an emulator.
There should be better console programs. especially for the Pc and x86
architecture. Currently to do any sound editing I have to switch to X
and use xwave. To view pictures I have to switch to X. To use email
(with a better interface) I have to switch to X. In comparison to the
console -- Xwindows possesses a majority of much more powerful
applications.
Why should it be this way.???
Just to maintain portability??? --
I wonder how X communicates with my SVGA pci card. If not direct access
then how? --
AMUSING!.
to say the least.
SAMUEL IGWE
John Smith wrote:
>
> Leslie Mikesell wrote in message <6dced3$9m$1...@Jupiter.Mcs.Net>...
> >In article <6d9q3e$q...@camel20.mindspring.com>,
> >John Smith <sm...@nowhere.com> wrote:
> >>
> >>>>How can I disable the linux console/display driver so that my programs
> >>>>truly have control of the display.?????
> >>>
> >>>Don't do this. Linux users will hate your program.
> >>
> >>I wouldn't, I fact I would like direct access to console text functions as
> >>well.
> >
> >I almost never work at the console of the machines where the programs
> >are running, so if anything ever did direct console access it would
> >be invisible to me. Why would anyone consider it a good thing to
> >not work remotely?
> >
>
> I suspect that you are a minority as I beleave that most Linux user are
> probably running it on their personal home machine. And after the
> implementations that I would like I envision a special "remote console"
> which would allow such programs to run remotely with all their functality
> and usability intact.
>
> >>MS-DOS still has much better looking and functioning programs so Linux, in
> >>this respect, could use a little DOS mentality.
> >
> >Huh? Perhaps you aren't running X.
>
> I am comparing DOS and Linux's console mode. And X has its own limitations.
> And what about Linux machines running CGA or are too low end to run X?
> Besides console mode has its own advangtages.
>
> >
> >>And ncurses SUCKS. SLang
> >>while much better also isn't good enougth. Why are we, with todays modern
> >>operating systems, being forced to program our text programs for the
> lowest
> >>common denominator the "DUMB TERMINAL".
> >
> >Ummm, perhaps so you can run the program with anything that does terminal
> >emulation???
> >
>
> Ummm, I do not need to run programs from anywhere. Neither do most people.
>
> >>And then people wonder why DOS beat
> >>out UNIX.
> >
> >Nobody who is aware of the price of each at the time DOS was a reasonable
> >choice wonders this.
> >
>
> I am thinking of the battle in the business world between UNIX servers with
> dumb terminals verses DOS based machines. Just compare Wordperfect's and
> Lotus' UNIX and DOS versions. The DOS versions are much more user friendly.
>
> >>Users aren't going to care, if even beleave, that Linux is a
> >>better OS than DOS if Linux programs look like crap and primative when
> >>compared to DOS equivalents.
> >
> >So use X.
> >
>
> I do not want to write an X program.
>
> >>As a programmer and a user I can state with
> >>certainty that Linux needs to allow access to low level console functions
> >>including display, mouse, & keyboard.
> >
> >And as a user who runs programs from many different machines in different
> >windows at the same time I can state with certainty that you are wrong.
> >
>
> The inclusion of low level functions will not affect your programs. Only
> programs which wish to take advantage of the extended console would be
> affected, until the "remote console" program which I envision appears.
>
> >>Yes I know and many a user has thought that his machine was frozen when it
> >>was just the console that was frozen because the user had accidently
> pressed
> >>Ctrl+S.
> >
> >This is correct behaviour as well. If you don't like being able to pause
> >scrolling output or work over a serial line with flow control put
> >'stty -ixon -ixoff' in your .profile or .bashrc. There is nothing
> >OS-specific about the meaning of xoff.
> >
> > Les Mikesell
> > l...@mcs.com
>
> Yes but the console has no need of XON/XOFF along with other serial specific
> attributes which currently exist. And there is still the limitation in
> detecting Alt & shift key presses and key combinations.
--
Chris Engebretson
In article <sgFK.201$FG4.3...@ptah.visi.com>,
se...@plethora.net (Peter Seebach) writes:
|> In article <Ep76u...@igsrsparc2.er.usgs.gov>,
|> Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
|>
|> >Kudos on a most brilliant troll! Will you now be going to
|> >rec.pets.cats to ask for the recipe for Kitten Tacos?
|>
|> That'd be a pretty weak troll. I actually got a couple bites
|> last year on "what's this strange fungus growing over most of
|> my cat's body, but not on the pads of its feet? I shaved it off,
|> but it grew back. The cat licks it a lot."
Did you ever find out what it was? :-)
|> I've got a great one for this year; I can hardly wait for April
|> to begin.
You've got a way to go, buddy; it's still September by my calendar.
Will Rose
samuel igwe (SAM...@worldnet.att.net) wrote:
: Many people are divided when it comes to this issue of direct access to
: low level hardware.
: personally, I have always loved DOS, irregardless of its problems. There
: is no substitute in my opinion for direct access.
: Speed and size are the main benefits. I am a devoted console user who
: detests the overhead of Xwindows. Ultimately, many will argue that in
: this age of Pentium II systems there is little or no loss in speed with
: graphics only apps. I have a 486 dx4 and have no desire to upgrade any
: time soon.
Well, yes, there is no substitute for direct access; if you need to
reprogram the hardware MSDOS is very convenient. But I do that only
every year or so; the rest of the time I want to be isolated from the
hardware.
I use a DX4 and run a very nice GUI on a single user machine; it's
not a problem, and it's adequately quick. For the Unix boxes I
don't even use X; telnet's fine. But there are a lot of jobs that
I'd rather do on a good windowing system.
Peter Seebach
In article <6dfb1g$s...@bgtnsc02.worldnet.att.net>,
samuel igwe <SAM...@worldnet.att.net> wrote:
>Many people are divided when it comes to this issue of direct access to
>low level hardware.
Yes; the ones who are divided like it. :)
>personally, I have always loved DOS, irregardless of its problems. There
>is no substitute in my opinion for direct access.
True; there is also no substitute for falling from a height to your death
on a pile of sharp rocks. I mean, nothing else is at all like it.
>Speed and size are the main benefits.
I'll make you a deal. You write code that uses direct access to a
video chipset. I'll write code that uses calls to a generic API.
Which one will be faster?
Go play GLQuake, and compare it with DOS Quake, and you tell me.
>I am a devoted console user who
>detests the overhead of Xwindows. Ultimately, many will argue that in
>this age of Pentium II systems there is little or no loss in speed with
>graphics only apps. I have a 486 dx4 and have no desire to upgrade any
>time soon.
Then you, of all people, should appreciate the importance of flexible
code that doesn't assume so much about what it's running on.
>In short, it seems odd that this sort of question creates such a
>response as I have seen in these newsgroup(s). For me it changes
>notting, I have already completed my textmode library that is smaller
>and magnitude of times more efficient that ncurses or any similar
>library for the console in text mode. It cannot be used in
>Xwindows,xterms nor from remote logins as I am not concerned with any of
>those. I am on the console 97.9% of the time.
Wonderful; if it doesn't have to actually *run*, I can write a library
which has the same feature list and does everything in a microsecond.
I'm on the "console" right now, and it's not the one you would want direct
access to. Sorry.
>These portable libraries are not the solution. There are many aspects of
>hardware devices that these libraries never address. All these things
>are available to me with direct access -=- even at the cost of setuid
>root.
There are many aspects of hardware devices that you can't access, and my
portable code can.
Do you want to bet on whether your code is faster or slower than a modern
X server? I'd probably bet on that - because an accelerated X server can
use more hardware than you can. It's not relying on one pathetic CPU, it
can throw the hard work off to other processors.
>I have already begun writing the clone of DOS edit.exe for which this
>library was written. The editor is one of many console applications I
>have in mind. It is geared towards those of us wishing to run an
>equivalent to the Dos editor (ver 6.0+) in the linux console.
Why would you bother? It's a sucky, ugly, editor.
>This is no attempt to convert anyone. If you want to live in the world
>of black and white tty screens, terminal input restricted libraries and
>programs requiring massive processor speed and storage just to maintain
>portability among unix like systems -- let it be your choice.
Who's limited to Unix? My portable code runs on my Mac too.
>I will not allow anyone to restrict me.
Portability isn't a restriction, it's a freedom.
>I PAID for the various hardware devices in my computer and do not feel
>that I have to be restricted to utilizing them in X.
Wonderful. I *paid* for a lot of hardware that isn't all exactly the same
as my other hardware, and I don't feel that I have to be restricted to running
each program only on the machine I was using when I wrote it.
>if you have a problem with that DOS like mentality -- "get stuffed"!!
Happily; I'll go take my marketable skills, earn a living, and buy more
pizza.
Fundementally, non-portable code will lose in speed for the remainder
of the forseeable future, and probably far beyond. Portable code has
all the hard things done for it, correctly. Your direct access methods
may not survive SMP; my code will. Your code can't use a new graphics
accelerator; mine can. Your code can't take full advantage of a sound
card with a DSP. Mine can. If you finally get yours running on one DSP,
it won't work on the next one that's twice as fast. Mine will.
You lose on speed, you lose on featuress, you lose on choices. You lose.
John Smith
Jens Dittmar wrote in message ...
>>>>>> John Smith writes:
>> This take over of DOS machines over UNIX terminal was largely due to more
>> user friendly programs under DOS.
>
> I think it was due to the price. I really cannot see any point where DOS
>is superior to any Unix, not even considering applications.
>
I find it astonishing that you cannot see any DOS attribute which is
superior to a comparable UNIX attribute. It seams to me that you are
extremely biased in your opinion.
>> Have you seen Lotus 123 for UNIX?
>
> I haven't even seen 123 for DOS. :) If there would be no Linux I would
>have chosen *BSD, if there were no BSD too I had spent some money. DOS was
>never an option because it is nothing more than a bootloader for games -
>useless for daily work.
>
>> And I figure that most Linux users with personal Linux systems do not use
>> remote sessions very often so many of them would happily use a program
>> that can only run on the console (for example, svga software).
>
> Regarding the fact that most 'Linux users with personal Linux systems'
>prefer X they probably would avoid console-only programs.
>
What about the users who do not like X or cannot run it?
>> Eventually I can envision a special Linux telnet which will allow remote
>> "console" sessions providing mouse, keyboard, and graphics control
>> functions to programs running remotely. An improved telnet if you will.
>
> Why to create one more incompatible technique nobody needs? Ever heard of
>X? And why the hell do you want to restrict to Linux? I don't get it...
>
For improved functionality as I have stated before. And everybody doesn't
need portability to every OS in the world which by the way current UNIX code
is not (not even to the majority of systems). Besides the lowlevel
functions can be encapsulated in libraries which automatically to ncurses
when not on the console.
> Jens
John Smith
Jarkko L T Lehto wrote in message <6de28r$jdp$3...@oravannahka.Helsinki.FI>...
Irrelevant, its the standard now no matter by who.
John Smith
Kaz Kylheku wrote in message <6NEK.1745$Jb.28...@brie.direct.ca>...
>In article <vc7iupy...@saturn.cs.uml.edu>,
Yes it can. Either through bios video functions, DOS video functions, or by
directly accessing the color video display at segment C000
John Smith
Peter Seebach wrote in message <51HK.229$FG4.4...@ptah.visi.com>...
>In article <6dfb1g$s...@bgtnsc02.worldnet.att.net>,
>samuel igwe <SAM...@worldnet.att.net> wrote:
>>Many people are divided when it comes to this issue of direct access to
>>low level hardware.
>
>Yes; the ones who are divided like it. :)
>
What a powerful argument.
>>personally, I have always loved DOS, irregardless of its problems. There
>>is no substitute in my opinion for direct access.
>
>True; there is also no substitute for falling from a height to your death
>on a pile of sharp rocks. I mean, nothing else is at all like it.
>
Another powerful argument. DOS seams to have done in the decade in which it
dominated and, horrors, it allowed direct access.
>>Speed and size are the main benefits.
>
>I'll make you a deal. You write code that uses direct access to a
>video chipset. I'll write code that uses calls to a generic API.
>
Open GL is just a thin wrapping around low level video functions. And on
some video cards that wrapping practically doesn't exist.
>Which one will be faster?
>
>Go play GLQuake, and compare it with DOS Quake, and you tell me.
>
First of all GL Quake will benifit from accelerated functions on most video
boards. Second of all it is a 32bit program and not hampered by 16bit x86
segmented memory.
>>I am a devoted console user who
>>detests the overhead of Xwindows. Ultimately, many will argue that in
>>this age of Pentium II systems there is little or no loss in speed with
>>graphics only apps. I have a 486 dx4 and have no desire to upgrade any
>>time soon.
>
>Then you, of all people, should appreciate the importance of flexible
>code that doesn't assume so much about what it's running on.
>
Sure I could write that way, so could he, but not many users would
appreciate programs which only input/output 1 line at a time. But at least
it will run anywhere.
>>In short, it seems odd that this sort of question creates such a
>>response as I have seen in these newsgroup(s). For me it changes
>>notting, I have already completed my textmode library that is smaller
>>and magnitude of times more efficient that ncurses or any similar
>>library for the console in text mode. It cannot be used in
>>Xwindows,xterms nor from remote logins as I am not concerned with any of
>>those. I am on the console 97.9% of the time.
>
>Wonderful; if it doesn't have to actually *run*, I can write a library
>which has the same feature list and does everything in a microsecond.
>I'm on the "console" right now, and it's not the one you would want direct
>access to. Sorry.
>
>>These portable libraries are not the solution. There are many aspects of
>>hardware devices that these libraries never address. All these things
>>are available to me with direct access -=- even at the cost of setuid
>>root.
>
>There are many aspects of hardware devices that you can't access, and my
>portable code can.
You seam to have that backwards. After all portable code eventually calls
or is converted to code specific to a particular system. And the inherit
trade off for protable code is usually a loss of functionality or of what is
possible.
>
>Do you want to bet on whether your code is faster or slower than a modern
>X server? I'd probably bet on that - because an accelerated X server can
>use more hardware than you can. It's not relying on one pathetic CPU, it
>can throw the hard work off to other processors.
Didn't he just mention he did not want to use X. And by the way all X
servers that I have seen are inheritly non-protable and must call many low
level functions.
>
>>I have already begun writing the clone of DOS edit.exe for which this
>>library was written. The editor is one of many console applications I
>>have in mind. It is geared towards those of us wishing to run an
>>equivalent to the Dos editor (ver 6.0+) in the linux console.
>
>Why would you bother? It's a sucky, ugly, editor.
That sucky editor made DOS 5.0 a success. People upgraded just for the
editor. And it is definately more usable and user friendly than vi or emacs
despite having less functions.
>
>>This is no attempt to convert anyone. If you want to live in the world
>>of black and white tty screens, terminal input restricted libraries and
>>programs requiring massive processor speed and storage just to maintain
>>portability among unix like systems -- let it be your choice.
>
>Who's limited to Unix? My portable code runs on my Mac too.
>
>>I will not allow anyone to restrict me.
>
>Portability isn't a restriction, it's a freedom.
>
Portability is restrictive by its very nature. It is the trade off for
portability's benefits.
>>I PAID for the various hardware devices in my computer and do not feel
>>that I have to be restricted to utilizing them in X.
>
>Wonderful. I *paid* for a lot of hardware that isn't all exactly the same
>as my other hardware, and I don't feel that I have to be restricted to
running
>each program only on the machine I was using when I wrote it.
>
Most PC hardware have some compatability level amoung different vendors.
For example, text modes through VGA for video cards.
>>if you have a problem with that DOS like mentality -- "get stuffed"!!
>
>Happily; I'll go take my marketable skills, earn a living, and buy more
>pizza.
>
I am not sure how marketable you are if you limit your coding practices in
such a way to only produce very portable code. Portability is nice but
sometimes you need to access non portable low level functions.
>Fundementally, non-portable code will lose in speed for the remainder
>of the forseeable future, and probably far beyond. Portable code has
>all the hard things done for it, correctly. Your direct access methods
>may not survive SMP; my code will. Your code can't use a new graphics
>accelerator; mine can. Your code can't take full advantage of a sound
>card with a DSP. Mine can. If you finally get yours running on one DSP,
>it won't work on the next one that's twice as fast. Mine will.
>
>You lose on speed, you lose on featuress, you lose on choices. You lose.
>
Low level access need not limit choice.
John Smith
Kaz Kylheku wrote in message ...
>In article <51HK.229$FG4.4...@ptah.visi.com>,
>Peter Seebach <se...@plethora.net> wrote:
>>In article <6dfb1g$s...@bgtnsc02.worldnet.att.net>,
>>samuel igwe <SAM...@worldnet.att.net> wrote:
>>>Many people are divided when it comes to this issue of direct access to
>>>low level hardware.
>>
>>Yes; the ones who are divided like it. :)
>>
>>>personally, I have always loved DOS, irregardless of its problems. There
>>>is no substitute in my opinion for direct access.
>>
>>True; there is also no substitute for falling from a height to your death
>>on a pile of sharp rocks. I mean, nothing else is at all like it.
>
>In fact, there is a quote from Lewis Caroll that rather fits. It did
>cross my mind when I first read the above.
>
> "There's nothing like eating hay when you're faint," the White King
>remarked to Alice, as he munched away.
> "I should think throwing cold water over you would be better," Alice
>suggested: "--or some sal-volatile."
> "I didn't say there was nothing better," the King replied. "I said
>there was nothing like it." Which Alice did not venture to deny.
>
>
>>>Speed and size are the main benefits.
>>
>>I'll make you a deal. You write code that uses direct access to a
>>video chipset. I'll write code that uses calls to a generic API.
>
>I bet the user base will *instantly* flock to the one which can refresh the
>screen a microsecond faster! :)
>
>>Which one will be faster?
>
>The one written in 8086 assembly language. But if you want real speed, you
>write it in 8080 assemby language, and translate with an 8086 assembler.
>
>That is, if you are not concerned about portability back to the 8008 and
4004.
Actually it would be the one in pentium pro/II optomized 32bit x86 assembly
code.
John Smith
R!ch wrote in message ...
>On Mon, 2 Mar 1998, John Smith wrote:
>
>> Not every program needs to run in all remote sessions. And nothing you
said
>> goes against my statement.
>
>Not every program *needs* to run remotely, granted. But well written
>software should be *able* to run remotely. That's one of the advantages
>of UNIX, remember?
>
I am not asking for this advantage to be removed just an alternative to be
provided.
>> I would be glad to, but the current kernel limits what can be done. And
>
>You have the kernel source: modify it.
>
>> under DOS you can have programs with mouse, extended keyboard access, and
>> extended display access which ncurses doesn't and probably cannot
provide.
>
>And these program can *only* run on DOS. There's this programming concept
>called "portability", I suggest you look it up sometime... ;-)
>
I have many DOS programs which are mostly portable. Except for a relatively
few low level video functions which are not currently provided under Linux.
>--
>R!ch (Email is flakey at present: use rich...@keaton.uk.sun.com)
>
>If it ain't analogue, it ain't music.
>#include <disclaimer.h> \\|// - ?
> (o o)
> /==================================oOOo=(_)=oOOo========\
> | Richard Teer richar...@uk.sun.com |
> | |
> | |
> | WWW: www.rkdltd.demon.co.uk |
> | .oooO |
> | ( ) Oooo. |
> \===================================\ (==( )==========/
> \_) ) /
> (_/
>
>
John Smith
T.E.Dickey wrote in message <6dedqh$a...@clarknet.clark.net>...
>In comp.os.linux.development.apps John Smith <sm...@nowhere.com> wrote:
>: I would be glad to, but the current kernel limits what can be done. And
>: under DOS you can have programs with mouse, extended keyboard access, and
>: extended display access which ncurses doesn't and probably cannot
provide.
>"probably" you are just ignorant (there's no excuse for that).
>
> + ncurses uses the gpm library on console to support mouse.
Unfortunately gpm doesn't integrate too well nor should it be expected too
as it is a separate program and library. Perhaps some kind of integration
into the kernel would help.
>
> + ncurses applications work properly with the keyboard, as set by
> 'setterm'.
>
setterm will not provide all the keyboard functionality that I may require
for some programs.
> + the console driver supports all of those nice extra characters
> (and you can get at them with a program that uses ncurses, but
> it's not a portable feature, hence not well supported - but still
> doable with less effort than you're planning).
>
unfortuately ncurses looks and feels primative and this significantly limits
one's programs.
>--
>Thomas E. Dickey
>dic...@clark.net
>http://www.clark.net/pub/dickey
John Smith
I am not asking for such a program to run in xterm. A special xterm-like "X
console" would be provided for running under X.
>>>>MS-DOS still has much better looking and functioning programs so Linux,
in
>>>>this respect, could use a little DOS mentality. And ncurses SUCKS.
SLang
>>>
>>>Those text-based Linux installation programs sure look nice and colorful;
>>>how about those ``3D'' pushbuttons of the RedHat installer?
>>>
>>
>>Look at the finer details and you might see what I am talking about. For
>>example where are the transparent shadows under the text windows which are
>>so common under DOS programs. This might be a minor detail but this minor
>
>Such shadows are done simply by giving the underlying characters the
>right attribute to darken their background. In any case, there was
>a time where these type of user interface was common place, but that time
is
>long gone.
>
Not true. Just because it is not in Linux doesn't mean it is long gone.
>>detail can make a program appear significantly more professional and
>>advanced. And the Linux console programs' functionality is limited by
>>limitations in availible functions that affect the display, keyboard, and
>>mouse control.
>
>Maybe you need to reconsider what is ``professional'' and ``advanced''.
>To me, that means feature-rich, and free of defects.
>
Just because a program looks better doesn't mean that it is feature-poor and
full of defects.
>>I am not looking for such program to run under xterm nor for it to be
>>universally portable.
>
>Like I said, DOS mentality.
>
This says nothing. And I use all kinds of OSes so I am influenced by all
their different interfaces. And I advise against fanaticism, look what
happened to Agima and the Machintosh.
>> If such functionality is eventually added to the
>>kernel a "Linux console" program can be written to allow such programs to
>>run under X Windows such as DOS programs can do under Win95/NT and OS/2.
>
>X is independent of the Linux kernel. It runs as a separate process. X
>applications talk to the X server through a communication socket; the
>applications may even be on a separate machine from the X server (a central
>design issue in X).
>
>The kernel simply acts as a provider of the communication mechanism,
passing
>raw bytes to and fro. There is really nothing you could do in the kernel
that
>would leverage more functionality from xterm.
>
>Of course, you could write a whole subsystem in the program which would
>provide the functionality of the console, but display the characters as
>bitmaps in an X window. But then you no longer have a text mode
application
>through a terminal emulator, but a GUI application. It won't run in an
xterm;
>instead, it will pop up its own window. This leads to the gain of some new
>flexibilities, but to a loss of others. For example, you can no dial in to
a
>remote machine and run the same program there; it requires a connection to
>your X display.
>
Well the special "X console" can definately be made portable.
John Smith
Kaz Kylheku wrote in message
>In article <6ddqgo$9...@camel19.mindspring.com>,
>John Smith <sm...@nowhere.com> wrote:
>>I suspect that you are a minority as I beleave that most Linux user are
>>probably running it on their personal home machine. And after the
>>implementations that I would like I envision a special "remote console"
>>which would allow such programs to run remotely with all their functality
>>and usability intact.
>
>It was done in 1984 at MIT. They called the project `XWindow', or X,
>and had it out the door by sometime around 1986. Of course, by then
computing
>machinery was so sophisticated that they made it pixel based rather than
text
>based.
>
>With X, the user can effectively have a graphical console to a remote
machine.
>The client/server X protocol provides the location transparency.
>
>I'm afraid you are at least twenty years behind the times with your idea
>of a remotable console display.
>
Again X does not have a text mode, the main area which I beleave needs
improvement.
>>>>MS-DOS still has much better looking and functioning programs so Linux,
in
>>>>this respect, could use a little DOS mentality.
>>>
>>>Huh? Perhaps you aren't running X.
>>
>>I am comparing DOS and Linux's console mode. And X has its own
limitations.
>
>Yeah, but a program which is specific to PC display or keyboard hardware
>doesn't, right?
>
Considering that all the levels of abstraction eventually lead to the PC's
display and keyboard any limitation in them would exist in the current Linux
console but not visa-versa.
>>And what about Linux machines running CGA or are too low end to run X?
>>Besides console mode has its own advangtages.
>
>Where can you get a CGA adapter these days? Maybe you can rip one out of an
>old PC/XT, if you can find one. If you can't afford 50 bucks for a SVGA
video
>card, why would you complain that your text boxes on the screen don't have
>shadows under them? With the poor quality of a CGA adapter, such things
are
>hard to read anyway.
>
I am talking about people with older machines laying around. And most
servers do not need to run X. All it does on these machine is suck up
resources.
>>Ummm, I do not need to run programs from anywhere. Neither do most
people.
>
>But most people have CGA adapters in their Pentiums, right? And most people
>demand pretty text-based applications?
>
Actually they do since all SVGA/VGA/EGA adapters are backwardly compatable
to CGA
>>>>And then people wonder why DOS beat
>>>>out UNIX.
>>>
>>>Nobody who is aware of the price of each at the time DOS was a reasonable
>>>choice wonders this.
>>>
>>
>>I am thinking of the battle in the business world between UNIX servers
with
>>dumb terminals verses DOS based machines. Just compare Wordperfect's and
>>Lotus' UNIX and DOS versions. The DOS versions are much more user
friendly.
>
>I wouldn't use ``user friendly'' in the same sentence as ``Word
Perfect''---
>at least when talking about version 5 or prior. Blank screen, lame function
>keys. The UNIX versions of text-based WP are/were about as unfriendly as
the
>DOS versions. I've actually seen/used them.
>
>>Yes but the console has no need of XON/XOFF along with other serial
specific
>>attributes which currently exist. And there is still the limitation in
>>detecting Alt & shift key presses and key combinations.
>
>It's called object oriented design. Because a Console ``is a kind of'' tty
>device, it inherits the properties from that base class, including
XOn/Xoff,
>variable baud rate, etc. The console surely doesn't need a baud rate,
>but it has one by way of ``inheritance''. Thus programs which don't care
>which particular derived ``kind of'' tty they are talking to can depend
>on that baud rate to be there, and for methods related to the baud rate
>to do something sensible.
>
An object oriented design does not need to limit functionality, in fact it
is suppose to improve functionality.
>Xon/Xoff _is_ useful in a console, however, believe it or not. You can use
>Ctrl-S to pause output. Why do you suppose it works in DOS? Even the Apple
II
>supported Ctrl-S as a way of pausing output even though its console wasn't
a
>serial tty that could be flooded.
Yes but under DOS that pausing would only happen in the command.com prompt.
John Smith
Don't need direct access if the low level function are provided.
Jarkko L T Lehto wrote in message <6de1pj$jdp$1...@oravannahka.Helsinki.FI>...
>In article <6d9q3e$q...@camel20.mindspring.com>,
> "John Smith" <sm...@nowhere.com> writes:
>
>Have you used GGI already? Try it before you go to that direct access
>grab!
Kaz Kylheku
Kaz Kylheku
In article <6dfce8$3...@bgtnsc02.worldnet.att.net>,
samuel igwe <SAM...@worldnet.att.net> wrote:
>John
>
>I am glad someone like you seems to see the big picture. Let the rest of
>them suffer under Xwindows. Blast them all.
>
>The console will ALWAYS have its advantages over X.
Yeah, but will stupid programming in the console environment always
have its advantages over reasonable programming?
I'm a heavy console user; I don't want the console landscape polluted
by crappy software.
Not that I expect that it will; it's too self-defeating to make it.
>I am one of a majority of linux/freebsd users running our systems on a
>personal home machine.
>
>We have no need nor desire for remote logins, nor programs that work in
>X and xterms.
I guess you don't have a local area network then, and you will *never* need to
dial back home via modem while you are travelling.
Bill Currie
John Smith wrote:
> First of all GL Quake will benifit from accelerated functions on most video
> boards. Second of all it is a 32bit program and not hampered by 16bit x86
> segmented memory.
DOS Quake is also a 32 bit program and not hampered by 16bit x86
semented memory (except during file save/load, but so what).
--
Leave others their otherness
Bill Currie
John Smith wrote:
> unfortuately ncurses looks and feels primative and this significantly limits
> one's programs.
Even though I've written my own direct to the hardware text library for
Linux, ncurses still has one advantage over my library.
Internationalization. I *WANT* those box characters (176-223) (mind you,
I don't use them ALL) AND 16 forground colors, so goodbye unix codepages
:(.
Other than `dont do it', does anybody have any suggestions for how to
cope with this problem? Pitty you can't have both 512 char fonts and 16
forground colors (or did I miss something in the VGA specs?).
Bill
John Smith
Peter Seebach wrote in message ...
>In article <6d9q3e$q...@camel20.mindspring.com>,
>John Smith <sm...@nowhere.com> wrote:
>>MS-DOS still has much better looking and functioning programs so Linux, in
>>this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
>>while much better also isn't good enougth. Why are we, with todays modern
>>operating systems, being forced to program our text programs for the
lowest
>>common denominator the "DUMB TERMINAL".
>
>Because it's still one of the most common interfaces. I'm typing on a
>console, right? Well, sort of - it's actually an emulated console, and
>a lot of the programs I'm running are actually running about 850 miles
>from me. So, while it sounds cool at first, it *sucks* to have everything
>need access to the hardware.
>
>A good ncurses-based interface can do everything this console supports -
>and can do it remotely, too.
>
>I spend more time in emulated windows than on "real" consoles. I may
>not be typical, but, for this market, I probably am.
>
>>And then people wonder why DOS beat
>>out UNIX.
>
>No, they don't. It's because Bob in Accounting got something from the
>company that made the typewriter he was replacing in 1980.
>
>>As a programmer and a user I can state with
>>certainty that Linux needs to allow access to low level console functions
>>including display, mouse, & keyboard.
>
>It's called X. If you want a display driver, you know where to find it.
>
X doesn't have text mode
Roy Stogner
On Mon, 02 Mar 1998 17:28:12 -0500, samuel igwe wrote:
>This is no attempt to convert anyone. If you want to live in the world
>of black and white tty screens, terminal input restricted libraries and
>programs requiring massive processor speed and storage just to maintain
>portability among unix like systems -- let it be your choice.
You have apparantly ignored everything that everyone has said to you.
Are you deliberately lying (in case you hadn't noticed, everything you
have said above is WRONG), are you illiterate, or are you just stupid?
I am writing this in a terminal program with full color support, both
background and foreground. I can also run the exact same program in a
black and white tty screen if I need to (i.e. Windows telnet) but I
have both choices. This nonsense that a black and white screen is
required is a figment of your deluded imagination.
Those "restricted libraries" are giving me that full color program
from a QVT/Term session in the next state. Your programs won't even
be runnable in X Windows! All your bragging about how people want "a
nice looking interface" is made all the more pathetically laughable by
the fact that people who use a nice looking interface will be unable
to use your programs.
By the way, speaking of restrictions, will I be able to do ANYTHING
else while using your editor? Will Ctrl-Z suspend it so that I can
read another file or run a command at the shell, will switching
virtual consoles allow me to do other things while I edit, or will
both of these just leave the video card and keyboard in an unusable
state?
Massive processor speed? Are you nuts? I'm on a Pentium at the
moment, but was running these same programs from a 486SX25 with no
problems whatsoever. As for "massive storage," that statement only
proves your total incapablity of use of the "ls" function.
By the way, "portably among Unix like systems" is the only reason
Linux exists at all, so let's show it a little respect, OK? Let's
also consider that that portability extends to portability among LINUX
systems as well. Will my MkLinux-running friend be able to use your
editor? Will I after I get an Alpha?
Wow. It's been years since I've been this impolite on a newsgroup,
but I simply find myself astonished. Seeing someone whose brain had
been so frozen by DOS that they were willing to throw away a dozen
features of Linux was cute; seeing facts bounce off that person from
a thousand different sources with no measurable effect is just
unbelievable.
---
Roy Stogner
Klau7s.S...@home.ivm.de
>
> Re: disabling the linux console/display driver and manipulating cursor.
>
> From: dit...@sonne.tachemie.uni-leipzig.de (Jens Dittmar)
> Reply to: Jens Dittmar
> Date: 02 Mar 1998 17:48:11 +0100
> Organization: Damage Inc.
> Newsgroups:
> comp.unix.programmer,
> comp.os.linux.development.apps
> Followup to: newsgroup(s)
> References:
> <6cld8p$p...@bgtnsc02.worldnet.att.net><6coj24$pl2$1...@brie.direct.
> ca>
> <6d9q3e$q...@camel20.mindspring.com>
> <m21zwn5...@dittmar.pci.uni-leipzig.de>
> <6ddmj5$s...@camel19.mindspring.com>
>
>>>>>> John Smith writes:
>> This take over of DOS machines over UNIX terminal was largely due to more
>> user friendly programs under DOS.
>
> I think it was due to the price. I really cannot see any point where DOS
>is superior to any Unix, not even considering applications.
>
>
sc, slsc, oleo, emacs-dismal which are all free software.
> I haven't even seen 123 for DOS. :) If there would be no Linux I would
>have chosen *BSD, if there were no BSD too I had spent some money. DOS was
>never an option because it is nothing more than a bootloader for games -
>useless for daily work.
And to create bootdisks for Linux or FreeBSD and reading howtos on the install
cdroms before upgrading one's box to the free unix clones.
>
>> And I figure that most Linux users with personal Linux systems do not use
>> remote sessions very often so many of them would happily use a program
>> that can only run on the console (for example, svga software).
>
> Regarding the fact that most 'Linux users with personal Linux systems'
>prefer X they probably would avoid console-only programs.
>
I don't use or like X at all. Console-only programs are no problem for me,
There is a C++-library called Venus which can be used to create programs
with direct console access character graphics (turbovision-lookalike).
But the problem is that one has to allow the user to write-access a device
file, which is a large security risk and disabled by default. So about all
my programs use either libncurses, the best thing since sliced bread,
or libtermcap combined with termios, which is sometimes faster and more
porable.
Btw. Ncurses-4.2 is now available from alpha.gnu.org (warning: it is beta
software, not much tested yet, so only install if you know exactly what to do.
Klaus Schilling
Will Rose
Roy Stogner (royst...@SPAMiname.com) wrote:
[...]
: Wow. It's been years since I've been this impolite on a newsgroup,
: but I simply find myself astonished. Seeing someone whose brain had
: been so frozen by DOS that they were willing to throw away a dozen
: features of Linux was cute; seeing facts bounce off that person from
: a thousand different sources with no measurable effect is just
: unbelievable.
Er, no. Not since September 93, anyway. This is Usenet, remember?
William McBrine
In comp.os.linux.development.apps samuel igwe <SAM...@worldnet.att.net>
wrote:
: There should be better console programs. especially for the Pc and x86
: architecture.
There are better console programs; you just haven't seen them.
: To view pictures I have to switch to X.
There are plenty of SVGALib-based picture viewers. Check out:
ftp://sunsite.unc.edu/pub/Linux/apps/graphics/viewers/svga
or http://...
I prefer SVGALib viewers myself, because on my particular system (Cirrus
5422 video), I get better support under SVGALib than X.
--
William McBrine | http://www.clark.net/~wmcbrine/
wmcb...@clark.net | Unsolicited commercial emailers will be annihilated
KNakasato
>
>
>Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
>>In article <6cld8p$p...@bgtnsc02.worldnet.att.net>,
>> <SAM...@worldnet.att.net> wrote:
>>>How can I disable the linux console/display driver so that my programs
>>>truly have control of the display.?????
>>
>>Don't do this. Linux users will hate your program.
>
>
>I wouldn't, I fact I would like direct access to console text functions as
>well.
I think he is just making a sarcastic remark. Basically, he is probably
saying that will disable other tasks that are multitasked.
>>>Manipulation of the port addresses where the cursor resides yields
>>>unproductive results. Could this be attributed to the linux display driver
>>>running in the background?
>>
>>You are still thinking within an MS-DOS mentality. Use a library such as
>>ncurses.
>
>MS-DOS still has much better looking and functioning programs so Linux, in
>this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
>while much better also isn't good enougth. Why are we, with todays modern
>operating systems, being forced to program our text programs for the lowest
>common denominator the "DUMB TERMINAL". And then people wonder why DOS >beat
out UNIX.
True, but then I think that NT is functionally unix with Windows shell.
I am sure that there are some nice graphics shell such as X.
>As a programmer and a user I can state with
>certainty that Linux needs to allow access to low level console functions
>including display, mouse, & keyboard.
I think it is preferable with high level standarized named functions.
Call it standard extensions, and allow implementation to optionally decide.
At least same names could be used in similar environment.
Unfortunately, it is too late and MS rules and monopolizing with MFC
and VB. :-(
I am pretty sure that this is dealt better in linux newsgroup.
Aloha
R!ch
On Mon, 2 Mar 1998, John Smith wrote:
> I have many DOS programs which are mostly portable. Except for a relatively
> few low level video functions which are not currently provided under Linux.
"Mostly portable" - now there's an oxymoron!
So, can I take these "mostly portable" programs that bash directly
on the hardware, to my SPARC box and run them there? Even if I have
the source?
Didn't think so.
I'm beginning to think this whole thread is a troll - either that,
or the product of a mind that doesn't have much CS training.
Chris Waters
"John Smith" <sm...@nowhere.com> writes:
> What about the users who do not like X or cannot run it?
Maybe you can get them to help you with your project. Both of them. :-)
--
Chris Waters xt...@dsp.net | I have a truly elegant proof of the
or cwa...@systems.DHL.COM | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Klaus.S...@home.ivm.de
>
> Re: disabling the linux console/display driver and manipulating cursor.
>
>
>> What about the users who do not like X or cannot run it?
>
>Maybe you can get them to help you with your project. Both of them. :-)
I don't like GUIs, so I don't like X. But I don't like either to have user
apps that require users to have write access to a /dev, in this caes /dev/vcs*,
as is necessary for Venus (the already mentioned turbovision clone), as nice as
it looks. It's against the principles of Unix-types programming to do that.
Klaus Schilling
Jan de Visser
R!ch wrote:
[ snip ]
>
> I'm beginning to think this whole thread is a troll - either that,
> or the product of a mind that doesn't have much CS training.
>
> --
> R!ch (Email is flakey at present: use rich...@keaton.uk.sun.com)
>
So do I. The funny thing is that this John Smith type posts from the
same "mindspring" domain as Ken Payne, who just fought a nice flame war
on Unix and NT development tools over in comp.unix.mis (he was on the NT
side, of course. (or better, he *was* the NT side)).
Hrrm...
JdV!!
========================================================================
Jan de Visser etm...@aom.ericsson.se
Mö/ETX/A/B NMAC Team SAC
tel. +46 31 74 71890 ECN 865 71890
Vette pech voor de kabouters!
========================================================================
Albert D. Cahalan
Klaus.S...@home.ivm.de writes:
> I don't like GUIs, so I don't like X. But I don't like either to
> have user apps that require users to have write access to a /dev,
What do you call /dev/tty* devices? No /dev/audio either?
What about /dev/null, /dev/full, and /dev/zero?
> in this caes /dev/vcs*, as is necessary for Venus (the already
> mentioned turbovision clone), as nice as it looks. It's against
> the principles of Unix-types programming to do that.
Hell no. It is against the principles of Unix-types programming
(and SMP programming!) to disable interrupts from user software.
The X server does exactly that, without even being locked into RAM.
Christopher Browne
On Mon, 02 Mar 1998 23:12:01 GMT, Peter Seebach <se...@plethora.net> wrote:
>>Speed and size are the main benefits.
>
>I'll make you a deal. You write code that uses direct access to a
>video chipset. I'll write code that uses calls to a generic API.
>
>
The one that uses direct access may be faster this year, if written to
get every ounce of performance out of that cool graphics card.
Unfortunately, it will need to be rewritten next year when a new
graphics card comes out. And that may understate the rapidity of
change. New graphics cards are released with greater rapidity than
that.
Meanwhile, the one that used a generic API such as X gets a speedup
factor of two any time someone tunes up the driver code for their
graphic card. And another speedup factor of 8 when I move from last
year's sucky graphics card to next year's fast one. And another speedup
factor of 4 when I get an Alpha 300 to replace the Cyrix 150+. And
another speedup when someone adds some generic accelerator code to X
that applies to *all* the graphics cards.
Those increases start multiplying up pretty quickly. Five years ago, X
performance on PCs using cheap Cirrus video boards on VLB with 486es and
8MB of RAM certainly did "suck." That's not true anymore now that PCI,
S3V, P200, and 32MB of RAM are becoming pretty typical. Each of those
things improve the performance of X by a fairly significant factor.
>>I am a devoted console user who
>>detests the overhead of Xwindows. Ultimately, many will argue that in
>>this age of Pentium II systems there is little or no loss in speed with
>>graphics only apps. I have a 486 dx4 and have no desire to upgrade any
>>time soon.
>
>Then you, of all people, should appreciate the importance of flexible
>code that doesn't assume so much about what it's running on.
The ability of an aged 486 system to take advantage of the hardware
improvements of the last five years is pretty limited. I could argue
that pre-PCI hardware was ill able to afford the overhead of supporting
*any* kind of graphical infrastructure, whether X or otherwise.
It is quite likely that the 486 DX4 can't economically be upgraded to
support recent X improvements.
>>I have already begun writing the clone of DOS edit.exe for which this
>>library was written. The editor is one of many console applications I
>>have in mind. It is geared towards those of us wishing to run an
>>equivalent to the Dos editor (ver 6.0+) in the linux console.
>Why would you bother? It's a sucky, ugly, editor.
It doesn't even support multiple windows.
Someone wanting a highly-tuned editor should take a look at VDE. It is
an example of a very well constructed editor that was written in tuned
x86 machine language. Interestingly, it gives the user the option of
either doing direct hardware access, or eschewing that in favor of
portability. You can go with direct access if you don't mind it maybe
not working.
On a Pentium system of *any* description, VDE can do virtually any
processing faster than the user can *possibly* make choices. It's
incredibly fast, but it doesn't matter, because even on some spectacular
"speed" drug, you couldn't possibly overpower it.
>>I will not allow anyone to restrict me.
>
>Portability isn't a restriction, it's a freedom.
It provides a different sort of freedom. You're not free to directly
trash the boot sector on the PC; you're not free to dump garbage on the
screen anywhere you want to; you have to go "through channels" to get
those sorts of jobs done.
But by giving up that particular freedom, you gain other freedoms:
- The freedom to not worry about where, precisely in memory the program
resides. (People that used to do CP/M will remember this issue.)
- The freedom to not worry about other programs trashing this one.
(Has anybody watched a MS Windows box crash lately?)
- The freedom to ask the OS to put data in named files for you rather
than having to figure out what block your program is in. (Anybody
remember FORTH?)
- The freedom to run the program on this computer, and on several
generations of later computers, with nothing more than a recompile. If
the program is written in an interpreted language, recompiling won't
even be necessary. I've got programs I wrote ten years ago for
computers that are desparately obsolete today. Those programs still run
today, albeit hundreds of times faster...
>>if you have a problem with that DOS like mentality -- "get stuffed"!!
>
>Happily; I'll go take my marketable skills, earn a living, and buy more
>pizza.
>
>Fundementally, non-portable code will lose in speed for the remainder
>of the forseeable future, and probably far beyond. Portable code has
>all the hard things done for it, correctly. Your direct access methods
>may not survive SMP; my code will. Your code can't use a new graphics
>accelerator; mine can. Your code can't take full advantage of a sound
>card with a DSP. Mine can. If you finally get yours running on one DSP,
>it won't work on the next one that's twice as fast. Mine will.
>
>You lose on speed, you lose on featuress, you lose on choices. You lose.
This is principle #4 of the UNIX Philosophy: "Choose portability over
efficiency."
If the software works *adequately* today, then it will work even better
next year on the newer, faster, cheaper stuff that comes out then.
Adding optimizations that make it harder to move to next year's faster,
cheaper hardware is only worthwhile if you are willing to rewrite the
code next year.
--
We use Linux for all our mission-critical applications. Having the
source code means that we are not held hostage by anyone's support
department. (Russell Nelson, President of Crynwr Software)
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Kaz Kylheku
In article <6dfsm8$l...@camel21.mindspring.com>,
BIOS is not DOS. You are even more clueless than you initially appeared.
>directly accessing the color video display at segment C000
I repeat, which feature of DOS will display text and then scroll the
background underneath it? A. D. Cahalan says above that ``[it] is insane, but
DOS can do it''.
fl...@interport.net
John Smith (sm...@nowhere.com) wrote:
: Jarkko L T Lehto wrote in message <6de28r$jdp$3...@oravannahka.Helsinki.FI>...
: >
: >FYI, there is no such thing as "standard text selection" that's just ms
: >crab!
: Irrelevant, its the standard now no matter by who.
Really . . . would you be so kind as to furnish me with a pointer to
documentation of this standard? After all, the nice thing about
standards is that anyone can code to them, that's why they're
externalized in documents.
If you still don't understand the difference between commonplaces and
standards, read up on NFS and compare it to the "standard" of which
you speak -- NFS is a good example because it came from a vendor, but
was still public. And then compare that to Java, which is not a
standard.
--
Ben
"You have your mind on computers, it seems."
Peter Seebach
In article <6dfuat$m...@camel21.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>Another powerful argument. DOS seams to have done in the decade in which it
>dominated and, horrors, it allowed direct access.
It allowed direct access, and it created a vast market for "dos extenders"
and "tsr's" and all sorts of other programs, any two of which were fairly
likely to have horrible and irreconcilable conflicts.
Wonderful.
In the mean time, people using "academic" systems got work done.
Does that mainframe that your bank uses to do all the real work allow
direct access? No, and it didn't in the 80's either.
>First of all GL Quake will benifit from accelerated functions on most video
>boards. Second of all it is a 32bit program and not hampered by 16bit x86
>segmented memory.
Right. In other words, it benefits from the *lack* of direct access.
If you write using direct access, you have to know *exactly* what you
are accessing. If you omit the childish obsession with something that
was faster in the 60's, on some systems, you find that you get much
better performance from a much broader range of hardware.
>Sure I could write that way, so could he, but not many users would
>appreciate programs which only input/output 1 line at a time. But at least
>it will run anywhere.
While many users may not "appreciate" those programs, they're often the
difference between getting a job done and not getting it done.
I'm hardly arguing that all code should use <stdio.h> functions for all
purposes. However, the call for "direct access" is stupid.
The time for that has come and gone.
>>There are many aspects of hardware devices that you can't access, and my
>>portable code can.
>You seam to have that backwards. After all portable code eventually calls
>or is converted to code specific to a particular system. And the inherit
>trade off for protable code is usually a loss of functionality or of what is
>possible.
You don't understand, do you.
If you write code which uses direct access, you are directly accessing *one*
device. You have to recode to use another. Or, you can make your code
run on a few devices, and it'll have to use the least common denominator.
When I don't depend on direct access, I can use a large array of functions.
Some of them will not be "accelerated" on some hardware, but they'll be, at
worst, within a few percent of what you'd get by just writing to the video
buffer yourself *on that hardware*. On other hardware, my code will be *much*
faster than you could get by writing to a video buffer.
Without direct access, you choose the features you want, and you can run
on anything that can provide them. Quickly.
>Didn't he just mention he did not want to use X. And by the way all X
>servers that I have seen are inheritly non-protable and must call many low
>level functions.
You aren't seeing the forest for the trees. The tree in my lawn is not
in South America; this doesn't meen there are no trees in South America.
The X server I run on my laptop is, admittedly, not going to run on a SPARC -
but any program that runs on one is likely to run on the other.
Yes, I saw the twit mention he didn't want to use X. Well, if he wants to
suffer in a world of low-performance video, writing every pixel by hand, he's
welcome to. If he actually wanted *speed*, he'd use an API that would gain
full benefit from a variety of accelerated hardware.
Hey, technocrate! Remember that "massively accelerated graphics for Matrox
Mystique" program you were gonna do? Is it still the fastest thing you could
run on a PC? Didn't think so.
>That sucky editor made DOS 5.0 a success.
Not particularly. It sucks less than the older one, but it's hardly worth
it.
>People upgraded just for the
>editor. And it is definately more usable and user friendly than vi or emacs
>despite having less functions.
Define "more usable". I can't get my work done in an editor that doesn't
have powerful search and replace.
Easier to use for five minutes, yes. Easier to use for a year, no.
Learning curves tend to correlate negatively with long-term efficiency.
If you could make full use of it in five minutes, you'll never get much
more out of it. If you spent a week learning it, a while later, you'll
be doing things with it that you could never have done with the "easy"
model.
I hate to break it to you, but those of us who have a long-term memory,
at all, often *use* something for much longer than we *learn* it. I
suppose "investment" is foreign to you, too.
>Portability is restrictive by its very nature. It is the trade off for
>portability's benefits.
How is it restrictive? Let's compare: You write up the complete list of
things you can do in non-portable code that I can't do in portable code.
I'll write up the list of things I can do in portable code that you can't
do in non-portable code.
Hint: API's make portable code *very* powerful. Can you write non-portable
code which do texture mapping on every PCI graphics card that has hardware
texture mapping? I can write portable code that does that.
>Most PC hardware have some compatability level amoung different vendors.
>For example, text modes through VGA for video cards.
You're right, and if I wanted to play video games in slow 320x200 resolution,
that would be the end of it.
Can you find a PC that can run Quake in 16-bit color, 800x600, without
slowing down? How about one that can run GLQuake at the same resolution?
Oh, look! The portable one has *more features* - better lighting,
transparency, and things that, strangely, the *non-portable* one can't
do.
>I am not sure how marketable you are if you limit your coding practices in
>such a way to only produce very portable code. Portability is nice but
>sometimes you need to access non portable low level functions.
You're right - but more often than not, there's a *portable API* that
handles it for me.
In any event, most of the code I do is the portable part. I do a lot of
coding to API's, and as such, I can write a program that will do, say,
text editing, on *any* POSIX-like system; this gets me portability to
a dozen Unixes, VMS, and Windows NT. If I want to use X, I can support
displays on Amigas and Macintoshes, PC's running any kind of Windows,
the NeXT, any recent Unix system... Pretty good.
>>You lose on speed, you lose on featuress, you lose on choices. You lose.
>Low level access need not limit choice.
By definition it does; as soon as you are accessing *something* directly,
you need to know what it is, and you've lost the choice to access something
different.
X code can run on any CPU; care to explain how you'd like to write directly
to video memory on a real CPU, if you wanted something faster than a toy Intel
box? You'd write different code...
But see, it's been done already, and it's been done by people a hell of a lot
smarter than you or I. If you want to spend the rest of your life shaving
bits of stone off of square things hoping to make them round, go ahead. I'll
buy tires and roll.
Jens Dittmar
>>>>> samuel igwe writes:
> The console will ALWAYS have its advantages over X.
Of course - I use it too.
> I personally care notting for portability across differing hardware
> architectures. If theres a problem the user should write an emulator.
So what about the software I use which was developed say on an SGI box?
Should I run it on a MIPS interpreter with IRIX binary API emulation? It is
just this cross platform portability which made Linux a success.
> Just to maintain portability??? -- I wonder how X communicates with my
> SVGA pci card. If not direct access then how? --
This makes it portable. Ever heard the term 'driver'?
Jens
Leslie Mikesell
In article <6dfsbn$b...@camel21.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>
>I find it astonishing that you cannot see any DOS attribute which is
>superior to a comparable UNIX attribute. It seams to me that you are
>extremely biased in your opinion.
Or just experienced... The beauty of unix text applications is that
they generally can take their input from a file or pipe as well as
being run from any kind of terminal. Thus when you realize that you
repeatedly do the same 10 operations changing only a couple of things
you can write a shell script that prompts for the variable items
then performs all the steps, without having to learn a macro language
for each separate program. But, if you like DOS and programs that
run with pretty background colors there is always DOSEMU.
>What about the users who do not like X or cannot run it?
Do you not like X in general or do you not like the way your particular
hardware performs/looks when running X? I don't like X on monitors
that don't look sharp at 1024x768 and you need a decent accelerated
card. But that's pretty ordinary stuff these days.
>For improved functionality as I have stated before.
Is that worth giving up compability with pipes? Is it worth designing
a new protocol for obsolete equipment? Why not just use the DOS
programs you like under DOSEMU?
Les Mikesell
l...@mcs.com
Dave Pearson
On Mon, 02 Mar 1998 17:28:12 -0500, samuel igwe <SAM...@worldnet.att.net> wrote:
> This is no attempt to convert anyone. If you want to live in the world
> of black and white tty screens,
Huh? The three programs I spend most of my Linux time in (not counting
emacs) are mutt, slrn and Midnight Commander. All three are in glorious
colour.
--
Take a look in Hagbard's World: | w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ | ng2html - The NG to HTML converter.
http://www.hagbard.demon.co.uk/ | eg - Norton Guide reader for Linux.
Free software, including........| dgscan - DGROUP scanner for Clipper.
kpayne*sp...@mindspring.com
"John Smith" <sm...@nowhere.com> penned:
>
>Peter Seebach wrote in message ...
>>In article <6d9q3e$q...@camel20.mindspring.com>,
>>John Smith <sm...@nowhere.com> wrote:
>>>MS-DOS still has much better looking and functioning programs so Linux, in
>>>this respect, could use a little DOS mentality. And ncurses SUCKS. SLang
>>>while much better also isn't good enougth. Why are we, with todays modern
>>>operating systems, being forced to program our text programs for the
>lowest
>>>common denominator the "DUMB TERMINAL".
>>
>>Because it's still one of the most common interfaces. I'm typing on a
>>console, right? Well, sort of - it's actually an emulated console, and
>>a lot of the programs I'm running are actually running about 850 miles
>>from me. So, while it sounds cool at first, it *sucks* to have everything
>>need access to the hardware.
>>
>>A good ncurses-based interface can do everything this console supports -
>>and can do it remotely, too.
>>
>>I spend more time in emulated windows than on "real" consoles. I may
>>not be typical, but, for this market, I probably am.
>>
>>>And then people wonder why DOS beat
>>>out UNIX.
>>
>>No, they don't. It's because Bob in Accounting got something from the
>>company that made the typewriter he was replacing in 1980.
>>
>>>As a programmer and a user I can state with
>>>certainty that Linux needs to allow access to low level console functions
>>>including display, mouse, & keyboard.
>>
>>It's called X. If you want a display driver, you know where to find it.
>>
>
>X doesn't have text mode
>
Depends on how you see things. Multible text "consoles" reside in
X just fine.
Albert D. Cahalan
se...@plethora.net (Peter Seebach) writes:
> Define "more usable". I can't get my work done in an editor
> that doesn't have powerful search and replace.
>
> Easier to use for five minutes, yes. Easier to use for a year, no.
>
> Learning curves tend to correlate negatively with long-term efficiency.
> If you could make full use of it in five minutes, you'll never get much
> more out of it. If you spent a week learning it, a while later, you'll
> be doing things with it that you could never have done with the "easy"
> model.
That is a huge pile of arrogant BS. XEmacs is clearly one of the
most powerful editors, yet it is easy to learn the basics.
Compare to vi, which is hard to learn and doesn't have half the
features of XEmacs.
> Hint: API's make portable code *very* powerful. Can you write
> non-portable code which do texture mapping on every PCI graphics
> card that has hardware texture mapping? I can write portable
> code that does that.
No you can't, unless you are using Windows 95 or ignoring the
hardware texture mapping.
> Can you find a PC that can run Quake in 16-bit color, 800x600,
> without slowing down? How about one that can run GLQuake at
> the same resolution? Oh, look! The portable one has
> *more features* - better lighting, transparency, and things
> that, strangely, the *non-portable* one can't do.
You have a backwards definition of portable. Standard Quake runs
everywhere and uses standard PC video hardware. GLQuake only runs
on a few specific video cards because GLQuake is _not_ portable.
GLQuake may work better -- which only shows how good unportable
code can be. (OpenGL? What OpenGL? GLQuake comes with it's own
damn video drivers for that because OpenGL is _not_ much of a
standard yet)
Peter Seebach
In article <vc7btvn...@saturn.cs.uml.edu>,
>most powerful editors, yet it is easy to learn the basics.
Yes, but the advanced features are pretty hard to get at. :)
>Compare to vi, which is hard to learn and doesn't have half the
>features of XEmacs.
I wouldn't call vi 'hard to learn'. And, while it has a lot fewer
features, it has about as many *editing* features - it's just not
a complete programming environment. When I want hooks in another
language, I use a vi that has them.
>> Hint: API's make portable code *very* powerful. Can you write
>> non-portable code which do texture mapping on every PCI graphics
>> card that has hardware texture mapping? I can write portable
>> code that does that.
>No you can't, unless you are using Windows 95 or ignoring the
>hardware texture mapping.
Assume I use Windows '95's API to drive the texture mapping.
Now, *one* program is doing hardware texture mapping on *many*
video cards.
You can't do that with direct access.
>You have a backwards definition of portable. Standard Quake runs
>everywhere and uses standard PC video hardware.
Except that it obviously doesn't use "standard PC video hardware"
on the Mac.
>GLQuake only runs
>on a few specific video cards because GLQuake is _not_ portable.
GLQuake runs on machines that don't even have an 80x86.
GL is an example of an API which allows you to write programs which get
good performance even out of hardware that didn't *exist* when you wrote
your code.
Direct access can't do that.
>GLQuake may work better -- which only shows how good unportable
>code can be. (OpenGL? What OpenGL? GLQuake comes with it's own
>damn video drivers for that because OpenGL is _not_ much of a
>standard yet)
OpenGL is a wonderful standard; it's not anyone's fault but M$ that
they aren't supporting it.
However, the same GL code runs on a variety of machines - more portable
than *any* direct access.
Matthias Buelow
In article <6ddmj5$s...@camel19.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>can only run on the console (for example, svga software). Eventually I can
>envision a special Linux telnet which will allow remote "console" sessions
>providing mouse, keyboard, and graphics control functions to programs
X Window System version 11, release 6, is probably what you mean.
And it doesn't run only on lignux, of course.
--
Matthias K. Buelow * Boycott Micro$oft, see http://www.vcnet.com/bms/ *
Matthias Buelow
In article <6dfuat$m...@camel21.mindspring.com>,
John Smith <sm...@nowhere.com> wrote:
>First of all GL Quake will benifit from accelerated functions on most video
>boards. Second of all it is a 32bit program and not hampered by 16bit x86
>segmented memory.
The world you live in, Sir, seems to be at least 10-15 years in the past.
Even more, it's restricted to one microcomputer type of architecture.
Please remove comp.unix.programmer from your posts, since your postings
have no relevance to this newsgroup at all.
Matthias Buelow
In article <6dgvnb$gng$2...@blue.hex.net>,
Christopher Browne <cbbr...@hex.net> wrote:
>Someone wanting a highly-tuned editor should take a look at VDE. It is
>an example of a very well constructed editor that was written in tuned
>x86 machine language. Interestingly, it gives the user the option of
Last time I used that editor (around 1991 or so) it could only edit files
up to 64K (yes, that's _kilobytes_), with some proprietary "compression"
techniques, up to 90K. That could probably be enough for a mail editor,
but not for serious work today.
Jarkko L T Lehto
In article <vc7btvn...@saturn.cs.uml.edu>,
acah...@saturn.cs.uml.edu (Albert D. Cahalan) writes:
> That is a huge pile of arrogant BS. XEmacs is clearly one of the
> most powerful editors, yet it is easy to learn the basics.
> features of XEmacs.
doesn't have half the features of XEmacs? I don't think so.
BTW. I use VIM 5.0 and it's just great! Sure it's hard to learn but when
you learn it it's quite powerful..
>> Hint: API's make portable code *very* powerful. Can you write
>> non-portable code which do texture mapping on every PCI graphics
>> card that has hardware texture mapping? I can write portable
>> code that does that.
> No you can't, unless you are using Windows 95 or ignoring the
> hardware texture mapping.
This is a troll, I guess?
> You have a backwards definition of portable. Standard Quake runs
> everywhere and uses standard PC video hardware. GLQuake only runs
> on a few specific video cards because GLQuake is _not_ portable.
> GLQuake may work better -- which only shows how good unportable
> code can be. (OpenGL? What OpenGL? GLQuake comes with it's own
> damn video drivers for that because OpenGL is _not_ much of a
> standard yet)
OpenGL is very much a standard, you and all MS people just tend to think
otherwise.
BTW, anyone know if GLQuake/Linux runs without a 3d accelerator? Of course
slowly, but would it run at all??
Karl Stenerud
John Smith <sm...@nowhere.com> wrote in article
<6d9q3e$q...@camel20.mindspring.com>...
> compared to DOS equivalents. As a programmer and a user I can state with
> certainty that Linux needs to allow access to low level console functions
> including display, mouse, & keyboard.
Take a look at the linux GGI project. It is being designed as a
replacement to SVGAlib.
As a test, they've already made a GGI Doom and GGI UAE.
They're even working on a GGI X diver.
I don't have the URL on me, but if you go to the UAE page there's a link
from there.
(UAE = Ubiquitous Amiga Emulator)
Now we should get back to C topics =)
Karl Stenerud
> >> detect the following:
> >>
> >> <Shift down><PageDown><DownArrow><Shift up> Standard text
> selection.
> >
> >FYI, there is no such thing as "standard text selection" that's just ms
> >crab!
>
> Irrelevant, its the standard now no matter by who.
Yes, but somebody, somewhere, had to implement the code for it to respond
like that.
Now if you want a different OS do do it, you have to re-implement the code.
What's so bad about that?
While we're at it, why don't you put proper piping in DOS?
Or how about ^Z to put your job in the background?
Sorry, it's not automatically "detected" by DOS so I guess there's nothing
you can do.
Kaz Kylheku
>
>> Define "more usable". I can't get my work done in an editor
>> that doesn't have powerful search and replace.
>>
>> Easier to use for five minutes, yes. Easier to use for a year, no.
>>
>> Learning curves tend to correlate negatively with long-term efficiency.
>> If you could make full use of it in five minutes, you'll never get much
>> more out of it. If you spent a week learning it, a while later, you'll
>> be doing things with it that you could never have done with the "easy"
>> model.
>
>most powerful editors, yet it is easy to learn the basics.
However, if you only ever use the basics, you won't achieve long-term
efficiency. The default editing features of Emacs are utterly useless
for efficient text mangling. That's why emacs users can choose to use
a package which provides, for instance, vi emulation.
Implementation is the sincerest form of flattery!
Each different ``mode'' in emacs can behave as a completely different piece of
software with a whole new learning curve. Learning ``viper-mode'' for instance
probably requires exactly the same effort as learning vi. You may be an Emacs
wizard, yet be completely stumped when you go into this mode. Either you have
to admit that the mode is a separate tool rather than a feature of Emacs, or
you have to admit that you haven't mastered Emacs.
>Compare to vi, which is hard to learn and doesn't have half the
>features of XEmacs.
But learning basic text editing with vi leads to better ``long-term
efficiency'' than *basic* text editing with emacs. I also don't believe that
it's harder to learn vi. When I switched from emacs to vi, I just loved it.
Within a week, I abandoned emacs completely. I not only liked the commands,
but also the ``instantaneous'' response; with emacs, I was used to very
poor response on a loaded system, and meditation periods during which
the editor would perform garbage collection.
However, if someone takes the time to go beyond the basics with emacs, it
becomes a powerful tool---which tends to uphold the general hypothis that
there is a negative correlation between learning curve and long-term
efficiency; it's not arrogant BS.
The features of XEmacs are actually software tools that are added on to it.
Comparing that to vi is unfair, because vi (or vi clone) users also use
separate software tools---they are just not integrated into the editor.
Emacs isn't for everyone. I prefer to use stand-alone programming tools rather
than having everything done up in the interpreted language of a single
software package. Plus when I was in school, I managed to bypass all the
introductory Lisp courses because I thought they were ``sissy'' due to not
using a proper systems programming language. I went to a college which used
Modula 2 for the low-level courses and then transferred the credit back to
University and went straight into upper-level C hacking. :) The lack of a Lisp
background is a big setback for a would-be emacs user, because you have to
rely on others to develop the tools you want.
Karl Stenerud
> >>Which one will be faster?
> >
you
> >write it in 8080 assemby language, and translate with an 8086 assembler.
> >
> >That is, if you are not concerned about portability back to the 8008 and
> 4004.
>
> Actually it would be the one in pentium pro/II optomized 32bit x86
assembly
> code.
>
Yes, but when Intel rolls out the ia64 chips in a couple of years and they
become mainstream (or someone else takes over the market), our portable
software will take full advantage of the new hardware, while yours will
still chug along in pentium pro/II optomized 32bit x86 assembly code.
All it takes is one change in the caching scheme or the instruction
scheduling and your program bottlenecks.
I wish you luck trying to rewrite code optimized for one processor to
another one.
Karl Stenerud
> I am not looking for such program to run under xterm nor for it to be
> universally portable. If such functionality is eventually added to the
> kernel a "Linux console" program can be written to allow such programs to
> run under X Windows such as DOS programs can do under Win95/NT and OS/2.
If you're not looking to make it portable, then don't write it for Linux.
In this age of changing video cards and new emerging standards, we'll be
better off without it.
> Yes I know this is a function of the terminal driver, an annoying one
amoung
> others. That why I would like an "enhanced" console with an althernate
mode
> for user freindly programs.
Fine, so write one. You have a brain, don't you?
Just make sure it's portable... =)
Kaz Kylheku
In article <01bd47ad$5d1df2c0$7e13...@bm.mdsi.bc.ca>,
Karl Stenerud <ksteneru...@mdsi.bc.ca> wrote:
>John Smith <sm...@nowhere.com> wrote in article
><6ddp6e$n...@camel19.mindspring.com>...
>> I am not looking for such program to run under xterm nor for it to be
>> universally portable. If such functionality is eventually added to the
>> kernel a "Linux console" program can be written to allow such programs to
>> run under X Windows such as DOS programs can do under Win95/NT and OS/2.
>
>If you're not looking to make it portable, then don't write it for Linux.
>In this age of changing video cards and new emerging standards, we'll be
>better off without it.
Don't worry; it's unlikely that it will ever come to fruition. :)
firewind
On 4 Mar 1998, Karl Stenerud wrote:
> John Smith <sm...@nowhere.com> wrote
> > compared to DOS equivalents. As a programmer and a user I can state with
> > certainty that Linux needs to allow access to low level console functions
> > including display, mouse, & keyboard.
>
> Take a look at the linux GGI project.
GGI does not belong in Linux. The day Linus agrees to put it in the kernel
(which I don't see happening anytime soon) is the day I stop using Linux.
--
(initiator of the campaign for grumpiness where grumpiness is due in c.l.c)
Attempting to write in a hybrid which can be compiled by either a C compiler
or a C++ compiler produces a compromise language which combines the drawbacks
of both with the advantages of neither.
-- John Winters <jo...@polo.demon.co.uk> in comp.lang.c
firewind
On 5 Mar 1998, Christopher Browne wrote:
> On 4 Mar 1998 08:58:34 GMT, Jarkko L T Lehto <jltl...@cs.Helsinki.FI> wrote:
> >doesn't have half the features of XEmacs? I don't think so.
> >BTW. I use VIM 5.0 and it's just great! Sure it's hard to learn but when
> >you learn it it's quite powerful..
>
> - There isn't a calculator that integrates into VIM that knows how to do
> symbolic differentiation.
A calculator is not an editing tool.
> - There isn't a news client that runs inside VIM.
A news client is not an editing tool.
> - There isn't a mail client that runs inside VIM.
A mail client is not an editing tool.
> - There isn't a spreadsheet that runs inside VIM.
A spreadsheet is not a [text] editing tool.
> - There isn't [lots of Elisp packages that run inside GNU
> Emacs/XEmacs]...
Which also, for the most part, aren't text editing tools.
> One can argue over whether or not these functions should be correctly
> put into a text editor; they're certainly extensions that don't exist
> in the VI family of editors.
Exactly; vi is a text editor, while emacs is an operating system.
Bill Currie
firewind wrote:
> GGI does not belong in Linux. The day Linus agrees to put it in the kernel
> (which I don't see happening anytime soon) is the day I stop using Linux.
What is it that YOU don't like about GGI? I hate the solid yellow
cursor in text mode (bletch, I like my blinky little cursor).
However, GGI itself (AIUI) does not go in the kernel, only KGI (kernel
graphis interface) does. It seems that KGI has just enough
functionality to provide user mode drivers access to the hardware
without having to go root and I think also provide a little hardware
abstraction, but I'm not certain.
The CONCEPT of GGI is good, and libGGI does not need the kernel patches
to be usefile as it provides access to various ways of providing
graphics:X, libvga/libsvga, KGI and possibly others (I think some people
are providing an Allegro interface for DJGPP, and possibly the other way
round, and DirectX<->libGGI is being talked about as well).
I HAVE tried GGI, but I didn't get far (didn't finish installing it) as
I don't like rebooting too often (I'm lazy). I think that GGI becoming
mainstream SHOULD be seriously considered as it could open up a whole
lot of opportunities for Linux.
Bill
--
Leave others their otherness
Christopher Browne
On 4 Mar 1998 12:21:07 GMT, Matthias Buelow
<to...@cip.informatik.uni-wuerzburg.de> wrote:
>In article <6dgvnb$gng$2...@blue.hex.net>,
>Christopher Browne <cbbr...@hex.net> wrote:
>
>>an example of a very well constructed editor that was written in tuned
>>x86 machine language. Interestingly, it gives the user the option of
>
>up to 64K (yes, that's _kilobytes_), with some proprietary "compression"
>techniques, up to 90K. That could probably be enough for a mail editor,
>but not for serious work today.
90K is nonetheless useful enough for a lot of "serious work" in the
absence of MS Bloatware. 90K in VDE provides space for on the order of
80 pages of document, which is much larger than most documents I work
with. Moreover, documents I work with that *are* larger than 90K are
generally broken up into subdocuments *anyways*, because 90 pages of
"stuff" gets unwieldy.
On a more technical note, and moving back to the original point (the
value of portability), I certainly agree that the limitations exist, and
that they are restrictive. And they come from having written the
program in tuned x86 machine language.
VDE displays both sides of the argument, both good and bad.
- It was heavily tuned for a particular architecture, so it is real
efficient there. This is a good thing.
- It was heavily tuned for a particular architecture, and doesn't scale
up when architectures change. This is a bad thing.
--
"World domination. Fast" (By Linus Torvalds)
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Christopher Browne
>> most powerful editors, yet it is easy to learn the basics.
>> features of XEmacs.
>
>doesn't have half the features of XEmacs? I don't think so.
>BTW. I use VIM 5.0 and it's just great! Sure it's hard to learn but when
>you learn it it's quite powerful..
- There isn't a calculator that integrates into VIM that knows how to do
symbolic differentiation.
- There isn't a news client that runs inside VIM.
- There isn't a mail client that runs inside VIM.
- There isn't a spreadsheet that runs inside VIM.
- There isn't [lots of Elisp packages that run inside GNU
Emacs/XEmacs]...
One can argue over whether or not these functions should be correctly
put into a text editor; they're certainly extensions that don't exist
in the VI family of editors.
>>> Hint: API's make portable code *very* powerful. Can you write
>>> non-portable code which do texture mapping on every PCI graphics
>>> card that has hardware texture mapping? I can write portable
>>> code that does that.
>> No you can't, unless you are using Windows 95 or ignoring the
>> hardware texture mapping.
>
>This is a troll, I guess?
Presumably.
--
M$ is for people who want a half-way implementation of yesterday's
ideas tomorrow.
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Roy Stogner
On 5 Mar 1998 03:46:56 GMT, Christopher Browne <cbbr...@news.hex.net> wrote:
>On 4 Mar 1998 08:58:34 GMT, Jarkko L T Lehto <jltl...@cs.Helsinki.FI> wrote:
>>In article <vc7btvn...@saturn.cs.uml.edu>,
>> acah...@saturn.cs.uml.edu (Albert D. Cahalan) writes:
>>> That is a huge pile of arrogant BS. XEmacs is clearly one of the
>>> most powerful editors, yet it is easy to learn the basics.
>>> Compare to vi, which is hard to learn and doesn't have half the
>>> features of XEmacs.
>>
>>doesn't have half the features of XEmacs? I don't think so.
>>BTW. I use VIM 5.0 and it's just great! Sure it's hard to learn but when
>>you learn it it's quite powerful..
>
>- There isn't a calculator that integrates into VIM that knows how to do
>symbolic differentiation.
>- There isn't a news client that runs inside VIM.
>- There isn't a mail client that runs inside VIM.
>- There isn't a spreadsheet that runs inside VIM.
>- There isn't [lots of Elisp packages that run inside GNU
>Emacs/XEmacs]...
No, but vim runs inside my news client and mail client just fine, and
has nothing to do with my calculator or spreadsheet. It is an editor.
When choosing between vim and emacs/Xemacs, I am looking to use an
effective editor. If I was looking to use a program with a
disagreeable interface which nevertheless draws development work away
from real operating systems, I WOULD BE USING WINDOWS 95.
---
Roy Stogner
T.E.Dickey
In comp.os.linux.development.apps Klau7s.S...@home.ivm.de wrote:
: Btw. Ncurses-4.2 is now available from alpha.gnu.org (warning: it is beta
: software, not much tested yet, so only install if you know exactly what to do.
Not really beta (it's queued up for release). Upgrading a library is (I
assume this is your point) is indeed something that you should know how to
assess the impact, vis the ongoing problems with Redhat 5.0 & glibc 2.x).
The only 'new' bugs we encountered during beta (and are holding for
post-4.2 development) are a couple of longterm bugs that are present in
older versions such as 1.9.9e. (It'd be nice to fix all of the bugs, but
we haven't found them yet ;-).
--
Thomas E. Dickey
dic...@clark.net
http://www.clark.net/pub/dickey
Kaz Kylheku
In article <6dl77g$h3q$7...@blue.hex.net>,
Christopher Browne <cbbr...@hex.net> wrote:
>On 4 Mar 1998 08:58:34 GMT, Jarkko L T Lehto <jltl...@cs.Helsinki.FI> wrote:
>>In article <vc7btvn...@saturn.cs.uml.edu>,
>> acah...@saturn.cs.uml.edu (Albert D. Cahalan) writes:
>>> That is a huge pile of arrogant BS. XEmacs is clearly one of the
>>> most powerful editors, yet it is easy to learn the basics.
>>> Compare to vi, which is hard to learn and doesn't have half the
>>> features of XEmacs.
>>
>>doesn't have half the features of XEmacs? I don't think so.
>>BTW. I use VIM 5.0 and it's just great! Sure it's hard to learn but when
>>you learn it it's quite powerful..
>
>- There isn't a calculator that integrates into VIM that knows how to do
>symbolic differentiation.
I usually use `bc' as a calculator from within vim. It doesn't do symbolic
algebra or calculus, but I don't need those features in a calculator.
I type a line like
scale = 3; 3^51 / 4
Then type <ESC>!!bc<Enter>
and the text is replaced by the answer:
538423490768889441577686.750
I'm afraid you are confusing features of Emacs with the add-on extensions
to Emacs which its programmability allows.
>- There isn't a news client that runs inside VIM.
I use a news client that runs in UNIX, which is a better operating
system than Emacs. :)
>- There isn't [lots of Elisp packages that run inside GNU
>Emacs/XEmacs]...
These aren't features of Emacs, but add ons. Each package must be separately
learned, too. If you don't know how to use vi, could you instantly use a vi
emulation package.
Elisp is shit anyway. Real programs are written in C, and failing that,
assembly language.
Kaz Kylheku
In article <Pine.LNX.3.95.98030...@metroid.dyn.ml.org>,
firewind <fire...@metroid.dyn.ml.org> wrote:
>> One can argue over whether or not these functions should be correctly
>> put into a text editor; they're certainly extensions that don't exist
>> in the VI family of editors.
>
An operating system with no real-time capability which juggles processes
written in some inefficient mess consisting of nested parentheses interspersed
with other symbols. :)
Jarkko L T Lehto
In article <6dl77g$h3q$7...@blue.hex.net>,
cbbr...@news.hex.net (Christopher Browne) writes:
>>doesn't have half the features of XEmacs? I don't think so.
>>BTW. I use VIM 5.0 and it's just great! Sure it's hard to learn but when
>>you learn it it's quite powerful..
> One can argue over whether or not these functions should be correctly
> put into a text editor; they're certainly extensions that don't exist
> in the VI family of editors.
Nor do they exist in any other editor but of Emacs family. I really don't
think they are functions of editor! They only use emacs as a 'shell'..
But as a editor for programmers what properties are there in Emacs which
don't exist in VIM?
Christopher Browne
On 5 Mar 1998 07:41:40 GMT, Roy Stogner <royst...@SPAMiname.com> wrote:
>On 5 Mar 1998 03:46:56 GMT, Christopher Browne <cbbr...@news.hex.net> wrote:
>>On 4 Mar 1998 08:58:34 GMT, Jarkko L T Lehto <jltl...@cs.Helsinki.FI> wrote:
>>>BTW. I use VIM 5.0 and it's just great! Sure it's hard to learn but when
>>>you learn it it's quite powerful..
>>
>>symbolic differentiation.
>>- There isn't a spreadsheet that runs inside VIM.
>>Emacs/XEmacs]...
>
>has nothing to do with my calculator or spreadsheet. It is an editor.
What news client and mail client are you running? I'm not aware of any
in which VIM would embed itself.
The notion that your news/mail client can *spawn* VIM is not
particularly foreign; I'm rather surprised at the thought that there's
something inside which VIM will run...
--
The *Worst* Things to Say to a Police Officer: Sorry, Officer, I
didn't realize my radar detector wasn't plugged in.
cbbr...@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>
Kurt Wall
In comp.os.linux.development.apps Roy Stogner <royst...@SPAMiname.com> wrote:
> On Sat, 28 Feb 1998 14:56:49 -0500, John Smith <sm...@nowhere.com> wrote:
> >Kaz Kylheku wrote in message <6coj24$pl2$1...@brie.direct.ca>...
> >>You are still thinking within an MS-DOS mentality. Use a library such as
> >>ncurses.
> >MS-DOS still has much better looking and functioning programs so Linux, in
> >this respect, could use a little DOS mentality.
> There is no rational justification for this statement. "Better
Yes there is. The original post was a troll, no, make that "Troll," given
the list of groups he cross-posted to, no, make that "spammed," no, make
that "Spammed."
Kurt
krw...@earthlink.net
--
PCMCIA (n.): "People Can't Memorize Computer Industry Acronyms"
Christopher Browne
William McBrine
In comp.os.linux.development.apps firewind <fire...@metroid.dyn.ml.org> wrote:
: GGI does not belong in Linux. The day Linus agrees to put it in the kernel
: (which I don't see happening anytime soon) is the day I stop using Linux.
I think you may misunderstand the nature and purpose of GGI. Nothing
personal, but that's just what I've observed among many of the anti-GGI
advocates.
You know what doesn't belong in Linux? Programs -- including X servers --
that can lock up the console, tight. That's what GGI is designed to
prevent. (It has some other neat features, of course, but if I had to
identify a single driving purpose behind it, that seems to be it.)
--
William McBrine | http://www.clark.net/~wmcbrine/
wmcb...@clark.net | Unsolicited commercial emailers will be annihilated