= Сообщение: 64 из 1924 =========================================== RU.BINKD = От : Yuri Myakotin 2:5020/4441.1 24 Oct 13 11:55:31 Кому : Pavel Gulchouck 24 Oct 13 11:55:31 Тема : То ли лыжи не едут... FGHI : area://RU.BINKD?msgid=2:5020/4441.1+5268d274 На : area://RU.BINKD?msgid=2:463/68+52683e0f = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.BINKD?msgid=2:463/68+5268dc33 ============================================================================== Hello Pavel!
Wednesday October 23 2013 23:59, Pavel Gulchouck wrote to Roman Trunov: PG> Точно сработает? PG> -1 для указателя - не вполне естественное значение. Это во всех использующих хэндлы winapi функциях - "INVALID_HANDLE_VALUE"
RT>> А вот что хуже - то, что socket() в винде возвращает не int, а RT>> SOCKET, который - сюрприз!- теперь тоже intptr_t, т.е. 64 бита. PG> Эх... :( Тем не менее уже несколько дней скомпиленный MSVC 2013 в 64бит бинкд работает у меня без всяких проблем. Единственная правка - в том самом месте, где падало (int/long на intptr_t).
PS насчет своей идеи с .bsy файлами - пока просто добавил для себя код, который создание/удаление .bsy дублирует посылкой адреса моему тоссеру через named pipe. Сейчас делаю обработчик, который будет динамически паковать нетмейл на линка в момент начала успешной сессии с ним.
PG> Наверное, можно не BINKD_SOCKET, а просто SOCKET, который, если не PG> определён, то typedef int. И ведь делать нечего, уже не рассосётся. :( PG> Хотя есть другой вариант. Там ведь для функций работы с сокетами под PG> виндой всё равно врапперы. Сделать у binkd/win собственный массив PG> сокетов, и хранить индекс в этом массиве. Пожалуй, так мне даже больше PG> нравится. Нет ли в этом варианте каких-то явных недостатков, которые я PG> не заметил? Открытие/закрытие сокета нужно семафорить - не проблема. Было бы неплохо.
See all in Hell, Yuri --- Мессагомаратель 1.1.5-b20110320 * Origin: Убей человека. Прежде всего в самом себе. (2:5020/4441.1)
