VoidVolker

Кросскомпиляция для винды под линуксом вполне возможна. Лет 20 назад это было не так уж и сложно, но сегодня объём и сложность всяких зависимостей в проектах и компиляторах выросли настолько, что это превратилось в длинный и очень весёлый квест с кучей подводных камней и даже айсбергов. Поэтому проще всего поставить виртуалку и уже в ней всё собирать сразу под целевой ОС. Собственно в вашем случае так и надо продолжить разбираться с проблемами, которые вы встретили при сборке под линуксом. На сайте TDLib есть подробная инструкция для сборки библиотеки. Что именно у вас не получилось сделать? Вы искали ответ на вашу проблему в гугле?

Да, можно. Ставите VirtualBox или UTM App, ставиет виртуалку с виндой десятой или одиннадцатой, в ней студию 2022 и все остальные инструменты для разработки. Есть два варианта:

• х86 винда - потери производительности примерно 90%, но в целом всё будет работать как на обычной винде, просто существенно медленнее
  
• Arm винда - пишут, что встроенный в винду транслятор команд х86->Arm достаточно производительный и работает нормально, но я лично не тестировал и ничего конкретного сказать не могу, предполагаю, что теоретически возможны какие-то проблемы
  

На маке в виртуалку студию не ставил, но в целом в виртуалке сама по себе студия работает прекрасно и даже на не самом топовом железе вполне юзабально работает. В целом же рекомендую всё же использовать х86 ПК для разработки под винду ну или арендовать виртуалку в облаке.

Да, всё верно, запускать службу на экране входа. Только что попробовал двигать и менять положение окна логина - не поддаётся, к сожалению. А вот скрыть или свернуть/развернуть его вполне можно. Очевидно, что позиция и размер окна прибиты гвоздями к основному экрану и обновляются приложением логина в реальном времени. Так что тут остаётся только несколько вариантов:

• Попробовать изменить настройки экрана на дублирование
  
• Реализовать своё окно логина - с дублированием ввода в оригинальное или возможно через даже через Credential Provider (не щупал - как оно работает не знаю)
  
• Попробовать хакнуть процесс логина через редактирование его памяти и вписать нужные значения в переменные позиции и размера окна - вот тут тоже может не сработать из-за ограничений безопасности
  

Такую службу я уже как-то давно запилил: https://github.com/VoidVolker/Windows-logon-service - она умеет запускать любые приложения в любом количестве на экране входа. А вот пример приложения, которое её использует: https://github.com/VoidVolker/LockScreen - показывает обои на всех дополнительных экранах логина. Там же легко найдёте код для работы со списком экранов - можете спокойно использовать (только ссылку укажите на репозиторий). А если сделаете с открытым исходным кодом - вообще отлично будет. Только WPF не используйте - там жуткий маразм из-за DPI с размещением окон на нескольких мониторах. Лучше WinForms или С/С++/WinAPI на любом ЯП. Для ковыряния в окнах есть великолепнейшая утилита InqSoft Window Scanner (древний раритет, но сравнимых по функционалу аналогов нет).

UPD: проверил возможность переключения основного экрана в сессии логона - работает! Итак, решение следующее:

1. Качаем nircmd: https://www.nirsoft.net/utils/nircmd.html
   Команда для переключения монитора следующая: https://nircmd.nirsoft.net/setprimarydisplay.html
   

   ❯ ./nircmd.exe setprimarydisplay 1
   ❯ ./nircmd.exe setprimarydisplay 2
   ❯ ./nircmd.exe setprimarydisplay \\.\DISPLAY3

   
   
2. Вариант 1: Пишем простейшее приложение, которое при старте переключает монитор на нужный через nircmd, а при получении команды остановки - переключает монитор обратно. Вот на счёт события остановки не уверен - т.к. у меня в сервисе используется стандартный Process.Kill() без ожидания, при этом ещё и сессия логона закрывается и отработает ли событие - не знаю, не проверял. Возможно, добавлю в сервис опцию для выполнения команды перед закрытием сессии - либо в контексте сессии логона либо от имени системы.
   
