rPman

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

На практике, обычно так и делают, если у вас десктопное приложение и пользователи подключаются с его помощь к базе данных, можно запрашивать у них логин и пароль (т.е. строка подключения это только ip и порт БД), т.е. за авторизацию и аутентификацию будет отвечать БД.

p.s. парольная авторизация это пережиток прошлого ;) красивый пример - вы можете сделать авторизацию по qr-коду, генерируемым приложением на мобильном телефоне (а там таймкод по типу google authenticator) и снимать его через вебкамеру (подойдут даже самые дешевые, помню покупал одну за 70р, с подсветкой даже), коды авторизации выдавать пользователям при личной встрече.

Вы точно хорошо подумали, прежде чем выбрать такую странную смесь архитектур?
p.s. правда я и сам бы мог так сделать, если бы потребовалось писать сложный интерфейс, а вычислительная логика уже была бы на python, так как в visual studio на .net писать сложные формочки удобнее всего (имхо).

Если вас не интересует полноценная поддержка обновлений а так же вас не волнует что архив установки будет толстым (особенно это замечают когда будете делать частые обновления), тупо складывайте заранее установленный каталог python в отдельный каталог и пользуйтесь (максимум перед запуском переменные окружения прописывайте), в этом случае за обновление будете отвечать сами. Но даже в этом случае хорошим жестом будет являться предложение установки приложения без питона, ожидая его уже установленным на машине пользователя. Почему вариант таскать питон с собой плохой? - поддержка, через три десять лет, чтобы запустить ваше приложение с поддержкой современного оборудования, понадобится пуд соли и ершик для чистки унитаза (особенно это актуально для gpgpu/opencv подсистем).

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

Если у вас linux с нормальными пакетными менеджерами, пользуйтесь ими, и программными пакетами в их формате (apt/rpm/ebuild/..), и они сделают все необходимое за вас в лучшем виде! Если же windows...

В не кастрированных (не домашние) версиях windows10 можно попытаться запустить бинарники ubuntu/debian, если не требуется gui, это почти наверняка будет работать, т.е. вы можете использовать штатный пакетный менеджер apt, ив пару команд установить/обновить все все необходимое

Можете так же устанавливать python в тихом режиме, скачав установщик с сайта https://www.python.org/downloads/, это будет занимать меньше места, но в случае если вам нужны необычные модули, то вам может не повезти найти собранные под windows, да и те что есть, обычно требуют ручную установку.. в общем не все там легко автоматизируется, пути загрузок внезапно могут через год другой исчезнуть и пользователи получат проблему.

Универсально, можете воспользоваться готовой linux подсистемой для windows - cygwin (на столько долгой и качественной поддержки почти всего из мира windows в linux вы не найдете), и таскайте в своем установщике их setup.exe (кстати он всегда доступен для загрузки с сайта по одному и тому же url) в режиме Unattended setup mode (--quiet-mode), вместе с питоном вы получите базовый набор утилит командной строки и кучу еще чего теоретически лишнего, но поверьте, оно не помешает, особенно если вам нужна автоматизация процессов управления установкой на машине клиента.

Запустить браузер на c# дело 3 кликов мышки (контрол WebBrowser), чуть сложнее будет симулировать ввод запроса, точнее найти в какие input необходимо вставить текст и какую нажать.

