none7

Потому что номера прерываний в DOS принято записывать в шестнадцатеричном виде.
0x10 == 10₁₆ == 16₁₀

Как он, например, узнаёт, нажата ли кнопка? Для этого надо выполнять цикл как можно чаще

Как вы узнаёте утром, что надо просыпаться и идти на работу или в школу? Для этого надо всю ночь смотреть на часы как можно чаще. :)
А можно просто "сказать" будильнику (или родственникам), чтобы разбудили в нужное время. Вот так и программа доверяет операционной системе "разбудить" её, когда кто-то нажмёт на кнопку. А пока никто не нажал, программа спит и не тратит ресурсы.
Операционная система в любом случае знает обо всех нажатиях кнопок и обо всех движениях мыши, она решает, какой программе передать эти нажатия или движения, т.е. какую программу нужно разбудить сейчас. Как только программа обработает событие, она снова уснёт, если больше нечего обрабатывать.

свободное место вроде есть

148 кб в корне это не свободное место, а его отсутствие...

У вас программа скорее всего была собрана в конфигурации Debug, поэтому суфикс D в имени DLL. Отладочные библиотеки обычно не установлены у обычных юзеров, только у тех кто поставил Visual Studio.

Нужно просто сделать релизную сборку программы, я думаю. Если не сработает, то установить VC++ 2015 Redistributable на целевую машину или слинковать со стандартной библиотекой статически, как посоветовал res2001.

Прочитай в книге про переопределение ToString

public class Test
        {
            private string _text;
            public Test(string text)
            {
                this._text = text;
            }

            public override string ToString()
            {
                return _text;
            }
        }

var x = new Test("текст");
            Debug.WriteLine(x);

Всегда полезно проверять мин. макс. параметры всех значений и кидать исключение в случае чего.
А вообще, есть кейсы, где лучше поругаться на слишком большую длину сообщения.
Например, когда будете сохранять это сообщение в СУБД MySQL в поле типа данных varchar(10000) с превышением длины, то СУБД в случае превышения длины строки по тихому сохранит первые 10000 символов, а переполненную часть - нет. Так что лучше проверить длину сообщения, и если она не соответствует регламентированной, то не давать зеленый свет для обработки.

Ну во-первых точно не получится использовать стандартный Bitmap.
Хранить в куче такой большой объект тоже не следует, тк он 100% попадёт в LOH
+ в .NET есть ограничение в 2гб на объекты в управляемой куче.
Описанное вами изображение как раз в этот лимит и не влезет.

Остаётся два с половиной варианта:
1. Делить огромное изображение на чанки по меньше (либо по пикселям, либо по каналам, либо и так и так)
2. Хранить изображение в неуправляемой памяти, выделять и освобождать память вручную.
В .net 6 как раз добавили Native alloc API для этого.
3. Возможно есть какая-нибудь нативная библиотека для работы с большими изображениями.
Возможно даже уже есть обёртка для работы с ней.

Во всех случаях придётся отказаться от Bitmap и использовать другие подходы

без доп. библиотек и массива битмапов

Не получится

Ничего не будет. Ничего не заблокируется и не удалится

Была поддержка Windows XP в Visual Studio 2017. Нужно просто выбрать определенный toolset.