Dlaczego WinRT jest niezarządzany? [Zamknięte]

164

Windows 8 wprowadza WinRT, który jest podobny do .NET, ale niezarządzany. Dlaczego jest niezarządzany? Czy to problem z wydajnością? Czy to oznacza, że wyrzucanie elementów bezużytecznych nie jest odpowiednie dla interfejsów API niższego poziomu?

c# .net windows-8 windows-runtime

— user380719
źródło

To był zły telefon , tak samo zły jak jego zamknięcie. Teraz nalegasz na odniesienia i źródła, przerwałeś to wcześniej, zamykając pytanie. Teraz usunąłeś doskonałe źródła od programistów, którzy nad tym pracowali.

— Hans Passant

Głosowałem poza tematem, ponieważ nie dotyczy to praktycznej kwestii programowania. To tylko ciekawość. Żaden programista nie zmieni swojego kodu w wyniku tego pytania.

— Raymond Chen

@Kev Z tego powodu pytania typu „jak powstała planeta Ziemia?” byłby absolutnie okropny w społeczności naukowej, ponieważ przyciągnął wiele religijnych spekulacji. Są dobre odpowiedzi na to pytanie - tylko dlatego, że przyciąga wiele złych odpowiedzi, nie oznacza, że jest to złe pytanie. Ale naprawdę, czemu po prostu nie przenieść tego pytania do P.SE?

— Rei Miyasaka

@casperOne To uzasadnione pytanie „tablicy” dla wielu programistów - chcemy poznać przypuszczalnie techniczne powody takiej decyzji, abyśmy mogli zastosować to samo rozumowanie gdzie indziej. Czy to dlatego, że odśmiecacz jest trudny do profilowania? Czy to dlatego, że zapewnia łatwiejszy dostęp do abstrakcji sprzętowych niższego poziomu? Jeśli nie ma powodów technicznych, jest to po prostu niefortunne - ale nie ma to nic wspólnego z jakością samego pytania.

— Rei Miyasaka

Zgadzam się z @HansPassant; to pytanie należy ponownie otworzyć i potraktować jako ważne. „Dlaczego jest to niezarządzane?” to bardzo dobre pytanie w odniesieniu do podstaw WinRT.

— Rob Perkins,

Odpowiedzi:

190

WinRT jest zamiennikiem starego Winapi opartego na C. Jest to interfejs API, który musi być użyteczny w wielu środowiskach wykonawczych. 20 lat temu współdziałanie z interfejsem API C było stosunkowo łatwe. To się zmieniło od tego czasu, COM stał się uniwersalnym klejem w drugiej połowie lat 90. Praktycznie każde środowisko uruchomieniowe języka, które jest powszechnie używane w systemie Windows, obsługuje model COM.

Moduł odśmiecania pamięci to szczegół implementacji języka uruchomieniowego. Na przykład moduł zbierający dla platformy .NET bardzo różni się od modułu zbierającego dla języka JavaScript. Obiekty natywne utworzone w obu muszą przestrzegać bardzo ścisłych zasad kolekcjonera. Co z kolei oznacza, że musieliby tworzyć wersje WinRT, które są specyficzne dla każdego środowiska uruchomieniowego języka. To nie wystarczy, nawet firma tak duża jak Microsoft nie może sobie pozwolić na stworzenie i obsługę określonej wersji WinRT dla każdego powiązania językowego. Nie jest też konieczne, biorąc pod uwagę, że języki te już obsługują COM.

Obecnie najlepszym powiązaniem dla WinRT jest C ++, ponieważ model COM działa wydajniej z jawnym zarządzaniem pamięcią. Z dużą pomocą nowych rozszerzeń kompilatora C ++, które czynią go automatycznym, bardzo podobnym do starego _com_ptr_t ze składnią podobną do C ++ / CLI, aby tego uniknąć. Powiązanie z językami zarządzanymi jest stosunkowo proste, ponieważ środowisko CLR ma już doskonałą obsługę międzyoperacyjną COM. WinRT przyjął również format metadanych .NET. Ahaik, na dzień dzisiejszy nie wykonano żadnej pracy nad zarządzanymi kompilatorami.

