All implementations of X/Open Curses provide a "curses.h". ncurses provides this via a symbolic link to its own implementation "ncurses.h", making it possible to select that header file if there is another implementation installed, e.g., on Solaris.
If you were configuring ncurses (to build it), the INSTALL
file explains it in the context of one of the configure options:
--disable-overwrite
If you are installing ncurses on a system which contains another
development version of curses, or which could be confused by the loader
for another version, we recommend that you leave out the link to
-lcurses. The ncurses library is always available as -lncurses.
Disabling overwrite also causes the ncurses header files to be
installed into a subdirectory, e.g., /usr/local/include/ncurses,
rather than the include directory. This makes it simpler to avoid
compile-time conflicts with other versions of curses.h
Putting the header files into a subdirectory assumes that applications
will follow the (standard) practice of including the headers with
reference to the subdirectory name. For instance, the normal ncurses
header would be included using
#include <ncurses/curses.h>
#include <ncurses/term.h>
while the ncursesw headers would be found this way:
#include <ncursesw/curses.h>
#include <ncursesw/term.h>
In either case (with or without the --disable-overwrite option),
almost all applications are designed to include a related set of
curses header files from the same directory.
Manipulating the --includedir configure option to put header files
directly in a subdirectory of the normal include-directory defeats
this, and breaks builds of portable applications. Likewise, putting
some headers in /usr/include, and others in a subdirectory is a good
way to break builds.
When configured with --disable-overwrite, the installed header files'
embedded #include's are adjusted to use the same style of includes
noted above. In particular, the unctrl.h header is included from
curses.h, which means that a makefile which tells the compiler to
include directly from the subdirectory will fail to compile correctly.
Without some special effort, it will either fail to compile at all,
or the compiler may find a different unctrl.h file.