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

Все предельно просто - dependency properties это попытка получить реактивное программирование конкретно в рамках WPF и с минимальными затратами (без модификаций на уровне языков/платформы .net).

Вы формулами в Экселе когда-нибудь пользовались? Вида =A1+A2+A3? Когда обновляешь ячейку A1 и автоматически обновляются все значения, вычисляемые по формулам, в которых встречается A1. Вот это примерно то же самое. Почему это так важно в WPF? Потому что а) это естественный способ связи свойств визуальных компонент друг с другом и с ViewModel-ью - без свойств зависимостей обновление зависимых значений превращается в адские цепочки Refresh-ей, Recalc-ов и прочего, и дай бог не забыть вызвать все нужные пересчеты. б) это дает механизм абстрагированной обработки и изменения свойств объектов (как правило - контролов), более производительный и узкоспециализированный по сравнению со стандартной рефлексией. Это, в свою очередь, обеспечивает возможность без лишних заморочек написать классы вроде DoubleAnimation, с помощью которого можно анимировать ЛЮБОЕ (!) свойство типа double у любого объекта, лишь бы оно было dependency property.

Значит возможен ли UI с помощью html, css и js?

Возможен: Atom, VS Code и прочие приложения на Electron-е (не только они, разумеется, это как пример).

Ходят слухи что WPF, помирает и толк его использования, сходит на нет.

Не делайте поверхностных выводов. WPF это ж не какой-нидь дед старый, который когда помирает, мало чем уже семье помочь может. Если технология просто не так активно развивается, это не значит, что она по определению в хвосте какой-либо другой.
Все, кто использует HTML для десктопного интерфейса это те, кто хочет а) кроссплатформенности; б) сделать свою софтину hackable, например чтобы можно было всякие плагины писать на js, и тем самым понравиться своим клиентам-разработчикам. Ну и еще в) те, кто кроме html+js стека ничего не знает, а декстопа тоже хочется ("мы же тоже люди").

www.batstrading.com
А некоторые крупные брокеры, например CQG, сами помогут в этом вопросе: https://develop.cqg.com/qd/?page=ContinuumDocumentation

XSpider

1) в рамках roaming-профиля должна перемещаться папка %USERNAME%\AppData\Roaming, она для этого и была сделана; все адекватные приложения кладут все, что должно ездить вместе с пользователем, сюда. В т.ч. настройки, если они не в реестре;
2) в аутлуке файл данных всегда можно положить куда душе угодно. Дефолтовое расположение для PST-шек - это Outlook Files в подпапке Documents, которая вроде как уже у вас ездит. OST-шки лежат в AppData\Local и роумингу не подлежат, т.к. представляют собой локальный кэш IMAP-аккаунтов.

В целом, заменить можно на QDesktopWidget , но придется как-то уйти от использования класса Display, указатель на объект которого возвращается методом display(). Нужно разбираться, что за функция XRRGetScreenInfo, и как она этим Display пользуется. Возможно, будет достаточно свойства primaryScreen для получения номера главного экрана и метода screenGeometry(int screen).

А откуда берётся этот MSIL? Куда компилируются .cs?

cs компилируются компилятором. Есть стандартный csc, поставляется вместе с .net framework (НЕ со студией). Это "классический" компилятор от MS, написан на C++, с закрытым исходным кодом. Такой же есть и для Visual Basic. Кроме них есть еще Roslyn-компиляторы C# и VB, они open-source, их главное отличие в том, что они сами написаны на управляемых языках. Это значит, что у вас есть compiler-as-a-service. Это, в свою очередь, значит, что если вы хотите написать тулзу, обрабатывающую тем или иным образом исходный код, например на C#, вам не нужно самому писать парсер/компилятор, вы можете подключить модули Roslyn-компилятора и пользоваться ТЕМ ЖЕ компилятором (лексером/парсером/etc), что и используется непосредственно при сборке приложения. С классическим компилятором так не получится, он представляет из себя черный ящик: cs на входе, сборка на выходе.

Далее будем считать, что не учитываем в рассуждениях технологию .net native.

в каком моменте тогда работает виртуальная машина

она работает в момент запуска exe.

почему мы получаем на выходе .exe

в этом вопросе часто возникает путаница. Дело в том, что дотнетовские exe и dll - это т.н. сборки (assemblies), и они содержат метаданные и MSIL (!) исполняемый код. То, что у них расширения exe и dll - это потому, что MS для повышения совместимости и удобства использования, упаковала их в формат PE. Чтобы .net приложения можно было запускать также, как и нативные. НО реально в exe-файле есть только небольшой загрузчик, который запускает CLR, просит загрузить текущий файл как дотнет-сборку и передать управление на метод-точку входа. Почитайте про сборки в хорошей книге, и скачайте dotPeek, посмотрите что внутри дотнетовского exe. Это совсем не то, что в "обычном", нативном exe.

