Do (N)curses, terminfo, termcap, etc... work on regular terminals and not just terminal emulators?
Printable View
Do (N)curses, terminfo, termcap, etc... work on regular terminals and not just terminal emulators?
Do you think this Sega Genesis game cartridge will work in an actual Sega Genesis (as opposed to an emulator)?
lol :pQuote:
Originally Posted by brewbuck
yes supposedly before mtv there was tha full color text console, which was quite an improvement on the classic monogreen terminal, so they wrote crazy libraries for such things
I suppose it is not really a silly question since it's totally conceivable the answer could be a silly one, like "actually no...". Anyway, yes, all the fabulous text console apps you can get to via "alt-ctrl-f7" on linux use those libraries (ncurses or termcap) and they work equally well in the GUI terminals, qv. http://cboard.cprogramming.com/gener...tml#post879748. Apps run in the terminal emulator are the exact same executable that would run on the CLI console. I assume this is true for MS-DOS also.
>> Do (N)curses, terminfo, termcap, etc... work on regular terminals and not just terminal emulators?
Maybe on really old equipment (not sure though) but certainly not any more.
So what is it they do not work on?????? You monitor is a terminal. They work on my monitor. They've always worked. They never stopped working.Quote:
Originally Posted by Sebastiani
>> So what is it they do not work on?????? You monitor is a terminal. They work on my monitor.
I meant that they wouldn't work without an emulator. I think the way it use to work is that the terminal server would send/recieve control signals directly to/from the (dumb) terminal. Naturally, that won't work any more since all terminals these days (I am assuming) run on top of some sort of operating system, so in that sense the session has to be "emulated" (eg: information marshalled in and out).
I could be wrong though.
EDIT (from Wikipedia):
Quote:
In the context of traditional computer terminals that communicate over a serial RS-232 connection, dumb terminals are those that can interpret a limited number of control codes (CR, LF etc.) but do not have the ability to process special escape sequences that perform functions such as clearing a line, clearing the screen, or controlling cursor position. In this context dumb terminals are sometimes dubbed glass teletypes, for they essentially have the same limited functionality as does a mechanical teletype. This type of dumb terminal is still supported on modern Unix-like systems by setting the environment variable TERM to dumb. Smart or intelligent terminals are those that also have the ability to process escape sequences, in particular the VT52, VT100 or ANSI escape sequences.
[...]
In the broader context that includes all forms of keyboard/screen computer communication devices, including personal computers, diskless workstations, network computers, thin clients, and X Terminals, the term dumb terminal is sometimes used to refer to any type of traditional computer terminal that communicates serially over a RS-232 connection that does not locally process data or execute user programs.
[...]
Since the advent and subsequent popularization of the personal computer, few genuine hardware terminals are used to interface with computers today. Using the monitor and keyboard, modern operating systems like Linux and the BSD derivatives feature virtual consoles, which are mostly independent from the hardware used.
There doesn't seem to be a black or white answer. From that Wikipedia qoute it seems most dont though. Programming for just an emulator is dumb. Ncurses kinda lost my support. Btw alt-ctl-f7 gives nothing on Debian Lenny
>> There doesn't seem to be a black or white answer.
I think it's pretty clear. Ncurses, et al, are semi-generic software packages that don't access old-school dumb terminals directly (thank God) but via some sort of software adaptor (virtualization/emulation system).
>> Programming for just an emulator is dumb.
Too much abstraction for you? :p On the contrary, the emulator makes it possible for you to write code that works on *virtually* every platform. Without it, you'd be writing code to access the hardware of an older terminal, and your *own* emulator to access newer terminals. So emulation is win/win, really.
>> Ncurses kinda lost my support.
Why so?
Really? Works fine for me on the game server I just finished some 3 months ago for linux and windows consoles.Quote:
Originally Posted by Aparavoid
Sorry, it's alt-ctl-f1/f2/f3/f4/f5/f6 to drop into text console mode -- you have to select one of 6 ttys. To go back to the GUI you use alt-ctl-f7. And it does work in lenny, I just checked. So if that is what you mean by "terminal" (no GUI windowing system at all), there you are; my definition of a terminal would be a tty device.Quote:
Originally Posted by Aparavoid
Anyway, vis. "Programming for just an emulator is dumb." -- 99% of the places where the apps are run are either a normal monitor used in terminal mode, or in an X terminal. A serial port "dumb" console is kind of an unusual and specialized thing. I would imagine software has to be written specifically for a piece of hardware in that case, so there is no such thing as a portable library for dumb terminals.
>>Why so?
Mostly for the resons I listed above but the more I think about it, may programming for an emulator isn't a bad idea. I guess people who make Gameboy games plan on use for a computer too and not just and actual gameboy. I figured out f7 puts it back in GUI which is why it didn't appear to do anything.
Ok, I'm getting lost in the debate. But lets get something straight here...
Today's consoles running on such systems as Windows and Linux are emulations of smart terminals. Most notorious for the issue at hand, the VT100 terminal. So... to start with, you have a console that in fact is an emulator. To put it blunt, our current mainstream systems aren't terminals. They emulate a terminal through the console.
Now, ncurses is, taken verbatim from wikipedia, a programming library providing an API, allowing the programmer to write text user interfaces in a terminal-independent manner. It's a toolkit for developing "GUI-like" apps which run under a terminal emulator.
So, "programming for an emulator" as you put it is on this case not optional. It's mandatory. However, it's also irrelevant. The ncurses library is not an emulator. It is only concerned with providing the programmer with an API they can use to create text user interfaces for these consoles. They are the emulators.
Your next concern is the system you are working on. For linux, you use ncurses from the GNU project. For other systems you need to look up for their respective ports. For windows, I use PDCurses which is a straight ncurses windows port which facilitates your work a lot in case you need to maintain both linux and windows versions of your software.
Almost true but not quite.Quote:
Originally Posted by Mario F.
If you look thru an old /etc/termcap (which isn't included anymore) you will find hundreds of pages of definitions for specific terminal types including the VT100, etc. etc. AND the "linux console". In other words, the console (which does not have to run in an emulator) is exactly the same as a hardware device: the interface is provided by the linux kernel, the same way it would provide an interface to a physical device. This is possible because standard monitors are way more similar to each other than the heterogeneous collection of physical terminal types.
So I will stick to what I was saying before: the linux console *outside* of the GUI, does not use a terminal emulator. It is a terminal type, defined the same way using the same protocols as any other type of terminal. It does not emulate any of them, altho I believe it is intended to be compatible with software written for the VT100.
The issue really is which terminals will (eg) ncurses run on, and a partial answer is it will run on a linux console and in a terminal emulator of the console in X windows. The console *is not* an emulator; the emulator is (eg) xterm, which the console will run in an xterm because that is a terminal emulator. But with the GUI turned off, it will run in the physical terminal device interfaced by the kernel, aka your monitor, with no emulation of anything else involved.