Aby utworzyć na dysku plik, można użyć jednej z sześciu funkcji Windows, której towarzyszą dodatkowe funkcje do zapisu plików. Co gorsza, nie ma jednej odpowiedzi, który sposób tworzenia pliku jest właściwy - każdy ma wady i zalety.

W przypadku Javy dochodzi jeszcze konieczność ujednolicania różnych architektur sprzętowych i systemów operacyjnych. Obszerny interfejs API Javy powstał jako pewnego rodzaju kompromis. Jeśli czegoś nie może wykonać bazowy system operacyjny, symuluje to maszyna wirtualna. Problem pojawił się w przypadku wymiany informacji w drugą stronę: gdy program napisany w Javie miał korzystać z niestandardowych możliwości systemu. Sun rozwiązał to opracowując interfejs JNI, który pozwala odwoływać się do niestandardowych interfejsów API bazowej platformy czy biblioteki. JNI jest dostosowany do jednego języka - C. Należy podkreślić, że wiele serwerów aplikacyjnych implementuje dodatkowe mechanizmy współpracy z komponentami np. Borland AppServer i VisiBroker pozwalają na połączenie składników COM, J2EE i CORBA.

Opublikowany na początku br. .Net Framework jest pierwszą, kompleksową biblioteką standardową na platformie Windows. Obejmuje olbrzymi zakres API: funkcje biblioteczne Win32, standardowe komponenty COM, usługi serwisowe Windows i elementy spotykane w bibliotekach VB czy C++.

W .Net również pozostawiono "furtkę" do wywołań API bazowego systemu operacyjnego. PInvoke bardzo przypomina interfejs JNI, zawiera jednak mechanizm wspierania rozrządu (marshaling) i przy pewnych zabiegach pozwala na wywoływanie klas napisanych w C++.

W .Net dostępne są mechanizmy do współpracy z COM. Istnieje odpowiedni zestaw typów i usługi pozwalające odwoływać się z poziomu .Net do komponentów COM, tak jakby były to rodzime komponenty .Net (są tworzone specjalne klasy "szkieletu"). Funkcjonalność jest realizowana za pośrednictwem odwołań do bazowego komponentu COM. Mechanizm ten jest wykorzystywany w wielu klasach .Net.

Trzeba jednak liczyć się z tym, że nie każdy komponent COM będzie działał na platformie .Net. Nie można uruchomić komponentów wizualnych typu windowless. Niektóre odwołania do interfejsu IDispatch czy parametrów/właściwości bez ściśle określonego typu będą wymagały pisania własnych klas pośredniczących (.Net wymaga w wielu miejscach silnej kontroli typów). Komponent lub klasa .Net może być również "opakowana" w interfejs COM. Paradoksalnie, zazwyczaj to znacznie prostsze niż przystosowanie obiektów COM, by pracowały w środowisku .Net.

Procedury tworzenia bibliotek Javy i .Net. są całkowicie odmienne. W przypadku Javy mamy do czynienia ze swoistym komitetem, który tworzą producenci serwerów aplikacyjnych i innych elementów platformy J2EE. Ostateczne, "oficjalne" API jest wynikiem kompromisu zawieranego między wieloma producentami oprogramowania. Twórcy Javy nie muszą zachowywać zgodności ze starszymi API - jednak nawet w obrębie samej Javy można znaleźć pewną liczbę interfejsów, które były dostępne w 1.1x a w 1.2x (czy 2.x) zostały zmienione bądź wycofane. Jedynymi mechanizmami zgodności ze starszą technologią są interfejsy do modelu komponentowego CORBA.

.Net zostało tak skonstruowane, by programista znający główne interfejsy najpopularniejszych obiektów COM czy semantykę API mógł dość szybko poruszać się w nowym środowisku.