[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ncurses & native WIN32 support...

From: Austin Gilbert
Subject: Re: Ncurses & native WIN32 support...
Date: Thu, 10 Nov 2005 09:08:32 -0600

On Nov 10, 2005, at 4:34 AM, William McBrine wrote:

On Tue, 8 Nov 2005, Austin Gilbert wrote:

I can tell you that PDCurses doesn't compile on my Mac OS 10.4.3 machine out of the box :( This makes me somewhat concerned about its portability.

No, no, that's not what it's for. It doesn't *have* to be portable (though it is -- just not as portable as ncurses). You don't write for PDCurses or ncurses; you write for the standard curses API, and link against ncurses, system curses, or PDCurses, as appropriate, depending on your target platform. If you use advanced features that are ncurses- or PDCurses- specific, you ifdef them. But most programs won't need that.

Okay... this is good advice. I asked at some point if the API's matched up - I couldn't be sure of this since PDCurses documentation is scarce.

Even if you did get PDCurses working on your Mac, that would be of limited usefulness, since the "X11" port of PDCurses (the only one that could work on the Mac) is just that -- it runs directly on X, rather than in a terminal, as you might expect. <snip>

Hmmm, yeah, I wasn't really interested in PDCurses for OSX since I already have NCurses. I was simply making a point about the portability of PDCurses.

The general idea is that curses is a portable API, while the implementation is system-specific. PDCurses and ncurses are implementations that are themselves somewhat cross-platform; but the key to portability is the API.

I realize this is the best we have at the moment, and it is a very reasonable and respectable approach, but wouldn't it be better if there was a single implementation that handled both Unix and DOS, Windows, & OS/2?? In a perfect world, given the choice, I would prefer to work with a single library rather than two (or more) platform specific implementations of a single API. Wouldn't you?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]