curses/ncurses

[nategoose]

Why was reliance on ncurses removed?
The current libfb will only work on terminals compatable with
vt100 (xterm, linux-console, eterm, putty, and several others),
some of which are not recognised in $TERM. Using curses or the S-lang library allows for much greater termial
compatibility, since they query the termcap or terminfo
databases based on $TERM.

[lillo]

Wider compatibility was sacrificied for more speed, compactness and standalone-ess. Curses or S-lang are nice libs, but at least the first is slooow. To address this need for speed, the custom routines now built in libfb were coded. This also had the nice side-effect of removing a dependency (which is always nice), also further reducing FB output exe size (which is nice too).

Almost any known terminal has at least VT100 emulation... so I don't think that's a big deal. Ok, maybe something could be done to better identify the terminal, maybe via termcap (though I never used it), but VT100 compliance is a must.

[jonathanbrickman0000]

Well, lillo, I'll agree that the vast majority of terminals now in use are VT-102 compatible; however, there are still a large collection of IBM 3270 and 5000-series emulators and even hardware terminals still in use, and there used to be hundreds (might be close to a thousand) of entirely different specs. If I were programming text-mode and needed to the code to run immediately in parts of Asia, Europe, South America, or Africa, I would have to use the Linux termcap database, which to my knowledge was developed over about thirty years (beginning long before Linux) to cover all of them. And the curses and S-Lang libraries were designed to use that termcap database. If you take a look at a very high quality PC terminal emulator (pre-Internet BBS comm program, I think Qmodem and ProComm still exist, and there are others), you'll see a list of at least a dozen or two, and those were just the most common in the 80's and 90's.

But happily, I'm not :) At the moment, I would dearly love to include a rxvt binary with every app. We'll see how much of a pain it is to make that work.

[lillo]

Some things have changed in the Linux port of FB since I wrote the first reply to this topic. For 0.15 I completely rewrote the Linux console handling routines to allow them to use the termcap library for wider compatibility. The only use I made of it was to query the terminals database for correct escape sequence strings, nothing more. Infact Linux apps compiled with FB 0.15 now depend on libtermcap. Later, I found out that some distros don't ship with termcap installed, and that this is being faded out in favour of the terminfo library/database structure. The ncurses library however provides an abstraction layer on top of terminfo, and it also provides compatibility functions for termcap, so on FB 0.16 (currently on CVS) I changed FB to link with libncurses again, and it seems to work just fine.

[jonathanbrickman0000]

Excellent. Now if I can only learn how to get vt102+mouse emulation to exist in Win32 :)

I don't know if you saw the other discussion on the subject, but rxvt doesn't do FBC's INPUT under either Cygwin or MSYS, because of some weird known troubles in Win32 console stdio. I have just discovered that Cygwin's rxvt will do 'links' (text-mode WWW, the Cygwin package is 0.99pre14), however, and very well, so there must be a solution buried in the Cygwin ncurses code: S-Lang is not installed, links must be using ncurses.

How hard would it be to compile and link an FBC app using Cygwin's ncurses...?

[skystrick]

Some things have changed in the Linux port of FB since I wrote the first reply to this topic. For 0.15 I completely rewrote the Linux console handling routines to allow them to use the termcap library for wider compatibility.

So is still part of FB? And if so, how do I make use of it?

I have a Wyse WY-60 serial terminal connected to my Ubuntu Linux computer, running FBC 0.91.0

When the Wyse terminal is in VT100 emulation mode, it works fine. Everything's perfect. It's actually the whole reason I use FB, it's the only QuickBASIC-dialect-compatible program which lets me address a dumb terminal.

But if I use the terminal in a different emulation mode - WYSE50 or WYSE60, for example - it will not work with FB. It works fine with bash, nano, Alpine (email), and all my other text-mode apps, but FreeBASIC causes it to crash immediately upon attempting to run a compiled program.

The cursor moves to the bottom left corner of the screen, prints a lower-case letter 'N', then hangs. I have to <Ctrl>+<C> to get out of it.

Here is a the code of my simple test program, and a screenshot:

Code: Select all

OPEN "CONS:" FOR OUTPUT AS #1
PRINT #1, "Hello, World!";
END

So I'm thinking the termcap/terminfo/ncurses support has been removed from FB at some point over the past 7 years?

[fxm]

Code: Select all

OPEN CONS FOR OUTPUT AS #1
PRINT #1, "Hello, World!";
CLOSE
END

[skystrick]

Code: Select all

OPEN CONS FOR OUTPUT AS #1
PRINT #1, "Hello, World!";
CLOSE
END

Thanks, but adding "CLOSE" makes no difference. It can't even get that far (if that were the issue, it would hang AFTER the Print statement, not before it). Also, I believe the END keyword force-closes all open files.

[fxm]

My main change is:
OPEN CONS FOR OUTPUT AS #1

[skystrick]

My main change is:
OPEN CONS FOR OUTPUT AS #1

Okay, thanks, but that's not the issue here. As i said in my post, it works fine under VT100 mode, just no other mode. The issue is not with my code.

Thanks anyhow.

[dkl]

FB still uses the libtinfo part of ncurses to query the escape sequences to use for various communication codes. It also has some (but not much) terminal-specific code, based on the value of the TERM environment variable. It's built into FB's Unix rtlib, there's nothing one has to explicitly do to use it. There hasn't been a major change in this area since the original author worked on it.

Why does the rtlib hang in your case? My first guess is that it sends an escape sequence to the terminal and the terminal doesn't support it and doesn't send a response, so the rtlib remains waiting forever. Presumably the rtlib's terminal detection isn't extensive enough (also, could terminfo misdetect the terminal type?).

Does a simple Print work?

Code: Select all

print "Hello!"

What about Locate?

Code: Select all

print "Hello!"
locate 10, 10
print "Bye!"

[skystrick]

Does a simple Print work?

No, it does not work. A simple PRINT statement, using your code, produces the same result as my code does (lower-case 'n' at the bottom of the screen, then hang).

You said some small parts of FB use terminal-specific code based on the TERM environment variable; for the record, I am changing this variable in my getty as well as in ther terminal's setup when I am going from VT100 mode to alternate modes (WYSE50, WYSE60, TeleVideo, ADM, etc.) - and stopping then restarting the getty with the new variable. Which explains why the rest of my apps (Alpine, nano, bash, etc.) work fine. No clue why FB can't seem to get aboard...

[skystrick]

Any ideas?

[dkl]

No, none other than what I mentioned above. I have no experience with terminal stuff, besides the work on FB's runtime so far. Can you recommend terminal emulators that'd allow me to test FB under conditions similar to yours?

I was hoping you could do some debugging, find out what where the FB rtlib goes wrong, what it's doing different than other programs, but I understand that diving into the FB source code etc. is a huge task and may be too much to ask.

[skystrick]

No, none other than what I mentioned above. I have no experience with terminal stuff, besides the work on FB's runtime so far. Can you recommend terminal emulators that'd allow me to test FB under conditions similar to yours?

I was hoping you could do some debugging, find out what where the FB rtlib goes wrong, what it's doing different than other programs, but I understand that diving into the FB source code etc. is a huge task and may be too much to ask.

Yes, I cannot understand the source code - the only programming language I know is BASIC. If I could understand more complex codes like C and assembler, I wouldn't be coding in BASIC! :-)

As far as terminal emulators go, what type of system are you using? If it's Linux, I would recommend PuTTY (open-source, free, been around along time, emulates a ton of terminals).