No czemu? Czemu .NETowa DLLka to nie DLLka? ;-)

Mam pretensje do Microsoftu ;-) Poczamu nie zrobili tak by DLL generowane z .NET były zwykłymi DDLkami? (chodzi mi o takie generowane z C#)
Wydaje się, że nie powinno to być trudne. Pierwszą instrukcją w takiej funkcji wołanej w DLL powinien być call do podprogramu, który sprawdzałby czy jest w .NET czy poza, gdyby był poza to sprawdzałby czy odpalony jest .NET, jeśli nie to by go uruchamiał i stawiałby "most" miedzy sobą, a .NETem tak by wywoływać odpowiednie procedury (czyli .NET by ładował tą bibliotekę ponownie i robił swoją część roboty).
Wtedy wołanie z .NET polegałoby na call, następnie robiłby się call do procedury sprawdzającej czy jest wykonywane przez .NET, jeśli tak to by robiło ret, za tym call były kod, który po prostu cośby "zaświecał" ;-) i robił ret, a .NET już by sobie resztę kodu za tym wykonywał po swojemu.
Mieliby dość dużą interoperacyjność przy niskich kosztach.
Z tego co mi po głowie chodzi coś takiego jest robione w niektórych KVM (Kilobyte Virtual Machine, czyli maszynach wirtualnych Java'y dla J2ME dostarczanych przez producentów komórek), głowy nie dam, ale jeśli to jest opatentowane to patent ma Google po ostatnich zakupach ;-)

Teraz to i tak jest już po truskawkach, bo to draństwo (czyli .NET) ma około miliona lat...

Zresztą ciekawa sprawa, jeszcze .NET 2.0 było w stanie produkować DLLki, które mogły robić w IE za OCXy, ale później z tego zrezygnowali. Ciekawe czemu.
Teraz by zrobić np. wtyczkę do Total Commandera przy pomocy C# trzeba robić jej wrapper w C++ i cudować, albo bawić się w obiekty COM.

Rozumiem, że problem mógłby być z GC. Bo byłby problem z tym jak zarządzać obiektami, które byłyby zwracane z DLLki, ale wydaje się, że można by je było w odpowiednim miejscu pamięci umieszczać i zakładać, że będą nieosiągalne dla GC i tyle. To mógłby być problem, ale z drugiej strony można by przyjąć, że taka DLLka zwracałaby kopię obiektu... OK, tu przyznam, że za mało wiem jak Windows wewnętrzne realizuje DLLki, jak wygląda problem z dostępem do ich zmiennych i podobne, ale z racji tego, że to Microsoft stworzył DLLki to pewnie mieliby parę sztuczek do tego by uniknąć wycieków pamięci przy jednoczesnym "unatywnieniu" DLLek z C#...

Fajnie by było jakby tak mogli (bez cudowania), byłaby jakaś zaleta ;-)


Podobne posty^beta
A gdyby tak JNI bez JNI? ;-)
Potworność ;-) czyli mnożenie w 90 liniach ;-)
Plug-in master ;-)
Chrome2Chrome - pożeracz transferu ;-)
Ha! Ochidna Echidna potrafi updatować pliki :-)