Curses for win32 with VT100/ANSI support

D

Daniele C.

As soon as my sourceforge.net project gets approved, I am going to
build a ncurses port to win32 bindable to sockets, e.g. allowing
VT100/ANSI terminals and the creation of simple terminal servers using
the ncurses API for the UI. I plan to initially support only a subset
of the ncurses lib, leaving the lib open to expansion/completion.

Please stop me if I am going to reinvent the wheel, and tell me if
there are any libraries of this kind.

1. No, I don't want to use cygwin
2. Yes, I know pdcurses, it is great and I plan to use it for normal
ncurses consoles but I need a socket-bound vt100 terminal library...

Thank you!
 
K

Keith Thompson

Daniele C. said:
As soon as my sourceforge.net project gets approved, I am going to
build a ncurses port to win32 bindable to sockets, e.g. allowing
VT100/ANSI terminals and the creation of simple terminal servers using
the ncurses API for the UI. I plan to initially support only a subset
of the ncurses lib, leaving the lib open to expansion/completion.

Please stop me if I am going to reinvent the wheel, and tell me if
there are any libraries of this kind.

Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)
 
C

Chris Hills

Keith Thompson <kst- said:
Sorry, this is the wrong place to ask. Try a Windows programming
newsgroup, possibly comp.os.ms-windows.programmer.win32. (Or a Google
search.)

This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.

This is precisely the place to talk about the majority of the code for a
curses library. The only difference for the many dozens of terminal
types are the escape sequences. These are usually held in a text file so
you can swap terminal types easily.

Very little of this will be windows or any other OS specific
 
S

Skarmander

Chris said:
This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.
The OP is trying to *implement* a networked ncurses on a particular
platform. This is going to involve OS or library-specific stuff, unless you
believe in magic.
This is precisely the place to talk about the majority of the code for a
curses library. The only difference for the many dozens of terminal
types are the escape sequences. These are usually held in a text file so
you can swap terminal types easily.

Very little of this will be windows or any other OS specific
Very little of this will be C specific too, and that's what this newsgroup
is about. There are no questions about the C language here. If there are
questions about what's portable and what's not, that would be another matter.

S.
 
C

Chris Hills

Skarmander said:
The OP is trying to *implement* a networked ncurses on a particular
platform. This is going to involve OS or library-specific stuff, unless you
believe in magic.

SO there will be some OS specific parts of the code. The majority will
not be. Unless this NG is ONLY for pure portable ISO C99 code. As the NG
is not for that he can post here.
Very little of this will be C specific too, and that's what this newsgroup
is about.

It's written in C which is what this NG is about.
There are no questions about the C language here. If there are
questions about what's portable and what's not, that would be another matter.

Wrong. but you are entitled to your opinion.
 
K

Keith Thompson

Chris Hills said:
This has bugger all to do with windows. Curses is a portable screen
handling system for terminal windows. I have used the same curses
library on an Atari ST, Dos, Win9* (in a dos window) MAC and various
unix. It is a portable system.

This is precisely the place to talk about the majority of the code for a
curses library. The only difference for the many dozens of terminal
types are the escape sequences. These are usually held in a text file so
you can swap terminal types easily.

Very little of this will be windows or any other OS specific

He wasn't asking about the code. He wasn't asking how to implement
anything. He was asking whether anyone else had already implemented
such a library *for win32*. That's not a C question.

The Linux kernel is written in C; that doesn't make a question about
porting it to some specific platform topical here. Ditto for any of
the thousands of other software packages implemented in C.
 
M

Malcolm

Chris Hills said:
SO there will be some OS specific parts of the code. The majority will
not be. Unless this NG is ONLY for pure portable ISO C99 code. As the NG
is not for that he can post here.
And if I write a knitting program, probably the stitch database and most of
the logic will be implemented in portable ANSI C, with only a minor
Windows-specific user interface.
Does that make the knitting / crotchet debate topical here?
It's written in C which is what this NG is about.
The difference is that a curses library is something that programmers use.
There is a case for including it in the standard library, though in fact the
ANSI library has no such functions.
Wrong. but you are entitled to your opinion.
We could allow it, but it would be expanding the scope of the group. I've no
use for a curses system, for instance. If I need a non-stream user interface
I'll use a windowing library, or html forms, or Java.
 
K

Keith Thompson

Chris Hills said:
You can not dis-allow it. You can have no say in the matter. I refer you
to the charter.

We certainly do have a say in the matter; we just don't have an
effective enforcement mechanism.