3. Вариант 2: в конфиг логон сервиса просто пишем nircmd с командой переключения на нужный монитор (при отключении монитора логон может и сломаться - не проверял)
   
4. Пользователю в автозапуск положить скрипт/команду для переключения монитора обратно. Если требуется - это будет проще, чем запускать приложение в закрывающейся сессии логона.
   

можно ли сделать моё наложение частью окна

Только со стороны механизма рендеринга окна. Если у этого окна есть свой кастомный рендер контента, конечно. Если это простое системное окно - то нельзя.

• Открыть исходный код и посмотреть
  
• При отсутствии исходного кода дизассемблировать и посмотреть
  

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

Google -> bash color -> тысячи мануалов. Использовать поиск по назначению - не так уж и сложно, правда же?

Неужели для работы такого достаточно простенького кода придется обращаться к драйверам?

В играх - да, ибо там своя атмосфера с античитами и банхаммерами. Вам нужен драйвер пользовательского ввода в ядре ОС (ring0). А туда пускают только с подписью (ну или ломать систему). Ищите на форумах автоита - там вроде был такой. Альтернативный вариант - свой контроллёр в USB порт, прикидывающийся мышкой/клавиатурой и которым можно рулить через драйвер уже в пользовательском пространстве.

Подойдёт ли Windows Forms? Мне ведь потом на мобилку порт делать.

Формы - это .Net и только для винды. Причем это уже очень старое легаси, которое имеет смысл использовать только для поддержки Windows XP - а у нас тут уже поддержка 10 заканчивается так-то. А .Net - это прежде всего C#. И вот на C# есть более новый WPF и кроссплатформенный MAUI. Для мобилки все равно придется переписывать с нуля или искать какие-то варианты решений, которые могут C# в мобилки.

Или на мобилку лучше не на C++ делать? Что посоветуете?

Не самое лучшее решение - там родная платформа Java и Swift. Qt умеет: https://doc.qt.io/qt-6/mobiledevelopment.html - но как оно там в результате будет работать сложно сказать и можно ожидать каких-нибудь слабопрогнозируемых глюков и сложностей. Спасибо Adamos.

Может кому-то известны нюансы при постройке такой программы?

Известны и т.к. вы нуб - для вас весь ваш процесс разработки будет нюансом и тут уже попахивает как минимум долгосрочной регулярной консультацией или менторство.

В общем, у вас несколько вариантов. Вариант раз: если хотите именно плюсы - то вам следует использовать Qt и писать код сразу с учетом дальнейших доработок для работы в Linux, Mac и на мобилках - не знаю, как и на сколько хорошо Qt умеет в мобилки, но могут быть какие-то сложности/баги. Ну, в кроссплатформе от этого не уйти - придётся мириться и местами писать разный код для разных платформ.

Вариант два: если хотите сразу писать приложение сразу для всех платформ с единой кодовой базой и минимальными услиями - то можно использовать веб-платформы типа NWJS, Cordova и прочие браузерные платформы. Минус - приложение будет тяжёлым и ощутимо более медленным, чем нормальное нативное.

В целом, могу рекомендовать для начала просто сделать на плюсах с Qt хоть какое-то приложение для винды, далее внести доработки для работы в линуксе и маке. При наличии/доступности мака - можно сразу и для мака делать. Линукс прекрасно ставится и работает в VirtualBox и прочих виртуализаторах. Далее сделать поддержку сетевых фич, БД и прочего, а уже только потом переключаться на разработку для мобилок. При этом, вам надо будет организовать свой план разработки от меньшего к большему. Т.е., сначала самые простые функции делаете, а уже потом к ним добавляете что-то более сложное по мере изучения.

WinAPI -> user32.dll -> ShowWindow.