To co chcesz uzyskać może okazać się nie możliwe w takiej konfiguracji.
Microsoft z każdą kolejną wersją systemu zmienia sposób w jaki działa
sieć Windows.
Sieć Microsoft Network powstał jako kluczowy element systemu
Windows 3.1 for Workgroup.
Było to na początku lat 90 ubiegłego wieku, mało kto wiedział wówczas co
to Internet, a protokół TCP/IP używany był w ośrodkach akademickich.
Sieci lokalne z biurach korzystały z protokołów IPX dzięki popularności
produktów rodziny Novel Netware.
Microsoft też na początku używał IPX-a, NetBIOS-a i jego rozszerzenia
NetBEUI
Protokoły te nie posiadały mechanizmu zamiany nazwy na adres maszyny
Microsoft musiał więc wyposażyć swoje systemy we własny mechanizm,
powstał wiec Network Browsing.
Usługa ta działa w ten sposób, że w momencie startu komputera
wysyła on broadcast po sieci lokalnej szukając aktywnego browsera,
jeśli takiego nie ma to sam staje się browserem.
Jeśli znalazł aktywny browser to rejestrował się w nim, podając swoja
nazwę i adres swojej karty sieciowej.
Później, kiedy Microsoft zaadaptował swoja sieć do pracy z TCP/IP
mechanizm ten stał się zbędny, gdyż za cześć tej funkcjonalności
odpowiadają DHCP i DNS, standardowe usługi sieci TCP/IP.
Nie ma sensy dublować rozwiązań,
tak wiec Windows XP był ostatnim systemem, który mógł pracować jako
browser i ostatni który wiedział jak z takiego browsera korzystać.
Dlatego też, gdy nie mamy w sieci kontrolera Active Directory,
który byłby jednocześnie serwerem DHCP i DNS dla sieci lokalnej,
może nie być możliwe łączenie się do komputerów po nazwie.
W Windows problem ten można obejść dopisując w pliku
c:\Windows\System32\drivers\etc\hosts
nazwy i adresy IP wszystkich maszyn z którymi chcemy się łączyć.
Nie wiem czy coś takiego jest możliwe w DOS, czy ma on swój odpowiednik
pliku "hosts".
Kolejny problem to wydajność.
W latach 80-tych i 90-tych, kiedy powstawały aplikacje DOS-owe używające
plikowych baz danych sieci lokalne działały inaczej niż dziś.
Przykładowo, pierwsza wersja microsoftowego protokołu SMB posiadała
ponad 100 różnych komend. Z plików znajdujących się na innej maszynie
można było korzystać niemal tak samo jak z plików lokalnych,
można było pobrać niewielki fragment danych ze środka pliku,
zmodyfikować go i odesłać tylko ten fragment.
Oczywiście protokół SMB też uległ zmianie przez te lata,
chyba największa miała miejsce wraz z pojawieniem się Visty
i drugiej dużej wersji SMB, z ponad 100 komend, pozostało raptem 19.
Teraz aby aplikacja mogła pobrać niewielki fragment pliku z jego środka
komputer musi pobrać cały plik, stworzyć jego kopie lokalną i dopiero
z tej kopii odczytać dane. Podobnie jest przy zmianach.
Oczywiście Microsoft nazywa to postępem i wprowadza BranchCaching
przechowujący kopie pliku serwerowego na lokalnej maszynie przed 28 dni,
wprowadza mechanizm synchronizacji danych oparty na binarnej kompresji
różnicowej, oraz inteligentny transfer w tle aby synchronizować dane
tylko wówczas gdy użytkownik nie używa aktywnie aktywnie internetu.
Wszystko to razem spowodowało, że Vista, Windows 7 oraz 8
stały się bezużyteczne jako serwery plików w sieci lokalnej,
a już na pewno nie ma sensu trzymać na nich plikowych baz danych,
czyli współdzielonych plików o rozszerzeniach takich jak mdb
czy też dbf.
Można co prawda spróbować wymusić na systemie aby korzystał tylko z
pierwszej wersji protokołu SMB, ale nie rozwiąże to do końca wszystkich
problemów, gdyż zaraz pojawi się kolejny: logowanie.
Pierwsze wersje Windows oraz DOS-owy klient sieci Windows korzystały z
LAN Managera, mechanizm kontroli dostępu był dziurawy jak ser
szwajcarski, z błędami już przy samej koncepcji swojego działania.
Dlatego też Windows 7 ma zaraz po instalacji zablokowaną możliwość
używania starego protokołu i akceptuje połączenia tylko od komputerów
używających NTLMv2. Pozostaje tylko odblokować stare protokoły
poprzez zmianę w rejestrze lub Group Policy.
/Robert
|