It seems clear to me that any answer to the OP's actual question would
not be based on a knowledge of the C programming language.
 
J

Jordan Abel

We certainly do have a say in the matter; we just don't have an
effective enforcement mechanism.

The problem is that it's not clear what authority your opinion on what
was the pre-existing "scope of the group" which "allowing" this would be
"expanding" is based on.
 
A

Andrew Poelstra

The difference is that a curses library is something that programmers use.
There is a case for including it in the standard library, though in fact the
ANSI library has no such functions.

Not a lot of systems have a screen. I've programmed routers with which I
communicated with entirely by FTPing log files around. Curses would just
be an unneccessary pain for compiler writers.

The only addition to the library that I think is feasable would be some
decent networking functions; all systems have networks, with the exception
of embedded systems, which already have their special small library.
 
C

Chris Hills

Keith Thompson <kst- said:
We certainly do have a say in the matter; we just don't have an
effective enforcement mechanism.

TO be more accurate *I* have a say in the matter but not an effective
enforcement system to correct you..... :)
 
C

Chris Hills

Andrew said:
Not a lot of systems have a screen. I've programmed routers with which I
communicated with entirely by FTPing log files around.

This is incorrect. In fact this is one place where you probably might
need curses.
Curses would just
be an unneccessary pain for compiler writers.

Why? Compiler writers write compilers not libraries.
Library writers write libraries.
The only addition to the library that I think is feasable would be some
decent networking functions;

Not really there are far to many types of network to do a standard
network library.
all systems have networks,

Completely untrue by a VERY long way.
with the exception
of embedded systems,

Lots of embedded systems have networks of one sort or another. Profi,
CAN and LIN for starters.
which already have their special small library.

Complete bollox.

You seem to have a very limited knowledge of things.
 
K

Keith Thompson

Chris Hills said:
TO be more accurate *I* have a say in the matter but not an effective
enforcement system to correct you..... :)

I fail to see how that's more (or less) accurate that what I wrote.

The original question was about whether anyone had implemented a
certain kind of curses/ncurses library for win32 (something to do with
sockets; I don't remember the details). The OP was about to start
work on such a project, and wanted to avoid re-inventing the wheel.

Chris, can you explain just how such a question has anything to do
with the C programming language? I know that ncurses happens to be
implemented in C, but the OP wasn't asking about how to implement it.

I see absolutely nothing in the original question such that a
knowledge of the C programming language would be helpful in providing
an answer.

Why do you continue to insist that the question was topical? That's a
serious question.

(To be clear, I'm not angry at the OP for asking an off-topic
question; mistakes happen.)
 
A

Andrew Poelstra

This is incorrect. In fact this is one place where you probably might
need curses.
curses is a screen display, correct? So, unless I'm telnetting or
SSHing onto a system without a screen, curses is useless.
Why? Compiler writers write compilers not libraries.
Library writers write libraries.
I stand corrected.
Not really there are far to many types of network to do a standard
network library.


Completely untrue by a VERY long way.
Not too far off; a system needs to communicate with the outside world
in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.
Lots of embedded systems have networks of one sort or another. Profi,
CAN and LIN for starters.
I should have said *some* embedded systems, which I thought was implied
by not stating *all* embedded systems.
Complete bollox.
No, the C Standard specifies that small systems with limited space may
use a small subset of the standard library.
You seem to have a very limited knowledge of things.
That is true for everyone, no? ;-)
 
W

Walter Roberson

Not too far off; a system needs to communicate with the outside world
in almost all cases, and since many systems lack a screen, having some
sort of network would be a logical choice.

Input:

Keyboards (for typing), keyboards (musical type), touch-screen,
stylis, magnetic card, RFID chip, camera... even punch cards still
(e.g., some fare collection systems)

Output:

CRT, LCD displays, LCD screens, LED displays, plasma, printers
(inkjet, thermal, laser, photo), rewrite magnetic card, speakers,
CD/DVD writer...

Bidirectional:

Serial ports, parallel ports, infrared (e.g., PalmPilot), CD/DVD RW,
USB, USB memory stick, radio...


Consider for example cheap programmable calculators. Are they
"embedded" ? It could be so argued, but if they are programmable then
the distinction between embedded and not becomes blurred.
 
K

Keith Thompson

Jordan Abel said:
It's never been clear to me why it requires more of a consensus to
change this "policy" than it apparently did to create it in the first
place.

I'm not sure what you mean. I don't know what would be required to
change the current de facto policy, but I haven't seen any consensus
to change it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top