Станислав Макаров

Код программы или игры, используемые в ней изображения, звуки, сюжет, сеттинг, игровая система (например, Dungeon&Dragons) могут быть защищены копирайтом. Название может быть защищено торговой маркой. В остальном самостоятельно сделать аналог вполне законно. На идеи и алгоритмы в России авторское право не распространяется.

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

Попробуем ответить на первый.

А могул ли быть, А100000000000000h, то есть начаться с А

Да могут быть. В хекс-системе числа состоят из цифр и букв от A до F. Другое
дело что ты должен следить за разрядностью и понимать что в регистр процессора
(ассемблер) и тип данных (для шарпов) может влезать ограниченный диапазон
величин. Например для ассемблерного двойного слова (DWORD) максимальное число FFFFFFFFh
И для шарпового unsigned long максимальное 0xFFFF_FFFF_FFFF_FFFF

Тоесть правильный ответ состоит из проверки числа на допустимые символы и проверки
ТИПА данных на диапазон.

Поменяй: props.item.office на 'office' in props.item.
Ты не можешь обращаться к свойству которого нет сразу во всех типах union'a. Но ты можешь проверить его наличие, а дальше ts, в зависимости от результата, сузит тип до того, в котором оно присутствует.

Почему не переписать вместо этого
add ebx,dword ptr [rbp+ECX*4+10h]

Буквально так написать нельзя, потому что нет такого режима адресации в котором можно было бы использовать вместе Rbp (64-битный) и Ecx (32-битный). Можно было бы написать add ebx,dword ptr [rbp+rcx*4+10h], но для этого счётчик цикла должен был бы быть 64-битным, а он, как мы видим, 32-битный (int i). Т.е. ответ на вопрос "для чего это": для беззнакового расширения 32-битного счётчика цикла в регистр, который можно использовать для доступа к памяти.

Другое дело, что из исходного кода очевидно, что при обращениях к памяти i не выходит из диапазона 0..9, так что разницы между ecx и rcx нет и не может быть. Возможно я что-то упускаю и у компилятора другое мнение на этот счёт, но может быть он просто туповат и не имеет кода который бы мог использовать эту возможность оптимизации, а может такая оптимизация и есть, но она не была включена во время генерации этого кода.

В общем, чтобы не издеваться над девушкой, объясним на пальцах.

Во-первых, заголовок у вопроса чудовищно некорректный. Это все равно что спросить, "что быстрее - пылесос или стиральная машина?"
Во-вторых, ответ на вопрос "производить ли обработку данных в БД или же запросить все данные в клиентское приложение и обрабатывать там" совершенно очевиден: обработку данных следует производить в общем случае только в БД. Она для этого и придумана. Чтобы обрабатывать значительные объемы данных.

Да, js тоже "может" обрабатывать большие объемы данных.
Но чтобы значительный объем данных обработать, его сначала надо передать, полностью забив канал между сайтом и базой
Чтобы значительный объем данных обработать, его надо сначала проиндексировать. Причем делать это каждый раз, а не использовать уже имеющийся набор индексов
Чтобы значительный объем данных обработать, надо иметь значительный объем памяти или упасть из-за её недостатка
Чтобы значительный объем данных обработать в многопоточном режиме (а сайт как раз является многопоточной системой), все вышеперечисленное надо умножить на количество посетителей сайта - при каждом запросе перегонять весь массив данных, выделять память, индексировать, считать. Если же вы оставляете все данные в памяти приложения, то их тогда надо как-то синхронизировать с БД. То есть вы себе собираете кучу проблем на пустом месте.

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

Из всего изученного стало понятно, что процессы - это некие "контейнеры", содержащие id, статус, instruction pointer, значение регистров, открытые файлы и другие данные контекста.

Вот уже по этому предложению видно, что понятно не стало. instruction pointer и значения регистров -- свои у каждого потока.

какую роль в планировании играют процессы?

Никакой.

Для чего они нужны?

Для учёта ресурсов и создания изолированных адресных пространств.

Как планировщик ОС работает с процессами?

Никак.

Моя единственная догадка в том, что планировщик как бы "заглядывает" в каждый процесс и уже там работает с потоками.

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

Я думаю можно. Поищи такие компилляторы как Watcom C, Borland C.
Они умеют генерить код для DOS. На ваткоме кажется была написана
игра Doom for DOS.

UPD +Линка www.openwatcom.org

Нужно компилировать под DOS, а ты скомпилировал под Windows.
Каждая программа на Windows содержит в себе маленькую программу для DOS, которая выводит такое сообщение.

Скорее всего - тебе понадобится компилятор и среда разработки примерно из тех же годов, что и DOS

Модуль B использует данные из Модуля A

Что за данные?

смаке оперирует целями и зависимостями, а не данными.
Зависимости можно указать с помощью add_dependencies, подключить библиотеку с помощью target_link_libraries.
Если у вас в каком-то из модулей генерируются какие-то данные, то, видимо, там есть custom_target - укажите его в зависимостях вышележащего уровня.

И вообще, стоит ли так слепо следовать правилам из приведённой в начале статьи?

Разумеется не стоит. Делайте как того требует задача. Формат ошибок придумывать не надо. Мы например пришли к тому, что используем problemJson для ошибок.

Когда тебе понадобится зайти на белый IP из этой подсети, ты на него не попадешь, т.к. он будет искаться в первую очередь у тебя в локалке

.htaccess - это часть сервера, сфера ответственности команды эксплуатации
Обычно его создает/правит админ или бек-разработчик
Работает этот файл только с веб-сервером apache/httpd, к nginx отношения не имеет
Фронтенд-разработчики по идее никак с этим не связаны, это и близко не их сфера ответственности. Могут столкнуться, только если сами настраивают свое рабочее окружение и каким-то образом им помешал дефолтный .htaccess
Управление кешем с серверной стороны точно не относится к фронтенд-разработке