В мире C# существуют также такие понятия как .NET, Mono, Roslyn и т.д., можете ли вы структурированно разъяснить их смысл?

.NET это название и бренд платформы, .NET Framework, а теперь и .NET Core - реализации платформы от MS, Mono - open-source реализация НЕ от MS. .NET FW работает только на винде, .NET Core и Mono и на других платформах. Про Roslyn уже упомянул.

Ну начнем с того, что 10000 итераций на современном процессоре выполнится настолько быстро, что вероятно уложится в отведенный потоку квант времени, и второй поток скорее всего даже не успеет получить процессорное время, чтобы поменять вашу переменную. Поэтому ИСКЛЮЧИТЕЛЬНО в целях эксперимента можете попробовать увеличить число итераций хотя бы до 10 миллионов, и отключить по максимуму оптимизации (не по причине скорости, а по причине потенциального выбрасывания кода компилятором), т.к. наверняка количество итераций есть причина неудачи в вашем эксперименте.

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

С архитектурной точки зрения, если у вас снятие показаний, то у вас просто классический случай producer-consumer - впилите потокобезопасную очередь, и пользуйтесь.

Знаю что есть библиотеки ACE, POCO, BOOST(гуглил), но ничего про них не знаю больше.

ну так узнайте! Узнайте про Boost::Asio, узнайте про cpp-netlib, построенную поверх него (как раз будет вам HTTP клиент и сервер)

А чего тут думать. Ну введите некое условное обозначение зума, например 1 - это минимальное увеличение, как сейчас. Также введите точку - центр viewport-а, куда смотрит пользователь. В зависимости от значения масштаба, отрисовывать дни/часы или минуты. Отрисовывать только то, что видно через вьюпорт. Таким образом у вас получится длинный-предлинный календарь, в каждый момент времени вы будете видеть лишь его фрагмент. Ну как тайловых картах сделано.

devenv.exe /resetsettings
devenv.exe /resetskippkgs

К teugen добавлю, что если вы используете не значение класса/структуры, а указатель на него, то в хедер вместо инклуда другого хедера можно вставить объявление класса:

#pragma once
class ExampleClass;
class MyClass {
public:
 ExampleClass* ExampleFunction();
};

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

1. Аналогию с самими языками проводить не стоит. Аналогию стоит провести для платформ.
Платформы вроде .net и java, которые разрабатывались для энтерпрайза, разумеется лучше для него подходят. И не важно даже, десктопное у вас приложение или веб-сервис. Важно, что в платформе есть поддержка нужных стандартов и технологий с гарантией качества от производителя.
С другой стороны, многие компоненты таких платформ это closed-source. Поэтому, если вы не банк, а стартап, то для веб-сервиса выбирайте
Ruby или Python.
Социальную сеть можно сделать много на чем, но я бы делал на рельсах или джанге. А вот функционал сбербанк-онлайн я бы делал на ASP.NET MVC (т.е. на C#) или на джаве (на спринге например). Однако, тот же близзовский battle.net написан на спринге (сервер когда-то случайно отдал мне stack-trace после ошибки).

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

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

3. На PHP много чего нельзя сделать. Вернее, КАК БЫ можно все, но нормально можно только веб. Именно поэтому для меня он не язык, а какой-то шаблонизатор - слишком у него дурная история и связь с веб (что нехорошо для языка общего назначения). Конечно, современные веб-фреймворки его очень хорошо причесывают, что даже можно работать с ним, но мы же о языках говорим..

4. Для веб-проектов между Ruby, Python и PHP человек бы выбирал исходя из своих умений. У каждого языка своя экосистема (библиотеки, пакетные менеджеры, серверы приложений/плагины для веб-сервера) и довольно непросто знать все сразу. Именно поэтому все расходятся по своим лагерям и просто работают. Первичный выбор языка часто определяет его популярность. Лет 5 назад Руби всех рвал за счет Рельсов, сегодня Питон и PHP подтянулись в плане экосистемы, поэтому ситуация уже другая.
Если человек таки сумел познакомиться с разными языками, он выберет тот, в котором ему проще мыслить. Модель ООП, статическая/динамическая типизация - все это определяет ощущения КОНКРЕТНОГО человека от КОНКРЕТНОГО языка.

5. PHP учится быстрее всех, но если вы не знаете других нормальных языков, лучше его не учите - испортитесь как программист. Python и Ruby учатся примерно одинаково. Изучение C++ - совсем другая история, я бы не ставил его в один ряд с Питоном - этот язык несколько другого уровня и требует других (более глубоких) знаний о вычислительной технике (т.е. он 100% учится дольше, чем Python).