nesco, Galkov,
Товарищи, у вас что нибудь получилось с TCP в сервисе?
А то я тоже, как и ТС, решил TCP в сервис запихать, а он не работает
Вот маленькие примеры
Сервер code_31290.txt
Клиент code_31291.txt
При этом странно не работает
Соединение проходит, а текст не передается

Думаю, что нет.
Нет никакого настроения заморачиваться с введением аплета (без которого kol-у вся жисть только чернобелая).
Такого за собой потянуть может - мама не горюй. Если бы с самого начала делали....
------------ Дoбавленo в 11.15:
Что-то мне подсказывает, что nesco скажет то же самое. Хотя - чем черт не шутит

эх видимо не кто не додумается до этого:

Берём запуск приложений и ВСЁ
создаём сервис и в него пихаем запуск клиента или сервера в виде программы другой и под запуск эту программу так же что бы не было прерываний
берём делаем проверку процесса если он закрылся или его закрыли сервис его открывает снова

это самый простой пример

Rysik,
А как вы будете запускать программу, если на сервере (железный комп) нет активных пользователей, т.е. нет рабочих сессий?
Я думаю никак.
Остается только полноценный сервис (служба).

А разве это возможно У Винды же вроде всегда есть пользователь, даже в терминальном сервере.


Насколько я понял, то созданному в сервисе окну пропускаются только выборочные сообщения, такие как WM_TIMER, а вот WM_USER глушится. Точной инфы про пропускаемые сообщения мне найти нигде пока не удалось

Возможно
1. Вы только включили комп., ОС загрузилась и находится в ожидании ввода пароля
2. Вы получили доступ к своему рабочему столу, поработали, а потом сделали LogOff (опять ожидание ввода пароля)
При этих условиях работают только службы.

Чаще всего, такие условия работы ОС, встречаются на серверах (там где нужна повышенная секурность)
Оставлять рабочие сессии на сервере, это не кошерно

nesco, может для этих случаев нужно использовать не оконные сообщения (WSAAsyncSelect в TSocket.Create), а объекты событий через функцию WSAEventSelect http://www.sources.ru/cpp/cpp_network_evets_winsock2.shtml
(здесь то же самое но на Delphi)
В общих чертах:
- выполняем bind
- создаем объект через WSACreateEvent()
- связываем объект с сокетом и требуемыми событиями (WSAEventSelect())
- создаем параллельный поток и в нем располагаем обработчик событий. В обработчике ожидаем прихода события через WSAWaitForMultipleEvents

К тому же, наличие потока -- это асинхронный вывод, а наличие обработчика окна -- это синхронный. А сколько мы уже съели попыток засунуть асинхронный вывод на интерфейсные элементы. И все валят на то, что они пользователи, а не программисты и знать этого не обязаны, и во всем виноваты разработчики.
Так что я на себя такую ответственность не хочу брать. Если хочешь, то можешь договориться с -= DriveR =- и сделать ему отдельный TCP_Server для служб. А в остальном, у нас эти элементы нормально работает, а службы юзают единицы из общего потока пользователей

Так может именно потому что служба не полноценная?
Я с HiAsm знаком ОЧЕНЬ давно, за время моего знакомства я столько админских проектиков похерил и только потому, что службы не работают должным образом
Не сочтите за наезд с моей стороны, просто мысли в слух, почему службы пользуют единицы.

Вообще, по большому счету, компонент службы в нынешнем виде вообще не нужен.
Для чего делать локальную службу? Проще сделать фоновое приложение, а служба тем и хороша что она может работать с сетью, вне пользовательской сессии.
Для меня, как для админа, это очень актуально.

-= DriveR =-, у нас разве по другому: "спасение утопающих - дело рук самих утопающих"

Ну не программист я, не программист. Не дано мне.

А мы тоже такие же