Re: Ncurses & native WIN32 support...

[Austin Gilbert]

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?