Zastanawiam się, który jest zaimplementowany pod kątem którego. Domyślam się, że np. fopen jest realizowane za pomocą OpenFile. Z tego co wiem, Win32 API jest pełniejszy niż implementacja biblioteki MSVC C, więc moje przypuszczenie miałoby sens.Co to jest niższy poziom w systemie Windows: biblioteka C lub odpowiednie funkcje interfejsu Win32 API?
Czy to prawda, czy jest na odwrót?
Tak, Win32 to interfejs API "niższego poziomu" niż standardowa biblioteka C ... Zasadniczo standardowa biblioteka C w systemie Windows jest abstrakcją macierzystych systemów Windows, która pozwala niektórym standardowym operacjom zachować zgodność w dowolnej serii. platform obsługujących standardową bibliotekę C. Każda platforma będzie miała własną implementację biblioteki C opartej na wewnętrznie wewnętrznych wywołaniach systemowych.
Cóż, ostatecznie oba zostaną zaimplementowane pod kątem funkcji jądra, która wywołuje sterownik, który z kolei wykonuje całą magię, uzyskując uchwyt pliku. Jeśli fopen zadzwoni do OpenFile lub jeśli OpenFile wywoła fopen lub żadne z tych połączeń, to nie jest to coś, o czym nie wiesz, nie patrząc na kod źródłowy (a różne implementacje mogą go inaczej zaimplementować ...).
OpenFile to stara funkcja, której nikt nie używa, jestem pewien, że wszystkie implementacje CRT używają CreateFile – Anders
Dokładniej, 'OpenFile' jest 16-bitową funkcją Windows; 'CreateFile' został przeciążony, aby zrobić o wiele więcej rzeczy niż tworzenie pliku w 32-bitowym systemie Windows. Ale jest bardzo prawdopodobne, że 'CreateFile' * jest * funkcją jądra (nie mówiąc, że nie ma funkcji pomocniczych niższego poziomu, nieeksponowanych). Jest to udokumentowany eksport z 'kernel32.dll'. –
Nie ma "biblioteki C", która jest częścią systemu Windows. Każdy kompilator wysyła własne. Wszystkie biblioteki C mogą korzystać z interfejsu API systemu Windows (który * jest * częścią systemu Windows), a interfejs API systemu Windows korzysta z jądra systemu Windows. Możesz również użyć jądra systemu Windows bezpośrednio, ale jest nieudokumentowane i nie jest stabilne (jego API, to znaczy nie samo jądro). –
Całkiem oczywiście biblioteka standardowa C jest implementowana na szczycie Win32 API, a nie na odwrót. Można to odjąć od obecności co najmniej pół tuzina różnych implementacji biblioteki std C (z których niektóre są funkcjami open source i wywołującymi Win32). – Damon
* Części * jądra systemu Windows są nieudokumentowane i nieudokumentowane z jakiegoś powodu - nie zamierza się ich używać, ponieważ mogą się zmienić w dowolnym momencie! Inne części jądra Windows, ogólnie wyeksportowane funkcje z 'kernel32.dll', są dość dobrze udokumentowane i przeznaczone do ogólnego użytku. Punkt Damona jest dokładnie poprawny - możesz napisać własną bibliotekę wykonawczą C, tak jak zrobiła to Microsoft, używając funkcji Windows. Windows API * ma * być niższym poziomem, ponieważ Windows jest systemem operacyjnym. To samo dotyczy innych środowisk: CRT wywołuje system operacyjny lub przerwań systemu niższego poziomu. –