DCOM95 1.3 Informacje o wersji Ostatnia modyfikacja: 14 Września, 1998 Protokół połączeniowy DCOM95 zapewnia obsługę modelu obiektów rozproszonych COM (DCOM) dla systemu Microsoft(r) Windows(r) 95. Protokół DCOM w przezroczysty dla użytkownika sposób zapewnia obsługę pewnej, bezpiecznej i skutecznej komunikacji pomiędzy składnikami COM (Component Object Model), takimi jak formanty ActiveX(r), skrypty, i aplety Java języka rezydującymi na różnych komputerach w sieci lokalnej (LAN), sieci rozległej (WAN) lub w Internecie. Wykorzystując DCOM, aplikacja może być rozdzielona pomiędzy różne miejsca, zgodnie z oczekiwaniami klienta i wymogami zastosowania. Więcej szczegółowych informacji można znaleźć w przeglądzie technicznym DCOM dostępnym na stronie głównej Microsoft COM, pod adresem http://www.microsoft.com/com/. Spis treści =========== I. Nowe cechy II. Naprawione błędy III. Znane problemy IV. Różnice w stosunku do protokołu DCOM systemu Windows NT V. Redystrybucja VI. Pomoc techniczna i zasoby VII. Lista plików I. Nowe cechy --------------- Niedozwolone jest zastępowanie DCOM95 starszą wersją W poprzednich wersjach DCOM95, istniała możliwość zastąpienia nowszej wersji DCOM95 starszą wersją. Numery wersji są aktualnie sprawdzane podczas instalacji, i nie jest dozwolone instalowanie starszej wersji na nowszej. Zmiana ta pozwoli uniknąć problemów z niezgodnymi wersjami bibliotek DLL. Obsługa monitorowania procesów Visual Studio 6.0 W obsłudze Visual Studio 6.0, DCOM95 zapewniono monitorowanie informacji dla deweloperów, aby pomóc im zrozumieć zachowanie, wydajność i strukturę aplikacji. Używając analizatora Visual Studio Analyzer na komputerze z systemem Windows 95, należy zawsze używać tej wersji DCOM95. Nowe katalogi tworzone przez Instalatora Instalator tworzy katalog o nazwie DCOM95 w katalogu systemowym. Jest w nim zapisywana licencja użytkownika oprogramowania i inne pliki. Instalator tworzy także podkatalog katalogu DCOM95 o nazwie OLDOLE, w którym są zapisywane stare wersje plików DCOM95 lub OLE. Pliki te są przywracane w trakcie późniejszego odinstalowywania DCOM95. Internetowe usługi COM Usługi COM Internet Services (CIS) umożliwiają klientom i serwerom łączenie się poprzez Internet przy wykorzystaniu COM. Usługi CIS składają się z * Nowego protokołu DCOM, tunelowanego TCP * Nowego typu monikera, moniker OBJREF * Nowego narzędzia CISCNFG Dla obsługi klientów CIS w Windows 95, trzeba zainstalować zarówno DCOM95 jak i DCOMCFG. A następnie wykorzystać narzędzie CISCNFG, instalowane podczas instalacji narzędzia konfiguracyjnego DCOM, do zmiany klucza rejestrów określającego, który protokół jest używany dla procesów zdalnych. W oknie wiersza poleceń wpisz: ciscnfg Gdzie to: * rpc, aby użyć protokołu RPC * http, aby użyć protokołu HTTP * tcp_http, aby spróbować użyć najpierw protokołu TCP, a po wyczerpaniu limitu czasu serwera, ponowić próbę używając protokołu HTTP. Polecenie ciscnfg nie ma argumentu wyświetlającego informacje dotyczące użytkowania tego narzędzia. Nie są wymagane aktualizacje SDK umożliwiające używanie tunelowanego protokołu TCP. W tej wersji wprowadzono kilka aktualizacji dla monikerów OBJREF. CreateObjrefMoniker Tworzy moniker OBJREF w oparciu o wskaźnik do obiektu. WINOLEAPI CreateObjrefMoniker( LPUNKNOWN pUnk, //Wskaźnik do obiektu LPMONIKER *ppMk //Adres wskaźnika monikera OBJREF ); Parametry pUnk Wskazuje interfejs IUnknown w obiekcie, który ma być reprezentowany przez moniker. ppMk Adres wskaźnika do interfejsu IMoniker tworzonego monikera OBJREF. Zwracane wartości Funkcja obsługuje standardowe wartości zwracane E_OUTOFMEMORY i E_UNEXPECTED, jak również następujące: S_OK Moniker OBJREF został pomyślnie utworzony. Uwagi Klienci wykorzystują monikery OBJREF do uzyskania międzyprocesowego wskaźnika do działającego obiektu w przestrzeni adresowej serwera. Zazwyczaj serwer wywołuje metodę CreateObjrefMoniker aby utworzyć moniker OBJREF a następnie wywołuje metodę IMoniker::GetDisplayName, i ostatecznie uwalnia moniker. Nazwa wyświetlana monikera OBJREF ma postać: OBJREF:nnnnnnnn Gdzie nnnnnnnn jest nadawanym arbitralnie ciągiem kodowanym 64 pozycyjnie, zawierającym położenie komputera, punkt końcowy procesu, i identyfikator wskaźnika interfejsu (IPID) działającego obiektu. Nazwa wyświetlana może być przesłana do klienta jako tekst. Na przykład, nazwa wyświetlana może występować na stronie HTML pobieranej przez klienta. Klient może przekazać nazwę wyświetlaną do metody MkParseDisplayName, która tworzy moniker OBJREF w oparciu o nazwę wyświetlaną. Wywołanie później metody monikera IMoniker::BindToObject pozwala otrzymać międzyprocesowy wskaźnik do działającego obiektu na serwerze. Na przykład, składnik COM znajdujący się na serwerze na aktywnej stronie serwera może utworzyć moniker OBJREF, uzyskać jego nazwę wyświetlaną i zapisać nazwę wyświetlaną w wyjściowym pliku HTML wysyłanym do przeglądarki klienta. Skrypt wykonywany po stronie klienta może użyć nazwy wyświetlanej, aby uzyskać dostęp do działającego obiektu. Na przykład skrypt Visual Basic wykonywany po stronie klienta może zapisać nazwę wyświetlaną w zmiennej MojaNazwa i zawierać wiersz: MojeWystąpienie = GetObject(MojaNazwa) Aparat skryptów wykonuje wewnętrzne wywołanie metod MkParseDisplayName i IMoniker::BindToObject, a następnie skrypt może wykorzystać obiekt MojeWystąpienie, aby odwoływać się bezpośrednio do działającego obiektu. Jeśli działający obiekt używa statycznego IPID, a proces serwera zawsze działa na tym samym komputerze jako dobrze znany punkt końcowy, nazwa wyświetlana jest zawsze taka sama. W takim przypadku, serwer może zachować nazwę wyświetlaną zamiast obliczać ją zawsze, gdy odbiera wywołanie obiektu. IMoniker - Implementacja monikera OBJREF Moniker OBJREF reprezentuje odniesienie do wystąpienia obiektu działającego na poza procesowym serwerze, zarówno lokalnym jak i zdalnym. Moniker określa wystąpienie obiektu i komputer, na którym działa obiekt. Miniker OBJREF jest podobny pod wieloma względami do monikera wskaźnika, z wyjątkiem tego, że działające obiekty są poza procesowe. Klient może wywołać metodę IMoniker::BindToObject monikera OBJREF moniker i użyć uzyskanego wskaźnika, aby uzyskać dostęp do działającego obiektu, zamiast jego położenia. Ważną różnicą w stosunku do monikera wskaźnika jest to że nazwa wyświetlana monikera OBJREF może być osadzona na stronie HTML i działający obiekt reprezentowany przez moniker może być związany przez skrypt klienta, aplet lub formant ActiveX. Kiedy używać Podstawowym wykorzystaniem dla monikerów OBJREF jest uzyskiwanie dostępu do wystąpień działających obiektów poprzez Internet. Aktywna strona serwera lub inny pośrednik generujący dynamicznie zawartość HTML umieszcza nazwę wyświetlana monikera OBJREF jako parametr dla apletu lub formantu ActiveX. Kod apletu lub formantu wywołuje metodę CreateObjrefMoniker, aby utworzyć moniker OBJREF w oparciu o nazwę wyświetlaną, a następnie wywołuje metodę IMoniker::BindToObject na wynikowym monikerze OBJREF, aby uzyskać dostęp do wystąpienia działającego obiektu. Aktywna strona serwera przekazuje międzyprocesowo wskaźnik do działającego obiektu z powrotem do klienta strony. Uwagi IMoniker::BindToObject. Dla monikerów OBJREF, parametr pmkToLeft musi mieć wartość NULL. Ponieważ moniker OBJREF reprezentuje działający obiekt, proces aktywacji nie występuje. Jeśli reprezentowany obiekt nie działa, wywołanie BindToObject zwraca kod niepowodzenia E_UNEXPECTED. IMoniker::BindToStorage. Metoda uzyskuje międzyprocesowy wskaźnik do wymaganego interfejsu w pamięci zawierającej działający obiekt. Ponieważ moniker OBJREF reprezentuje działający obiekt, proces aktywacji nie występuje. Jeśli reprezentowany obiekt nie działa, wywołanie BindToStorage zwraca kod niepowodzenia E_UNEXPECTED. IMoniker::Reduce. Metoda zwraca wartość MK_S_REDUCED_TO_SELF i przekazuje z powrotem ten sam moniker. IMoniker::ComposeWith. Jeśli pmkRight jest anty-monikerem, zwracany moniker ma wartość NULL. Jeśli pmkRight jest złożeniem, którego lewym, skrajnym składnikiem jest anty-moniker, zwracany moniker jest złożeniem z usuniętym lewym skrajnym anty-monikerem. Jeśli pmkRight nie jest anty-monikerem ani złożeniem, którego lewym skrajnym składnikiem jest moniker, metoda sprawdza wartość parametru fOnlyIfNotGeneric. Jeśli jest to FAŁSZ, metoda łączy oba monikery w uniwersalne złożenie; jeśli jest to PRAWDA, metoda ustawia wartość *ppmkComposite na NULL i zwraca wartość MK_E_NEEDGENERIC. IMoniker::Enum. Metoda zwraca wartość S_OK i ustawia wartość ppenumMoniker na NULL. IMoniker::IsEqual. Metoda zwraca wartość S_OK, jeśli *pmkOther jest monikerem OBJREF i ścieżka dla obu monikerów jest identyczna (wykonywane jest porównanie bez uwzględniania wielkości liter). W przeciwnym wypadku metoda zwraca wartość S_FALSE. IMoniker::Hash. Metoda oblicza wartość # dla monikera. IMoniker::IsRunning. Ponieważ moniker OBJREF reprezentuje wystąpienie działającego obiektu, metoda zwraca wartość PRAWDA, chyba że obiekt jest znany jako niedziałający, ponieważ nie powiodło się ostatnie wywołanie. Metoda ignoruje parametr pmkToLeft. IMoniker::GetTimeOfLastChange. Metoda zwraca wartość E_NOTIMPL. IMoniker::Inverse. Metoda zwraca przeciwieństwo monikera (na przykład wynik wywołania CreateAntiMoniker). IMoniker::CommonPrefixWith. Jeśli dwa monikery są równe, metoda zwraca MK_S_US i ustawia wartość *ppmkPrefix na NULL. Jeśli któryś z monikerów nie jest monikerem OBJREF, metoda przesyła oba monikery do funkcji MonikerCommonPrefixWith. Funkcja ta poprawnie obsługuje sytuacje, w której inny moniker jest uniwersalnym złożeniem. Jeśli nie występuje wspólny przedrostek, funkcja zwraca wartość MK_E_. IMoniker::RelativePathTo. Metoda zwraca wartość E_NOTIMPL. IMoniker::GetDisplayName. Metoda uzyskuje nazwę wyświetlaną monikera OBJREF. Nazwa wyświetlana jest kodem 64 bitowym zawierającym położenie komputera, punkt końcowy procesu i identyfikator wskaźnika interfejsu (IPID) działającego obiektu. Dla zgodności z przyszłymi wersjami, nazwa wyświetlana może zawierać tylko znaki, które mogą być podane jako część URL. IMoniker::ParseDisplayName. Jeśli parametr pmkToLeft nie ma wartości NULL, metoda zwraca wartość MK_E_SYNTAX. IMoniker::IsSystemMoniker. Metoda zwraca wartość S_OK i przekazuje z powrotem wartość MKSYS_OBJREFMONIKER. Obsługa typów danych VB6.0 Visual Basic((r)) 6.0 pozwala, aby zmienne Visual Basic typu Variant zawierały struktury danych zdefiniowane przez użytkownika. DCOM95 aktualnie obsługuje przesyłanie tego typu danych. II. Naprawione błędy -------------------- Zastrzeżenie klasy podczas rozładowywania wielu modułów Jeśli wiele modułów było rozładowywanych jednocześnie, w poprzedniej wersji DCOM95 występowało zastrzeżenie klasy. W zależności od kolejności rozładowywania modułów, mogło wystąpić naruszenie praw dostępu. Usterka została usunięta w tej wersji DCOM95. Brak reakcji pulpitu podczas uzgadniania protokołu RPC Wcześniejsza wersji DCOM95 nie rozsyłała komunikatów podczas uzgadniania protokołu RPC. W pewnych przypadkach, jeśli użytkownik uruchomił inną aplikację w czasie uzgadniania protokołu RPC, wydawało się że komputer nie reaguje. Po 30 sekundach, przetwarzanie komunikatów było wznawiane. Zachowanie to zostało zmienione w tej wersji DCOM95 i aplikacje mogą być uruchamiane podczas uzgadniania protokołu RPC. Brak reakcji pulpitu podczas uruchamiania nowych aplikacji Protokół RPC tworzy ukryte okno w modelu MTA (Multiple-Threaded Apartment), które nie wymaga rozsyłania komunikatów poprzez DCOM. Kiedy użytkownik uruchamia nową aplikację z pulpitu, system Windows wysyła komunikat do wszystkich innych dojść do okien, informując je o tym zdarzeniu i oczekując odpowiedzi. W poprzednich wersjach DCOM95, ukryte okno RPC mogło nie odpowiedzieć na ten komunikat, co powodowało zawieszenie systemu Windows. W tej wersji DCOM95 rozwiązano ten problem i okno RPC nie powoduje już blokowania reakcji pulpitu podczas uruchamiania nowych aplikacji. Wiele adresów IP powodowało uszkodzenie sterty. W pewnych sytuacjach, jeśli poprzednia wersja DCOM95 była uruchamiana na komputerach z więcej niż jednym adresem IP, bufory adresów IP pokrywały się co powodowało uszkodzenie sterty. Usterka została usunięta w ostatniej wersji DCOM95. Używanie tylko pierwszego adresu IP Jeśli poprzednia wersja DCOM95 była używana na komputerze posiadającym dwie karty sieciowe (z tego względu posiadającym dwa adresy IP, każdy przypisany do różnych adresów karty), DCOM95 używał tylko jednej z kart sieciowych. W tej wersji DCOM95, jeśli próba z pierwszym adresem nie działa, zostanie użyty drugi. Protokół RPC sprawdza wielu adresów IP Podczas wywoływania procedury zdalnej do komputera posiadającego wiele adresów IP kolejne adresy IP będą teraz sprawdzane, jeśli nie powiedzie się połączenie z pierwszym adresem. Pliki monikerów obsługują dodatkową składnię zapisu ścieżki Pliki monikerów mogą być tworzone z argumentami w formie <ścieżkawzględna>, takimi jak "C:\test\test\..\..\foo.jpg." W wersji DCOM95 1.1, dozwolone były tylko ścieżki względne (np., "..\..\foo.jpg") lub bezwzględne (np., "C:\foo.jpg"). Ogólny błąd ochrony podczas rozładowywania biblioteki Oleaut32.dll W poprzednich wersjach DCOM95, występował ogólny błąd ochrony podczas rozładowywania biblioteki Oleaut32.dll przed wywołaniem CoUninitialize. Zdarzało się to często, jeśli aplikacja VB utworzyła formant połączony statycznie z Oleaut32.dll, a następnie zwalniała formant przed wywołaniem CoUninitialize. Nie powoduje to wystąpienia ogólnego błędu ochrony w ostatniej wersji DCOM95. Przesyłanie międzyprocesowe typów Visual Basic Przesyłanie międzyprocesowe pewnych typów danych Visual Basic zostało naprawiono. Parametry tablicowe o rozmiarze większym niż 64K są teraz dozwolone. Struktury zdefiniowane przy użyciu pseudonimów typów są przesyłane poprawnie. Atomy wykrywane wielokrotnie w funkcji OleUninitialize Błąd pojawiał się w aplikacjach wywołujących wielokrotnie funkcje OleInitialize i OleUninitialize. W czasie inicjowania, OLE dodaje wiele atomów dla DDE RPC. Jeśli atomy zostały już dodane przez inny wątek, nie są dodawane ponownie. Jednakże, podczas dezinicjowania, atomy były zawsze wykrywane, a ich dojścia nie usuwane. Dlatego też, podczas następnego wywołania OleInitialize, stare dojścia nadal istniały, nawet jeśli atomy zostały usunięte i OLE nie dodawało ich ponownie. Prowadziło to do sytuacji, w której wszystkie atomy OLE były niepoprawne po wielokrotnym wywołaniu OleInitialize i OleUninitialize. Problem ten został rozwiązany w tej wersji DCOM95. Serwer ADO zamyka się poprawnie. Obiekty ADO (Active Data Objects) wykorzystują moniker wskaźnika, aby uruchomić serwer procesu. Poprzednie wersje DCOM95 zawierały błąd związany ze zliczaniem odwołań do monikera wskaźnika, wskutek którego moniker wskaźnika był tworzony z początkową wartością licznika odwołań 1, zamiast 0. Dlatego też, licznik odwołań monikera wskaźnika nigdy nie mógł uzyskać wartości zero i moniker wskaźnika nigdy nie był zwalniany. W efekcie serwer ADO nigdy nie był zamykany, nawet po zwolnieniu ostatniego wskaźnika do niego. Problem ten został rozwiązany w tej wersji DCOM95. CoCreateInstance pracuje z własną nazwą DNS W poprzednich wersjach DCOM95, wywołanie CoCreateInstance z w pełni kwalifikowaną nazwą lokalnego komputera nie działało. Usterka została usunięta w aktualnej wersji DCOM95 i CoCreateInstance poprawnie tworzy i realizuje wystąpienia na lokalnym komputerze. Powolne opróżnianie w głównej pamięci magazynowej z bardzo dużymi plikami mieszanymi W poprzednich wersjach DCOM95, czas opróżniania głównej pamięci magazynowej otwartej w trybie STGM_TRANSACTED stawał się bardzo długi, jeśli plik mieszany był bardzo duży (np. 400M). Wewnętrzny limit tablicy strony został zwiększony i aktualnie problem nie występuje. Eksport obiektów z odtworzonego MTA W poprzedniej wersji DCOM95, serwer nie mógł eksportować obiektów z komórki MTA (Multi-Threaded Apartment), jeśli nie było to pierwsze utworzenie MTA w procesie. Usterka została usunięta. Teraz jeśli serwer tworzy MTA, niszczy je a następnie odtwarza MTA, obiekty mogą być eksportowane z MTA. Wielokrotne wystąpienia plików EXE Visual Basic 4 W DCOM95 v1.1, jeśli uruchomione zostało wiele wystąpień tego samego pliku wykonywalnego Visual Basic 4, a następnie były one zamykane w dowolnej kolejności, poza kolejnością uruchamiania, ostatni z plików exe zawieszał się. Efekt ten występował także w przypadku formularzy E-Forms w programie Microsoft Exchange. Usterka została usunięta w ostatniej wersji DCOM95. Można zamykać pliki exe Visulal Basic 4 w dowolnej kolejności. Znaki rozszerzone w nazwach plików Visual Basic Jeśli moduł lub klasa Visual Basic otrzymała nazwę zawierającą znaki rozszerzone dla określonego języka, plik taki nie mógł być otwarty na komputerze skonfigurowanym dla innej lokalizacji. Problem ten usunięto. III. Znane problemy ------------------- Corel WordPerfect Suite 7: Instalacja powoduje błąd nieprawidłowej strony Jeśli instalujesz pakiet Corel WordPerfect Suite 7 w systemie Windows 95, w którym działa DCOM95, możesz uzyskać błąd nieprawidłowej strony w Pf0d70.pfc podczas instalacji. Gdy pojawia się ten błąd, po prostu zamknij okno dialogowe. Instalator powinien pomyślnie kontynuować działanie. Microsoft Access95: Nie działa replikacja baz danych Jeśli próbujesz replikować bazę danych Access za pomocą programu Microsoft Access 95 na komputerach z zainstalowanym modułem DCOM95, możesz, możesz uzyskać następujący komunikat o błędzie: Zakończenie tej operacji w programie Microsoft Access nie jest możliwe, ponieważ nie można znaleźć lub zainicjować bilblioteki dołączanej dynamicznie Msjtrclr. Jest to problem programu Microsoft Access 95. Można uniknąć tego problemu, pisząc program, który wykorzystuje model obiektowy programu Access zamiast narzędzia do replikacji lub używając aktówki do replikacji. W programie Microsoft Access 97 problem ten nie występuje. WordPerfect Jeśli masz dokument programu WordPerfect zawierający osadzony arkusz Corel, a arkusz zawiera inny osadzony obiekt (na przykład mapę bitową), może pojawić się ostrzegawcze okno dialogowe informujące, że zostało utracone połączenie sieciowe przy zamknięciu wewnętrznego obiektu. Takich ostrzeżeń może być cztery lub pięć. Wystarczy zamknąć je i kontynuować. Klienci wielowątkowego modelu komórkowego (MTA), którzy używają procedur konwersji BSTR mogą blokować komunikaty dynamicznej wymiany danych (DDE) Procedury automatycznej konwersji BSTR (na przykład BstrFromR4) tworzą ukryte okna, aby ułatwić konwersję typów. Okna te nie obsługują kolejki wiadomości systemu Windows. Jeśli takie okno zostanie utworzone w obrębie klienta MTA, komunikaty DDE mogą być blokowane. Wątek klienta nie musi obsługiwać kolejki wiadomości w modelu programowania MTA. Jeśli nie obsługuje go, okno najwyższego poziomu powoduje blokowanie globalnych komunikatów emisji. Istnieją dwa wyjścia z tej sytuacji. Należy albo wywoływać procedury konwersji BSTR z klienta jednowątkowego modelu komórkowego (STA), albo sprawić, żeby wątek MTA klienta zachowywał się jak wątek STA (wątek STA musi obsługiwać kolejkę wiadomości). Jeśli wątek ten jest blokowany na dojściu win32, musi wywoływać funkcję MsgWaitForMultipleObjects, aby jednocześnie wysyłać komunikaty systemu Windows. Nazwy ścieżek DLL zawierające więcej niż 127 znaków mogą powodować błąd Jeśli spróbujesz zarejestrować bibliotekę dołączaną dynamicznie (DLL) z nazwą ścieżki, która zawiera 128 znaków lub więcej, rejestracja powiedzie się, ale obiekty CoCreateInstance i CoGetClassObject będą zwracać błąd (REGDB_E_CLASSNOTREG) przy próbie uzyskania dostępu do obiektu obsługiwanego przez daną bibliotekę DLL. IV. Różnice w stosunku do protokołu DCOM systemu Windows NT ----------------------------------------------------------- Funkcje zabezpieczeń protokołu DCOM95 Podstawowa funkcjonalność i interfejs programowania aplikacji (API) dla protokołu DCOM95 są takie same w systemie Windows 95 i Windows NT 4.0/5.0. Jednak niektóre funkcje związane z zabezpieczeniami różnią się z powodu różnic w infrastrukturach zabezpieczeń tych systemów operacyjnych. Zalecane jest używanie domyślnych ustawień zabezpieczeń; jest to również niezbędne do włączenia zabezpieczeń "na poziomie użytkownika" dla udziałów systemu plików. (Zobacz dalej.) Dostępne są następujące usługi, których można użyć do zastąpienia domyślnych ustawień zabezpieczeń: * CoInitializeSecurity * CoQueryAuthenticationService * CoQueryProxyBlanket * CoSetProxyBlanket * CoQueryClientBlanket * IClientSecurity Interface * IServerSecurity Interface Jednak niektóre funkcje będące częścią protokołu DCOM dla systemu Windows NT nie będą dostępne w systemie Windows 95 z powodu różnic w infrastrukturze zabezpieczeń systemu Windows 95. W szczególności należy wziąć pod uwagę brak w interfejsie Win32 API funkcji zabezpieczeń, takich jak możliwość tworzenia list kontroli dostępu (ACL) czy funkcja AccessCheck, a także brak kontekstu zabezpieczeń skojarzonego z tokenami wątku i procesu. System Windows 95 nie ma wbudowanej obsługi tych funkcji i konstrukcji. Z tego powodu, protokół DCOM95 nie obsługuje personifikacji (a w szczególności funkcji CoImpersonateClient i CoRevertToSelf przez interfejs IServerSecurity), która jest oparta na zabezpieczeniach tokenów wątku i procesu w systemie Windows NT 4.0. Personifikacja jest powszechnie używana do automatycznej kontroli dostępu do zasobów systemowych o ograniczonym dostępie, takich jak system plików, inne procesy i sieć. W systemie Windows 95 dostęp do tych zasobów nie jest ograniczony. Jednak protokół DCOM95 oferuje programistom różne obiekty pomocnicze dostarczające funkcjonalności ACL i AccessCheck, które mogą być używane przez zdalnych klientów do jawnej kontroli dostępu, zarówno do systemu, jak i zasobów i danych zdefiniowanych przez użytkownika. Te obiekty pomocnicze są dostarczane przez obiekt systemowy CLSID_DCOMAccessControl, który implementuje interfejs IAccessControl. Interfejs IAccessControl powinien być używany do programowego zarządzania uprawnieniami zabezpieczeń, ilekroć ważną rolę odgrywa przenośność danych między systemem Windows 95/98 i Windows NT. Obiekt CLSID_DCOMAccessControl jest dostępny we wszystkich wersjach protokołu DCOM95 i w systemie Windows NT 4.0 w wersji SP2 lub nowszej. Szczegółowe informacje dotyczące interfejsu IAccessControl można znaleźć w dokumentacji Platform SDK. Zabezpieczenia dostępu Sterowanie tym, kto może uruchamiać kod serwera/klasy nie jest obsługiwane w protokołu DCOM95, ponieważ nie jest obsługiwane uruchamianie serwerów. Serwery/klasy muszą już być uruchomione, aby zdalni klienci mogli się z nimi połączyć i korzystać z ich usług. Protokół DCOM95 obsługuje możliwość łączenia się z już uruchomionymi serwerami/klasami. Zabezpieczenia dostępu są obsługiwane poprzez klucz rejestru \APPID\{.}\AccessPermissions i dostosowywane przy użyciu narzędzia DCOMCNFG albo podczas instalacji lub konfigurowania kodu serwera. Nieuwierzytelnieni użytkownicy będą mogli używać serwerów, jeśli klasa zostanie skonfigurowana na obsługę połączeń nieuwierzytelnionych (statycznie, przy użyciu narzędzia konfiguracji, lub dynamicznie, przy użyciu funkcji CoInitializeSecurity). Można również tworzyć listy kontroli dostępu określające, którzy użytkownicy i grupy mogą uzyskać dostęp do określonych usług. Poziomy uwierzytelniania Klienci protokołu DCOM95 mogą używać wywołań DCOM na każdym poziomie uwierzytelniania. Serwery i klienci DCOM95 odbierający wywołania zwrotne mogą akceptować wywołania DCOM tylko przy użyciu poziomu uwierzytelniania RPC_C_AUTHN_LEVEL_NONE lub RPC_C_AUTHN_LEVEL_CONNECT. Transporty Protokół DCOM95 obsługuje połączenia TCP. Jeśli nie masz zainstalowanego protokołu TCP/IP, protokół DCOM95 nie będzie w stanie obsługiwać protokołu COM między komputerami. Ustawienie rejestru Następujące klucze rejestru znajdujące się w folderze HKEY_LOCAL_MACHINE\Software\Microsoft\OLE są związane z protokołem DCOM95: EnableDCOM (wartość domyślna = "Y"). Włącza protokół DCOM na danym komputerze. Jeśli ustawiona zostanie wartość "N", komputer nie może się łączyć z komputerami zdalnymi ani uaktywniać na nich obiektów, a komputery zdalne nie mogą się łączyć z obiektami na komputerze lokalnym. Ustawienie wartości "Y" powoduje, że komputer może łączyć się z obiektami zdalnymi jako klient (gdy EnableRemoteConnect='N', co wyjaśniono dalej), albo umożliwia pełną łączność klient/serwer (gdy EnableRemoteConnect='Y', co wyjaśniono dalej). EnableRemoteConnect (wartość domyślna = "N"). Umożliwia serwerom COM obsługę klientów zdalnych. Jeśli ustawiona zostanie wartość "Y", odwołania do interfejsów obiektów lokalnych mogą być przekazywane do klientów zdalnych, a klienci zdalni mogą łączyć się z uruchomionymi obiektami. Jeśli ustawiona zostanie wartość "N", komputer może łączyć się z obiektami zdalnymi, ale nie może działać jako serwer: komputer nie może łączyć się z uruchomionymi obiektami. Ponadto, następujący klucz rejestru znajduje się w folderze HKEY_CLASSES_ROOT\CLSID: {bdc67890-4fc0-11d0-a805-00aa006d2ea4}\InstalledVersion. Zawiera on numer wersji protokołu DCOM95 w formacie "a,b,c,d". Wartość ta może być używana przez usługę Internet Component Download do określenia, czy protokół DCOM95 jest zainstalowany. Wartość ta jest dodawana do rejestru podczas instalacji i nie należy jej modyfikować. Używanie systemu Windows 95 jako hosta serwera zdalnego System Windows 95 może być hostem serwera zdalnego, przy czym trzeba pamiętać o następujących ograniczeniach i warunkach: * Nie ma możliwości uruchamiania procesów. Proces serwera musi być już uruchomiony, aby klient mógł się z nim połączyć. * Jeśli wymagane są połączenia bezpieczne, serwer (a w przypadku wywołań zwrotnych, klient) musi mieć włączoną kontrolę dostępu na poziomie użytkownika z ustawioną nazwą dostawcy zabezpieczeń. * Wartość rejestru "EnableRemoteConnect" musi być ustawiona na "Y". Protokół DCOM95 był szeroko testowany przy użyciu dostawcy zabezpieczeń Windows NT Domain. Mogą wystąpić problemy, jeśli będzie używany inny dostawca zabezpieczeń. Aby ustanowić kontrolę dostępu na poziomie użytkownika, trzeba zainstalować plik Filesec.vxd. Plik ten jest zazwyczaj instalowany na komputerach systemu Windows 95 podczas instalacji usługi udostępniania plików i drukarek. Aby ustanowić kontrolę dostępu na poziomie użytkownika, otwórz okno dialogowe "Sieć" w Panelu sterowania, kliknij kartę "Kontrola dostępu", zaznacz opcję "Kontrola dostępu na poziomie użytkownika" i wprowadź nazwę domeny zabezpieczeń. Może to wpłynąć na sposób, w jaki aktualnie udostępniasz w sieci katalogi ze swojego komputera; szczegóły można znaleźć w dokumentacji online. Jeśli karta "Kontrola dostępu" nie pojawia się, trzeba zainstalować usługę klienta sieci. W indeksie Pomocy online kliknij pozycję "klienci sieci, instalacja", aby uzyskać informacje dotyczące instalacji klienta sieci. V. Redystrybucja ----------------- Informacje dotyczące redystrybucji protokołu DCOM95 można znaleźć w Umowie licencyjnej użytkownika (license.txt), która określa zasady redystrybucji. VI. Pomoc techniczna i zasoby ----------------------------- Obsługa serwisowa firmy Microsoft® Odpowiedzi na pytania związane z instalacją i użytkowaniem oprogramowania firmy Microsoft należy szukać przede wszystkim w: - Dokumentacji i innych materiałach dołączonych do oprogramowania lub w informacjach pomocniczych zawartych w plikach automatycznie kopiowanych podczas instalacji oprogramowania. - Pomocy (Help), dostępnej bezpośrednio z ekranu komputera. - W pliku informacji dodatkowych (zwykle Readme.txt), znajdującym się na dysku instalacyjnym. W tym pliku zawarte są istotne informacje na temat funkcjonowania programu oraz zmian, jakie pojawiły się po opracowaniu podręczników i dokumentacji. - W Internecie. Polska witryna pomocy technicznej Microsoft — http://www.microsoft.com/poland/problemy/ — zawiera kilkadziesiąt opisów pomagających rozwiązać najczęściej występujące problemy techniczne. Witryna zawiera również bardziej rozbudowane artykuły techniczne. Wszystkim legalnym, zarejestrowanym użytkownikom oprogramowania Microsoft, którzy nie mogą znaleźć rozwiązania problemu technicznego w wyżej wymienionych źródłach lub nie mają do nich dostępu, firma Microsoft oferuje bezpłatną pomoc telefoniczną. Standardowa pomoc techniczna Pomoc techniczna świadczona przez Biuro Pomocy Technicznej jest bezpłatna. Biuro Pomocy Technicznej obsługuje legalnych i zarejestrowanych użytkowników produktów firmy Microsoft. Biuro udziela porad telefonicznych pod numerem (0-22) 865 99 66 w godzinach od 9:00 do 17:00, od poniedziałku do piątku, z wyjątkiem świąt. Ograniczenia zakresu bezpłatnej pomocy Biuro Pomocy Technicznej: - Nie obsługuje wizyt. - Nie rozwiązuje problemów zgłoszonych za pośrednictwem poczty (np. przez przysłanie dyskietki), faksu, poczty elektronicznej — z wyjątkiem przypadków uzgodnionych uprzednio telefonicznie. - Nie udziela informacji handlowych ani informacji na temat oferty lub dostępności produktów i usług Microsoft. Wszelkie tego typu pytania prosimy kierować do Infoserwisu Microsoft. - Nie udziela pomocy technicznej dla produktów z rodziny Microsoft BackOffice®. - Jeśli produkt firmy Microsoft został zakupiony wraz ze sprzętem komputerowym lub jako preinstalowany przez producenta na komputerze osobistym, do świadczenia pomocy technicznej zobowiązany jest wyłącznie producent komputera. Aby uzyskać pomoc techniczną dla takiego produktu, należy skontaktować się z producentem lub sprzedawcą, od którego został nabyty produkt firmy Microsoft. Rejestracja produktu Po zainstalowaniu oprogramowania, należy wysłać pod wskazany adres wypełnioną kartę rejestracyjną. W ciągu ok. 2 tygodni otrzymają Państwo zwrotnie potwierdzenie rejestracji oraz stały numer klienta, na który należy się powoływać w kontaktach z Biurem Pomocy. Procedura korzystania z usług Biura Pomocy Technicznej Aby ułatwić i przyspieszyć procedurę udzielenia pomocy, przed zadzwonieniem do Biura Pomocy Technicznej powinni Państwo przygotować następujące informacje: - Numer identyfikacyjny klienta (otrzymany wraz z potwierdzeniem rejestracji). - Identyfikator produktu (Product ID). Jest to numer widoczny po wybraniu z menu Pomoc (Help) polecenia  — informacje (About ). - Rodzaj i wersja oprogramowania Microsoft, którego dotyczy pytanie. - Marka i typ używanego komputera oraz informacje o środowisku pracy (samodzielny komputer, sieć). - Treść komunikatów informujących o pojawieniu się problemu. - Opis problemu: podczas jakich czynności wystąpił i jakie są jego objawy. - Jakie próby rozwiązania problemu zostały podjęte przed skonsultowaniem się z Biurem Pomocy Technicznej. Firma Microsoft zastrzega sobie możliwość wprowadzenia zmian w zasadach funkcjonowania obsługi technicznej bez uprzedniego powiadomienia. W przypadku konieczności zmiany numerów telefonów, stosowne informacje podawane będą w naszej witrynie internetowej pod adresem http://www.microsoft.com/poland/ oraz w korespondencji wysyłanej okresowo do zarejestrowanych klientów. Inne programy i usługi pomocy technicznej Firma Microsoft oferuje również programy i usługi pomocy technicznej dla firm, które wymagają więcej niż standardowej pomocy w przypadku wystąpienia problemu. Aby uzyskać aktualne informacje na ten temat, należy odwiedzić witrynę Obsługi technicznej online firmy Microsoft pod adresem http://www.microsoft.com/poland/support/ lub skontaktować się z przedstawicielstwem firmy Microsoft. Infoserwis Wszelkie pytania nie związane z problemami technicznymi, w tym pytania dotyczące oferty handlowej i dostępności produktów firmy Microsoft, oraz prośby o informacje na temat poszczególnych produktów, należy kierować do Infoserwisu Microsoft lub bezpośrednio do naszych przedstawicieli handlowych. Infoserwis udziela informacji na temat przedstawicieli handlowych znajdujących się najbliżej Państwa. Telefon Infoserwisu: (0-22) 865 99 33 w godzinach od 9:00 do 17:00, od poniedziałku do piątku, z wyjątkiem świąt. Infoserwis nie udziela pomocy technicznej. Firma Microsoft zastrzega sobie możliwość wprowadzenia zmian w zasadach funkcjonowania Infoserwisu bez uprzedniego powiadomienia. W przypadku konieczności zmiany numerów telefonów, stosowne informacje podawane będą w naszej witrynie internetowej pod adresem http://www.microsoft.com/poland/ oraz w korespondencji wysyłanej okresowo do zarejestrowanych klientów. VII. Lista plików -------------------- W następującej tabeli zamieszczono listę numerów wersji plików dostarczanych z protokołem DCOM95. oleaut32.dll 2.40.4275 secur32.dll 4.10.1999 compobj.dll 2.3.2 ole2.dll 2.3.2 ole32.dll 4.71.2900 olecnv32.dll 4.71.2900 olethk32.dll 4.71.2900 rpcltc1.dll 4.71.2900 rpcltc5.dll 4.71.2900 rpcltccm.dll 4.71.2900 rpclts5.dll 4.71.2900 rpcltscm.dll 4.71.2900 rpcns4.dll 4.71.2900 rpcrt4.dll 4.71.2900 rpcss.exe 4.71.2900 storage.dll 2.3.2 stdole2.tlb 2.40.4275 stdole32.tlb 2.1 imagehlp.dll 4.00 dllhost.exe 4.71.2900 comcat.dll 5.0 iprop.dll 4.00 rpcmqcl.dll 4.71.2900 rpcmqsvr.dll 4.71.2900 olepro32.dll 5.0.4275 asycfilt.dll 2.40.4275 dcom2w98.dll 2.10.35.35 W następującej tabeli zamieszczono listę numerów wersji plików dostarczanych z protokołem DCM95CFG. dcomcnfg.exe 5.00.1603.0 ciscnfg.exe 4.71.2618