W przypadku * nix odkryłem, że The Art Of Unix Programming Erica Raymonda dość dobrze wyraził idee stojące za filozofią Uniksa. Cała książka jest online, polecam ten rozdział, aby zobaczyć, o czym mówię. Zasadniczo przedstawia koncepcje unifikacji systemów operacyjnych Unix i ich aplikacji. Na przykład:
- Reguła modułowości: pisz proste części połączone czystymi interfejsami.
- Zasada przejrzystości: projekt zapewniający widoczność, aby ułatwić inspekcję i debugowanie.
Następnie opisuje sposób zastosowania tych zasad.
Co składa się na filozofię systemu Windows?
Nigdy tak naprawdę nie zrozumiałem filozofii systemów operacyjnych Windows i nigdy tak naprawdę nie znałem nikogo, kto wie wystarczająco dużo, aby odpowiedzieć na pytanie. Googlowanie tego dla mnie po prostu wywołuje kilka rantów. Czy istnieje odpowiednik książki lub zestawu artykułów do The Art Of Unix Programming, ale dla systemów operacyjnych Windows?
Byłbym również zainteresowany, gdyby ktoś pomyślał, że ma dobrą odpowiedź, ale może to być zbyt długi post.
Odpowiedzi:
Zobacz kanał 9 MSDN. Dostajesz niesamowicie dużo miejsca na miejscu, co inżynierowie Microsoftu zamierzali / uzasadnili na temat określonego projektu lub funkcji.
W systemie Windows: Moim absolutnym faworytem jest blog wideo Dave'a Proberta na temat jądra systemu Windows (z pewnymi uwagami na temat różnic w stosunku do Uniksa): http://channel9.msdn.com/shows/Going+Deep/Windows-Part-I-Dave- Probert / .... i druga część 2-4 .... (możesz także spojrzeć na inne filmy „Going Deep” :-).
Baw się dobrze.
HTH, Thomas
PS: Dodatkowo bardzo dużo informacji znajduje się w książkach „Inside Windows NT”, pierwsza edycja była dość niezwykła ze względu na zrozumienie wewnętrznych zasad działania systemu Windows NT.
źródło
Unix, od „potoku” w górę, jest zaprojektowany wokół procesów komunikujących się w protokołach zwykłego tekstu. Stąd projektowanie różnych protokołów internetowych - SMTP, HTTP, IMAP, POP itp. Są czytelne dla człowieka. Dlatego programiści muszą pisać kod piszący i analizujący protokół, ale często łatwo jest współpracować z programami, których nie kontrolujesz.
System Windows jest natomiast zbudowany wokół wywołania procedury / wywołania metody. COM i następcy zapewniają sposoby rozszerzenia wywołań procedur na biblioteki DLL, między wątkami procesu, procesami i siecią. Wszystko to jest dość przejrzyste, szczególnie w językach zorientowanych obiektowo. Ułatwia to pisanie bardzo dużych aplikacji sieciowych - o ile kontrolujesz wszystkie komponenty. Utrudnia to zamianę części złożonego połączonego systemu na nowy fragment kodu. Na przykład format pliku Microsoft Word jest bardzo dziwny jako format pliku, ale prosty jako reprezentacja obiektów w pamięci używanych przez Word. Protokół Exchange wire to MAPI-over-DCOM: z punktu widzenia deweloperów programu Outlook wystarczy, aby uzyskać na nim obiekt skrzynki pocztowej i metody wywoływania,
źródło
Blog Raymonda Chena ( http://blogs.msdn.com/oldnewthing/ ) jest fantastycznym źródłem tego rodzaju informacji, a także zawiera nieprzyzwoite szczegóły na temat tego, dlaczego niektóre rzeczy są takie, jakie są w systemie Windows (przykład : dlaczego musisz kliknąć przycisk Start, aby zamknąć? Ponieważ podczas testowania, kiedy użytkownicy zostali poproszeni o wyłączenie komputerów, kliknęli).
źródło
Myślę, że można poczuć różnicę w systemach, patrząc na menu Start systemu Windows i porównując je z menu Start KDE lub Gnome. Menu * NIX są uporządkowane według zadań lub kategorii, podczas gdy menu systemu Windows są organizowane przez firmę programistyczną. To wiele mówi o różnicach w priorytetach twórców.
(Tak, tak, KDE / Gnome nie są „filozofią UNIX”, ale wciąż jest uderzającą różnicą).
źródło