Freeman

Если известно, какому exe-файлу соответствует отладчик, ради эксперимента можно попробовать подредактировать ему манифест программой типа Resource Hacker. Оно нарушит цифровую подпись, конечно, но задачу, может, и решит, если программа потом тупо падать не будет.

Сам никогда не пробовал.

Заранее могу сказать, что подобный перевод умолчательной кодовой страницы нарушит вывод однобайтовых символов не в UTF-8. В данной программе, они, скорее всего будут отображаться символами-заменителями �����. Это никак не лечится: или простые однобайтовые символы навроде 1251, или UTF-8.

Можно попробовать написать что-нибудь под KolibriOS. Хорошо прочищает мозги.

Сервис — не про ООП.

Ни с какого. Если ребенок родился программистом, он начнет программировать сам.

На видео не нужно писать код, если это обучающее видео. И не нужно давать возможность скачивать код, написанный на видео.

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

Это не проблема Git, это проблема архитектуры вашего приложения. При нормальной реализации должно быть общее ядро и клиентозависимые расширения, а для поставки клиента собираться в единое целое тем или иным образом.

То, как вы сейчас делаете, похоже на реализацию двух разных приложений. Если хотите продолжать -- разделите хранилища, как вам уже предложили.

В СССР было два периода -- до "слива" и после.

Период до слива пришелся на ламповые и транзисторные ЭВМ, когда теории операционных систем и языков высокого уровня еще только разрабатывались. И мы, и американцы шли тогда методом научного тыка, но с точки зрения сегодняшнего дня было в чем-то проще, поскольку всё упиралось в ограниченные аппаратные возможности, поэтому объемы были мизерные и могли контролироваться вручную. Именно в те времена была создана троичная ЭВМ Брусенцова, про которую недавно писали.

Слив заключался в том, что при Хрущеве партия и правительство приказали собственные разработки закрыть и явочным порядком заставили копировать PDP, IBM и DEC. С этого момента мы начали отставать, и это продлилось до конца СССР. После распада лучшие разработки и лучшие умы США получили в качестве трофея.

Более-менее применимые к современным условиям разработки приходятся самый конец СССР -- буквально последние два-три года. Можете почитать про разработку кодовой страницы Windows-1251, книгу Зуева про разработку компилятора, найти что-нибудь по истории компании Excelior из Новосибирска, еще про встроенку какую-нибудь, вроде "Микроши" или БК.

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

А большой и сложный проект следующего поколения или по схожей тематике делается по аналогии с уже сделанным проектом, типа как Хабр → GeekTimes, Мегамозг, Тостер. Наработав опыт, авторы таких проектов уже не задают вопросов в интернетах.

Только DBGrid, StringGrid даже не рассматривайте. Берете какой-нибудь движок, умеющий представлять CSV-файлы как таблицы, и вперед. Раньше вроде BDE такое умела, а теперь ADO, если не изменяет память. Там то ли в строке подключения что-то хитрое указывается, то ли дополнительный файл с именами виртуальных полей создавать нужно. Гуглите, да обрящете.

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

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

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

Если дело настолько серьезно, поизучайте также на предмет инсайда и "кротов" в своем окружении.

В разработке своего языка я условно-виртуально учитываю опыт Рефала (поскольку тоже суперкомпилятор), но сам на нем не программировал и с программистами на Рефале встречаться пока не доводилось.

В черновиках блога сейчас лежит статья о суперкомпиляции в Канторе, но тема пока не развивается. Общение по теме могло бы стать толчком.

Такие устройства называют встраиваемыми системами, если я вас правильно понял.

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

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

Разработка игр -- в первую очередь проектная работа, и только во вторую -- программирование.

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