| Summary: | Нет привязки по netbios (Кодекс) | ||
|---|---|---|---|
| Product: | WINE@Etersoft | Reporter: | Константин Кондратюк <kondratyuk> |
| Component: | Общее | Assignee: | Константин Кондратюк <kondratyuk> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P5 | CC: | ivan, lav, yury |
| Version: | 1.0.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Заявки RT: | Связано с: | ||
| Дата напоминания: | |||
| Bug Depends on: | |||
| Bug Blocks: | 492, 584, 785 | ||
|
Description
Константин Кондратюк
2007-02-21 16:38:22 MSK
На версии Кодекса, полученной для тестирования проблемы, ошибка проявилась. При выборе привязки "к компьютеру" список доступных компьютеров в сети пуст. Возможно, проблемы с netbios'ом начинаются именно здесь... Инициализация сети проходит при добавление ряда ключей в реестр wine. По аналогии с NTLanman это ключи (HKEY_LOCAL_MACHINE):
System\CurrentControlSet\Control\NetworkProvider\Order
ProviderOrder = "NTLanman"
System\CurrentControlSet\Services\NTLanman\NetworkProvider
DeviceName (пока пустой)
Name = "Microsoft Windows Network"
ProviderPath = "c:\windows\system32\ntlanman.dll"
После этого требует саму ntlanman.dll и ещё несколько связанных с ней. После подстановки вроде бы инициализируется сеть, ошибка NO_NETWORK не появляется.
Дальше - серия stub'ов при вызове WNetOpenEnum.
Видимо оставляем в названии провайдера NTLanman. Нужно грузить соответствующую библиотеку. Библиотека из Windows не работает - нужно написать свою, заменяющую её. Предполагаемая функциональность - перечисление ресурсов, смонтированных в unc/ Добавил ntlanman.dll к своему проекту. Доступны пока 2 функции, и то в виде стабов - NPGetCaps и NPOpenEnum. До NPOpenEnum загрузка не проходит, потому что в функции WNetOpenEnum параметр lpNet->lpProvider==0. Нужно узнать, почему так происходит, скорее всего этот участок кода должен отрабатывать. Нет, похоже, что NPOpenEnum() вообще не должна быть задействована. По крайней мере сейчас одинаковая ситуация и в новой внутренней библиотеке, и в win-dllке. От загрузки ntlanman из Windows отвязались, реализовав NPGetCaps(). 1. Есть вход в функцию NPEnumResources() и ожидание информации о ресурсах от неё. 2. Есть чтение содержимого .wine/dosdevices/unc, реализованное внутри функции NPEnumResources(). Осталось совместить эти два направления работы и посмотреть результаты в CompId. Ответ из wine-devel:
> The information about loaded dll is absent in the wine registry. Whether it
> means, what there are no preparations of DLL's for work with a network
> (similar ntlanman.dll in Windows)?
That's correct, this hasn't been implemented in Wine yet.
> Может в самом Линуксе из пакета самбы поставить nmbd, он же полностью
> эмулирует функцию нетбиоса под Линуксом, а уже из wine к нему
> привязаться?
Тест заработал, ресурсы в /unc перечисляются. CompId пока не показывает список. Есть проблемы с перечислением ресурсов, если *lpcCount > 1. В этом случае - падение, причём как на моей dllке, так и на виндовой. Есть перечисление компьютеров и формирование строк (только для существующих в сети машин). Нужно будет проверить, что всё хорошо, и багу с Кодексом можно закрывать. Добрался до реализации NPGetResourceInformation() и NPGetResourceParent(). Всё осложняется тем, что никакой подготовки к их вызову в mpr нет. На A и W вызоовы функций WNetGetResourceInformation() и WNetGetResourceParent() - стабы и return NO_NETWORK; Проблема исправлена к 1.0.8 |