Все действия лучше симулировать на javascript внутри этого браузера (хотя есть возможность работать с DOM прямо из c#, на чтение это оправдано но на изменения могут возникать не очивидные глюки в общем случае), запуская через onTimeout с нулевой задержкой.

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

p.s. Когда то давно делал приложение, которое делало десятки запросов в минуту, использовались сразу несколько ip адресов гугла по очереди чтобы избежать бана за частоту запросов, симуляция была на основе curl, тот еще квест, а главное поддерживать это было нудно, поисковики меняются постоянно, лучше уж как я выше написал.

В общем случае никак! pdf это считай картинка с опционально текстовой информацией.

В вашем случае можно попробовать конвертировать pdf файл в картинки, вырезать из определенной области кусок (imagemagic) и отправить его на распознавание с помощью того же tesseract.

вам необходимо сформировать валидный поток данных например несжатых данных по этому rfc
https://tools.ietf.org/html/rfc4175

Возможно что 1080p60fps несжатый поток обработать на c# будет проблематично и лучше найти готовые библиотеки для этого

p.s. попробуйте воспользоваться пайпами (правда с этим могут быть проблемы на windows, с правами например)
https://stackoverflow.com/questions/51903888/is-it...

Когда то давным давно, еще до WFP используя обычные Windows Forms и классы Dataset писал сложную прослойку-кеш для базы данных, десятки таблиц. Речь шла о 'покликать лениво мышкой', вся база в памяти, сохранение штатным сериализатором (в ту же xml - две строчки кода), сотни мегабайт, работало с приемлемой скоростью.

p.s. Сказано что без sql? берите любую готовую nosql базу данных ;) например redis

Подключение обычные tcp сокеты (в udp пока не лезте, но с ними тоже реально).

На сервер передаете только нажатые кнопки пользователей, буквально, побайтно (назначьте коды на все возможные действия пользователей, досканально, в зависимости от вашего игрового процесса это могут быть даже нажал кнопку - отпустил кнопку).

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

На клиенте перерисовываете все это каждый раз как получаете данные от сервера.

Вся игра должна крутиться на сервере, тогда у вас не будет никаких проблем с расинхронизацией, читерством (кроме автоматизации) и прочим.

Недостаток - у всех пользователей будет небольшой лаг на действия, в зависимости от пингов.

К сожалению не все игры можно так реализовать, но частично да.

это вообще фича операционной системы, и точно знаю в win98 (плюсом) и в winxp это настраивалось твиками.

Смешная идея - javascript pdf viewer загрузить в WebBrowser, туда же закинуть свой pdf-файл
viewerjs.org
https://habrahabr.ru/post/122034/
и т.п.

Если сравнивать c# и java именно в направлении разработки desktop приложений, то c# объективно выигрывает.

Нет особой разницы на чем реализовывать вашу задачу, но лично мне удобнее клепать формочки на древнючем WinForms, чем на той же java fx (даже с использованием GUI построителей) реально меньше телодвижений, проще изучение, идеологические баги все простые.

Доступ к данным именно microsoft office это фигня, хотя я очень редко но встречал проблемные документы, доступ к данным которых был только из запущенного офиса средствами его языка (или interprop communication в c#, когда запускается скрытый офис и язык имеет доступ к объектам самого офиса и открытого документа), на java кажется это будет еще менее удобно.

Ваша задача очень эффективно решается обычным файлом на диске (открытый с запретом lazy writes, либо принудительным flush после каждой записи). Если инструментарий (язык программирования и библиотеки) позволяет - откройте файл маппингом на память.
Индекс для таких запросов не нужен, ведь ячейки можно индексировать примитивно - (x+maxx*y). запрос 100x100 блока превращается в 100 быстрых чтений по 100байт. Если это оправдано, можно хранить не ячейки а блоки 100x100, тогда при чтении будет читаться в 4 раза больше данных но четырьмя чтениями. Но если блок данных экрана влезает в буфер опережающего чтения операционной системы (драйвере файловой системы) то такой метод хранения будет неактуален.

Любой другой метод будет медленный либо по записи (например хранить в базе не ячейки а блоки 100x100, соответственно при запросе блока будут считываться четыре соседних), либо медленный по чтению (хранить по одной записи на ячейку) и не эффективный по месту на диске.

sqlite — одна из самых медленных реализаций на запись (на средней win машине от 100ms на транзакцию), даже у ms access быстрее, но чтение шустрое, плюс совместимость высокая (если нужно отдельный файл, значит нужно переносить с машины на машину? а sqlite есть под ВСЕ платформы)

nosql вообще сложно сравнивать с sql, наибольшая скорость (на порядок выше sql), но key -> value создает ограничения, и имеет смысл в основном для document-oriented баз данных, т.е. если у вас есть 1->m то придется сериализовать списки и следить за целостностью самим.