Re: Platforma NET Framework 1.1

W wiadomości: cams3g$uae$1@polsl.gliwice.pl,
Radosław Sokół <Radoslaw.Sokol@polsl.pl> napisał(a):
> Marek Janaszewski /USUN_TO. z adresu!/ wrote:
>> [...]
>> Nie wiem na czym polega to poruszenie programistów Win32 API
>> związane z .NET-tem. Same głosy rozpaczy z związane z powstanie
>> nowego API: WinFX.
>
> Po pierwsze, Win32 jest na idealnym poziomie dzięki temu, że
> korzysta z niezwykle prostego modelu. Są to po prostu funkcje
> wołane wedle określonej konwencji i dzięki temu można z nich
> bezpośrednio korzystać w programach pisanych w czystym asem-
> blerze, C, C++, Pascalu czy C#. Idealny uniwersalizm. Nowy
> interfejs też powinien być tak uniwersalny, zamiast preferować
> tylko C# i ewentualnie C++. Efektywniej jest opakować prosty
> interfejs na potrzeby zaawansowanego języka programowania niż
> odwoływać się do obiektowego API z poziomu asemblera.

Witam!

Aktualnie sytuacja z .NET Firmework tak wygląda, odwołuje się do Win32 API.
Ale granice są dosyć płynne, nie są to proste opakowania bo dostarczają
znaczącej funkcjonalności więc zawsze będzie pokusa aby mieć dostęp do tych
dobroci. Coraz więcej kodu jest zarządzanego. Ale to będzie problem zawsze,
np. jeśli jest dostępny obiekt COM albo usługa web, którą chce wywołać nie
należy liczyć, że w językach niskiego poziomu jest możliwość łatwego
wywołania. Z drugiej strony tworzenie wszystkie pod języki niskiego poziomu
powoduje nienaturalność wywołania tego pod językami wysokiego poziomu. Stąd
konieczność tworzenia owijek i pośrednich interfejsów. No jesteśmy w punkcie
wyjścia jeśli te owijki dostarczają dodatkową funkcjonalność.

Oprócz tych problemów, które jak mi się wydaje powstają jest jeszcze problem
z bezpieczeństwem i kodem zarządzanym. Nie jestem purystą pod tym względem,
że wszystko musi 100% w kodzie zarządzanym. Ale póki będą istnieć różne
środowiska będą istnieć bariery między nimi. A te różnice muszą istnieć bo
by nie było celu tworzyć nowego środowiska.

Ty może tego nie czujesz bo pewno programujesz C++, ale ja generalnie
programuje w Pascalu/Delphi i naprawdę widzę jak Win32 API "zajeżdża"
właśnie C. Także nie widzę, nic zdrożnego w fakcie, że bardziej naturalnie
będzie można np. przekazać wynik funkcji jako string. Ten system okazywał
się nie do utrzymania, dlatego powstało COM a później .NET. A .NET nie jest
pisany tylko dla C#, jest to język to tylko język, który powstał dla tej
platformy. .NET jest wyznacza standardy. Jakieś ten standardy muszą być, aby
kawałki kodu mogły się między sobą dogadać.

Inny argument jest taki, że jak SWING w Javie nikt z tego powodu nie
załamywał rąk. Ponieważ w Javie ważna jest przenośność był to oczekiwany
krok przez programistów Javy. Także nic dziwnego, że platforma posiada
własny kod i nikt tego jej nie może zabronić. Możemy się jedynie sprzeciwiać
polityce jaką prowadzi Microsoft, że inwestuje w platformę .NET. Osobiście
uważam, że nie jest głupim argumentem aby stworzyć platformę skierowaną na
ułatwienia w tworzeniu oprogramowania.

Wydaje mi się, że te kilka akapitów można podsumować tak:
1. Nie wszystko musi i może być wystawione jako Win32 API. Bariery zawsze
występuje.
2. Są istotne argumenty jeśli chodzi o bezpieczeństwo kodu zarządzanego.
3. Win32 API posiada specyfikę C i wcale nie jest uniwersalnym rozwiązaniem.
4. Platforma może posiada własny kod. Jeśli komuś się to nie podoba niech
napisze go dla platformy jaką chce.

> Po drugie, zmiana interfejsu API jest dość odważnym krokiem,
> gdyż programiści generalnie nie lubią uczyć się czegoś zupeł-
> nie nowego. Pięknie opisał to Charles Petzold w artykule o
> OS/2 w jednym ze starych PC Magazine: według niego IBM sam
> zabił OS/2, gdyż wymusił na MS przygotowanie nowego API,
> podobnego do Win16, a jednak różnego w detalach. I choć
> efektem było wyjątkowo eleganckie, czyste API, łączące
> najlepsze elementy API UNIXów i Windows, to w rezultacie
> mało kto się go uczył, a portowanie programów było utrudnione.

A jednak czasem trzeba przeprowadzić dokonać pewnych zmiana zamiast podążać
krokami drobnych ulepszeń. Ten sam argument można dać w stosunku do DOS-a i
Windows, to samo C i C++. Do dzisiaj tworzysz się aplikacje pod DOS w
Clipperze i sprzedaje jako nowoczesne. Nikt tego nie zabrania.

Pytanie czy to jest odpowiedni moment. Ja tego nie wiem. Myślę, że jest to
ryzyko Microsoft. Przekonamy się w przyszłości czy miałeś racje wieszcząc
klęskę .NET Framework.

> Ja widzę całe .NET i WinFX bardziej jako warstwę pośredniczącą
> między prawdziwym API (które musi opierać się o proste wywo-
> łania przerwania systemowego wraz z parametrami) a aplikacjami.
> I moja "dusza programistyczna" mocno protestuje przeciwko nazy-
> waniu tego "nowym API", a nie "sugerowaną biblioteką".
[...]

O WinFX i Longhornie nie wiadomo wszystkie. Jak się pojawi to pewno dopiero
wtedy wiele rzeczy się okaże i zostanie sprawdzone. Jak będzie ze
sterownikami to nie mam pojęcia. Natomiast mówi się o tym, że WinFX nie
będzie już nakładką na Win32 API tylko następcą tego API. Ze ględu na
wydajność i być może bezpieczeństwo ma dokonywać bezpośrednich wywołań jądra
systemu. Także wiele kodu jest przepisywane od nowa, zatem aby zapewnić
jakoś aktualnemu Framerkowi nie posiada on jeszcze wszystkich elementów.
Dlatego zbliża się premiera wersji drugiej, w tym ADO.NET 2.0, ASP.NET 2.0,
które to komponenty są kontumacją rozwoju platformy.

Microsoft pewno podjął decyzje aby pójść w kierunku .NET aby ułatwić
powstawania większej ilości oprogramowania. Widocznie sposoby pracy znane z
Win32 API i C++ temu nie sprzyjały. Czy to się przyjmie to inna sprawa.

Coś w tym musi być skoro nie istniała tylko Visual C++, ale był i
VisualBasci, Delphi. Gdyby Visual C++ i Win32 API było takie cudowne i
uniwersalne do tworzenia programów nie powstało by wiele alternatywnych
rozwiązań.

-- 
Pozdrawiam,
Marek Janaszewski
[ j_marek@gazeta.pl ]