Program działający na inny program.

Ok, trochę przesadziłem, chodziło mi oto że koncepcyjnie .net jest i ma być całkowicie rozdzielne od winapi. Obecna implementacja rzeczywiście go używa.

Na WinAPI się nie znam, ale akurat z .NET'a trochę łykam. Jest lepszy, a przy instalacji odpowiednych aplikacji w różnych systemach (nie śmiejcie się ze mnie, bo jest Mono, DotGNU) także kod aplikacji pod nim napisanych jest także wieloplatformowy (wolne implementacje).

Język asemblera ma do tego tyle, że jak się totalnie nie ma pojęcia, o czym się pisze, to trzeba rzucić jakimś "fachowo" brzmiącym słówkiem, żeby sprawiać wrażenie, że się jednak wie, o czym się mówi.

Zależy gdzie umiera - do grzebania w niekoniecznie cnych celach WinAPI (wspomagane przez Native API, a jak) jest najbardziej sensownym rozwiązaniem. Do innych zastosowań nie musiało nawet umierać, bo poza kilkoma maniakami nikt niczego sensownego w gołym WinAPI nie robił.

A .NET to nie jest nakładka na winapi, tylko na nativeapi

W takim razie Native API jest w różnych dziwnych miejscach jak np. kernel32.dll, bo (nie licząc paru nieważnych funkcji z ntdll.dll) .NET importuje funkcje właśnie z niego i kolegów.

Native API? Chcesz być RE/twórcą malware/itp.? Jeśli nie, to i tak ci się ta wiedza nie przyda.
Nawet WinAPI będzie zbędne - jest tyle bibliotek, które pozwalają na programowanie większości rzeczy, do których używa się WinAPI, w sposób bardziej wysokopoziomowy i wygodniejszy... Chyba, że <patrz początek posta>.