EDYCJA: Larry Osterman, znany programista i bloger firmy Microsoft, zostawił dość dobry komentarz w usuniętej odpowiedzi. Zacytuję to tutaj, aby go zachować:

WinRT jest niezarządzany, ponieważ system operacyjny jest niezarządzany. Projektując WinRT tak, jak został zaprojektowany, zyskuje możliwość wyrażania się w wielu różnych językach, nie tylko w C ++, C # i JS. Na przykład z łatwością mogłem zobaczyć zestaw modułów Perla, które implementują API WinRT, które działają na pulpicie. Gdybyśmy zaimplementowali to w .Net, byłoby to niezwykle trudne

— Hans Passant
źródło

Nie wiem o kompilatorach, ale jestem prawie pewien, że projekcja WinRT .NET wymagała dużo pracy na CLR. Mogli ponownie wykorzystać kod COM Interop, ale są również różnice (np. Pozwalają IInspectablena wykonywanie takich rzeczy, jak zapytanie obiektu o jego rzeczywisty typ klasy lub listę wszystkich obsługiwanych interfejsów, a z plikami winmd można rzutować metadane WinRT dla tego wszystkiego do Reflection ). Pliki winmd nie nadają się do natychmiastowego użycia jako zespoły międzyoperacyjne, CLR musi je specjalnie obsługiwać.

— Pavel Minaev

Nie jestem pewien, ignorujesz słonia. Inspectable jest zamiennikiem IDispatcha, który utknął w 1997 roku. Pracujesz dla Microsoftu, możesz zdradzić tutaj niektóre sekrety :)

— Hans Passant

Wykonano prace we wszystkich 3 językach, aby wspierać projekcje językowe.

— Przywróć Monikę Larry Osterman

Twierdzę, że w tej chwili „najlepszym powiązaniem dla WinRT” jest właściwie C #. Powiązanie CLR jest zoptymalizowane nawet poza dość szybką interopcją COM, a języki .NET w wersji zapoznawczej dewelopera już implementują doskonałą obsługę wszechobecnych funkcji asynchronicznych z „await”. W kilku pokazach kod C # zrobił dużo więcej niż przykłady C ++ i działał łatwiej. Może później C ++ otrzyma rozszerzenie pomocnika asynchronicznego, ale w tej wersji C ++ async wyglądało okropnie. I jest mniej prawdopodobne, że wycieknie pamięć długoterminowa z CLR zbierającego elementy bezużyteczne niż implementacja C ++ z problemami cyklicznymi. C # FTW!

— Govert

@Hans: Trzecia projekcja to CLR dla wszystkich języków CLR (głównie C # i VB). Również WinJS nie jest projekcją, to zestaw bibliotek pomocniczych. Projekcja jest bezpośrednio wbudowana w silnik Chakra JS.

— Przywróć Monikę Larry Osterman

WinRT jest niezarządzany, ponieważ ma być zamiennikiem Win32 - najniższego poziomu dostępnego dla programistów API dla Windows. Niezarządzany interfejs API jest nadal najbardziej potencjalnie wydajnym interfejsem, który może zostać ujawniony deweloperowi, a rozumowanie jest takie, że zawsze będzie można umieścić na nim zarządzany interfejs API, co jest dokładnie tym, co robią „projekcje”.

Oznacza to również, że programiści C ++ mogą używać WinRT bez przeskakiwania przez obręcze, które wprowadza C ++ / CLI (patrz http://www2.research.att.com/~bs/bs_faq.html#CppCLI ). Oznacza to jednak, że nadal będziesz musisz studiować COM, jeśli chcesz korzystać z WinRT.

Prawdziwe pytanie brzmi: „dlaczego COM jest konieczny? dlaczego Microsoft musiał to wymyślić? Ponieważ zwykły C ++ bez wszystkich dodatkowych udogodnień COM jest nieadekwatny do prawdziwej pracy OOP, a twierdzenia Stroustrupa o C ++ zapewniającym „przenośność” są bardzo nieszczere w świetle rzeczywistości roboczej. Zobacz http://webmechs.com/webpress/2011/11/c-versus-objective-c-as-api-substrate/

— Andz
źródło

Zaktualizowany link do przemyśleń Bjarne'a na temat C ++ / CLI: stroustrup.com/bs_faq.html#CppCLI