Yes. Exactly. The features of the kernel define and constrain what your programs can do. Compare any UNIX-like to the Windows kernel for example.

Do you get disk devices? Yes -- as drive letters, c:\ d:\ etc, not as direct files.

Do you get terminal devices? Not really, unless you use a com port, and the emulation is still limited.

Do you get partitions? Yes, each mounted on their own root, not (usually) nested.

Do you get folders? Yes -- separated by \, rather than /. (Oddly, some calls in Windows actually can separate by /, some can't.)

Do you get files? Yes -- with case-insensitive names.

Which meant that Cygwin, which does as much as it can to act like UNIX within the Windows framework, can't avoid these facts. Some things it can translate between -- the / vs \ -- but some things are just unavoidable, like case-sensitive filenames. No matter what it does, if you create 'a' in the same folder as 'A', you are just overwriting 'A' again.

This has made some parts of Cygwin more difficult, slow, and complicated than they need to be just because Windows really isn't meant to do what's being asked of it here. fork() for example -- efficient and fundamental in UNIX, but slow and nightmarish to emulate in Windows, because it uses a very different process model. Also terminal devices, which are a bit of a nightmare to build from scratch anywhere you go -- Linus' project began as a terminal emulator, and from there it wasn't too too far to make it a complete kernel

And in the end, Windows' kernel just isn't suited to running UNIX-like things. UNIX can run thousands of tiny, short-lived processes in a few moments without a hiccup, that being one of the things it's designed for. Try and do that on Windows and it lags, hiccups, and kills random ones here and there for no apparent reason other than "if you don't make so many processes, it might do that less". Windows prefers larger, fewer, longer-lived processes.