Славка

В общем случае способ передачи нотификаций из модели во ViewModel не регламентируется паттерном MVVM. Как это лучше всего осуществлять - зависит от вашей задачи.

Возможно ViewModel будет сама знать о том, когда и в каком случае какие свойства модели изменяются и сама будет генерировать необходимые события PropertyChanged.
Возможно в модели будут специфичные для конкретной задачи ивенты (например, модель будет вызывать PlayerMoveCompleted когда игрок сделает ход), на которые будет подписана ViewModel и будет, в свою очередь, генерировать необходимые PropertyChanged.
Некоторые советуют в модели также реализовать INotifyPropertyChanged, но лично мне этот способ не нравится: во-первых, в модель начинает подмешиваться UI, что обычно нехорошо, а во-вторых - нотификация о смене значений конкретных пропертей это всё-таки задача ViewModel, и я не вижу смысла размазывать её ещё и на модель. Последняя должна содержать только специфичные для предметной области вещи.

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

Обязательно добавить в список прочтения "Принципы, паттерны и методики гибкой разработки на языке C#" ISBN 978-5-93286-197-4, 978-0-13-185725-4 . Узнаете как нужно применять инструменты языка. И как НЕ нужно.

Это всё отличные книги.

У Скита показано как развивался язык C#, о чём думали его разработчики. Это даёт очень целостную картину.

Албахари — один из лучших выборов, если надо разобраться с каким-то вопросом здесь и сейчас. Покрыты практически все темы. Естественно, где-то может не хватать глубины, зато всё чётко и практично.

Рихтер — классика. Там где не хватает глубины у Албахари, Рихтер её обеспечит. Здорово для "лёгкого" чтения перед сном, когда хочется что-то просто понять для себя.

А у MVVM нет общих правил, каждый реализовывает его по-разному.

Ну я б не говорил, что их прям нет. Есть привязки, есть INotifyPropertyChanged, есть рекомендации от MS. Да, вы правы в том смысле, что WPF это библиотека, но НЕ фреймворк для разработки, т.е. она не регламентирует структуру приложения.

И у меня диссонанс — что сначала изучать, куда копать, что вообще делать, что стоит изучать, а что нет.

Вот пару дней назад советовал книгу: Raffaele Garofalo, "Building Enterprise Applicatio... - если ничего не читали еще, начните с неё.

И действительно хороших, многофункциональных и понятных проектов на WPF + MVVM я не видел.

Неудивительно: WPF-приложения это обычно line-of-business, а это не open-source по определению.

С чего начать изучение WPF?

Убедитесь, что более-менее понимаете платформу .NET и ООП в ней, иначе будет тяжело.
Вам надо будет разобраться:
а) с системой зависимых свойств (dependency property);
б) c MVVM и INotifyPropertyChanged;
в) само собой с XAML и контролами, принципами написания своих контролов;
г) со стилями и стилизацией;
д) с системой команд (ICommand) и прочим.

Нужны ли MVVM-фреймворки? Почему столько дискуссии возникает. Одни говорят да, другие — нет.

Дискуссии возникают потому что а) некоторые вещи можно сделать разными способами; б) разработчики имеют дело с приложениями разного размера и сложности, но редко об этом задумываются в спорах; в) опытные разработчики нередко сами себя уже обеспечили нужным "библиотечным" пока разрабатывали приложения (ViewModelBase, хах :) ). Лучше пока разберитесь сами как что работает, потом поймете, какой фреймворк вам пригодится.

Впоследствии еще советую познакомиться с IoC-контейнерами, если еще не пользовались. Это общий совет для крупных приложений, не только для WPF. Некоторые имеют спецальные интеграционные библиотеки для работы на пару с фреймворками, например Autofac: Prism.Autofac.

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

Ух, он вам не нужен (RTlinux)! Тем более, он не развивается уже лет 10-15.
Более того, когда, еще в 1999 году проводили тестирование реалтайм функциональности линукса в разных вариантах, сравнивая их с настоящими ОСРВ, то отличий стандартных RT функций ядра, разных RT-расширений и большинства функционала коммерческих ОСРВ - не нашли! Вот моя, сильно порезанная статья того времени - www.osp.ru/os/1999/09-10/177813
Из нее выкинули, по коммерческим причинам, все тесты, упоминания и сравнения с коммерческими ОСРВ (я всё-таки их не буду называть, по этическим соображениям).
В общем, просто рекомендую пользовать стандартный шедулер и не париться. Ну а если не будет хватать, если еще куча специализированных шедулеров, заточенных на РВ, в разных вариациях.
Если все нужно в коммерческом смысле, то есть и куча дистрибутивов, типа MontaVista Linux, оптимизированных под очень серьезные задачи, с допиленными шедулерами, собственными стеками и IPC.

Не обязательно. Но лучше, да, правильно и красиво.

https://6002x.mitx.mit.edu/ пройдите этот курс, например, если дружите с английским.
если нет, для схемотехники прочтите "Искусство схемотехники" Хоровица и Хилла, и, как выше уже посоветовали, курс Харрисов.

Харрис и Харрис «Цифровая схемотехника и архитектура компьютера»
Там про всё и то, что вам нужно - тоже. Правда архитектура mips, но в вашем случае это скорее даже плюс.

Список библиотек / фреймворков на чистом C и книг (в конце)
https://github.com/peko/awesome-c

Указаны ссылки на издания на английском, если с ним проблемы, можно по названию поискать в переводе версии.

1. Если это COM библиотека, что может регистрироваться через regsvr32, то вам должны быть доступны следующие функции.
DllCanUnloadNow, DllGetClassObject, DllRegisterServer, DllUnregisterServer
Через DllGetClassObject можно создать COM обьект, зная его IID.
Если это обычная библиотека, то тогда может быть и OpenConnection. (Хотя разработчики могут и с COM серверами экспортировать иные функции, но как правило это не делают)
2. Если COM сервер правильно зарегистрирован, то не нужно загружать библиотеку самостоятельно, можно создать обьект через CoCreateInstance
3. Если это обычная библиотека, то вы можете ее загрузить только если она соотвествует разрядности текущего процесса. То есть 32х битные, только 32х битными приложениями, а 64х только из 64х битного.

Возникает вопрос. Это простой DLL с торчащими наружу функциями или COM?
• QLibrary — для DLL.
• regsvr32 — это для COM.
• Первый раз не загрузилось и второй раз загрузилось, потому что 32-битные программы со стандартным манифестом принимают каталог «SysWOW64» за «System32». Когда DLL не найден, программа отыскивает его в некоторых стандартных местах и таковыми, возможно, являются и активные COM-серверы.
• OpenConnection мог не найтись по адовой куче причин. Может оказаться, что имя OpenConnection «покозявлено» и надо что-то типа «OpenConnection@4». Может оказаться, что библиотека — действительно COM-сервер и QLibrary тут бесполезен.