Планирую реализовать масштабирование экрана в следующей версии. «Автоматический размер окна» просто выставляет оптимальный размер окна исходя из размеров удаленного экрана. Если удаленный экран меньше локального, то окно изменяет размер до размеров экрана, если больше, то разворачивает на весь экран.
У меня есть ИП, но это никак не связано с данной программой. Сертификат для подписи приложений у меня есть, для подписи драйверов — нет. Стоит дорого, по крайней мере для меня.
1. Кодируются только измененные блоки, для сравнения блоков используется вычисление SAD через SSE2/SSE3/AVX2.
2. Посмотрю.
3. У меня есть реализация mirror-драйвера, но использовать его проблемно, нужна электронная подпись для драйверов. Стоит дорого. Использовать стороннюю подпись нельзя, это противоречит условиям Whitelist. Реализация захвата с использованием DXGI API запланирована.
4. MSI инсталлятор уже имеется. NTLM авторизация запланирована на следующую версию. Программа бесплатная, для коммерческого использования в том числе.
5. Реализуемо. Для взаимодействия со службой просто используется IPC. Сейчас так же работают процесс сессии и уведомитель о подключенных сессиях (запускаются в сеансе пользователя).
В следующей версии сделаю. Возможность полезная. Единственное, что меня смущает — передача пароля через командную строку. Этот пароль могут увидеть другие приложения.
Теоретически возможно. Сторонние библиотеки должны собираться и для Android/iOS. Если делать только клиент, то все еще значительно упрощается. Клиентская часть почти на 100% кросплатформенная.
Даже сам Qt уже планирует отказываться от qmake в пользу qbs.
Не говоря уже о таком проекте, как KDE (одном из крупнейших, которые используют Qt). Как вы думаете, что использует KDE? Правильно, cmake.
В Qt очень хорошая интеграция с cmake, а cmake позволяет генерировать проекты для многих IDE, например, для Visual Studio.
1. Отсутствие шифрования.
2. Для авторизации на уровне протокола используются алгоритмы, которые уже просто нельзя использовать ввиду их небезопасности (алгоритм 1977 года, возможен полный перебор за разумное время).
3. Ограничение длинны пароля в 8 символов.
4. Нет разграничения прав доступа.
5. Нет поддержки многопользовательских конфигураций.
6. Реальные реализации для Windows крайне медленные, если не использовать mirror-драйвер (используют хуки для определения измененных областей экрана).
Часть из проблем решается надстройками, но в целом протокол уже морально устарел.
Хочу добавить по поводу мультиплатформенности.
1. В проекте из сторонних компонентов используются: Qt, libsodium, protobuf, libyuv, libvpx, zlib-ng. Все эти компоненты собираются для Linux/MacOS (с использованием соответствующих инструкций по сборке этих библиотек или собранных вариантов из вашего дистрибутива).
2. Весь UI и почти весь код написан с использованием стандартного Qt и stl и с учетом дальнейшей кросплатформенности.
3. Для реализации версий для Linux/MacOS необходимо: реализовать захват видео, пользовательский ввод-вывод (клавиатура-мышь), демон (аналог виндовой службы), а так же взаимодействие с сеансами пользователей (вход пользователей, выход пользователей из системы; не уверен, как правильно это называется в *nix).
4. Реализовать различные мелкие платформозависимые вещи (которые на первое время могут быть заменены заглушками, например, получение ассоциированных с типом файла иконок).
5. Добавить поддержку платформы в cmake-файлы.
6. Сделать установочные пакеты для распространенных систем.
В основном, это все что требуется.
Если кто-то готов помочь с реализаций, то всеми возможными способами окажу содействие.
При этом стоит учитывать, что очень многое из этого можно подсмотреть или заимствовать из WebRTC/Chromium.
Я считаю, что смысл есть.
1. Aspia так же возможно развертывать в AD, внутри установочного exe файла находится msi, который можно распаковать.
2. Инвентаризация — это побочный бонус от информации о системе. Это что-то вроде сетевой версии AIDA. К тому же, я планирую сделать не только информацию о системе, но и управление этой системой.
3. Баг с мультимониторными системами уже известен, буду исправлять.
Было бы очень неплохо, если бы кто-нибудь согласился помочь кодом. В первую очередь нужен код, сервер дело хорошее, но наживное. Для добровольцев могу выделить отдельный бранч на гитхабе и помочь разобраться с внутренним устройством проекта.
В идеале, для обхода NAT по максимуму использовать готовые решения для сервера-посредника.
2. Посмотрю.
3. У меня есть реализация mirror-драйвера, но использовать его проблемно, нужна электронная подпись для драйверов. Стоит дорого. Использовать стороннюю подпись нельзя, это противоречит условиям Whitelist. Реализация захвата с использованием DXGI API запланирована.
4. MSI инсталлятор уже имеется. NTLM авторизация запланирована на следующую версию. Программа бесплатная, для коммерческого использования в том числе.
5. Реализуемо. Для взаимодействия со службой просто используется IPC. Сейчас так же работают процесс сессии и уведомитель о подключенных сессиях (запускаются в сеансе пользователя).
Не говоря уже о таком проекте, как KDE (одном из крупнейших, которые используют Qt). Как вы думаете, что использует KDE? Правильно, cmake.
В Qt очень хорошая интеграция с cmake, а cmake позволяет генерировать проекты для многих IDE, например, для Visual Studio.
2. Для авторизации на уровне протокола используются алгоритмы, которые уже просто нельзя использовать ввиду их небезопасности (алгоритм 1977 года, возможен полный перебор за разумное время).
3. Ограничение длинны пароля в 8 символов.
4. Нет разграничения прав доступа.
5. Нет поддержки многопользовательских конфигураций.
6. Реальные реализации для Windows крайне медленные, если не использовать mirror-драйвер (используют хуки для определения измененных областей экрана).
Часть из проблем решается надстройками, но в целом протокол уже морально устарел.
1. В проекте из сторонних компонентов используются: Qt, libsodium, protobuf, libyuv, libvpx, zlib-ng. Все эти компоненты собираются для Linux/MacOS (с использованием соответствующих инструкций по сборке этих библиотек или собранных вариантов из вашего дистрибутива).
2. Весь UI и почти весь код написан с использованием стандартного Qt и stl и с учетом дальнейшей кросплатформенности.
3. Для реализации версий для Linux/MacOS необходимо: реализовать захват видео, пользовательский ввод-вывод (клавиатура-мышь), демон (аналог виндовой службы), а так же взаимодействие с сеансами пользователей (вход пользователей, выход пользователей из системы; не уверен, как правильно это называется в *nix).
4. Реализовать различные мелкие платформозависимые вещи (которые на первое время могут быть заменены заглушками, например, получение ассоциированных с типом файла иконок).
5. Добавить поддержку платформы в cmake-файлы.
6. Сделать установочные пакеты для распространенных систем.
В основном, это все что требуется.
Если кто-то готов помочь с реализаций, то всеми возможными способами окажу содействие.
При этом стоит учитывать, что очень многое из этого можно подсмотреть или заимствовать из WebRTC/Chromium.
1. Aspia так же возможно развертывать в AD, внутри установочного exe файла находится msi, который можно распаковать.
2. Инвентаризация — это побочный бонус от информации о системе. Это что-то вроде сетевой версии AIDA. К тому же, я планирую сделать не только информацию о системе, но и управление этой системой.
3. Баг с мультимониторными системами уже известен, буду исправлять.
В идеале, для обхода NAT по максимуму использовать готовые решения для сервера-посредника.