Да не дай бог. «xcopy deployment» отличается от «portable» и очень существенно: портабл приложения таскают свои настройки с собой, а значит требуют прав на запись в собственный каталог.

Недостаток скевоморфизма еще и в том, что ДАЛЕКО не у всех есть «нужные» ассоциации с реальным миром. Одна из базовых метафор, которые сейчас применяются повсеместно — это папка.
Вот так выглядели папки в Windows 95:


Странные желтые прямоугольники с выступом сверху. У меня не было ВООБЩЕ никаких ассоциаций, потому что для меня папка выглядела так:


Обязательно с завязочкой и надписями «Дело номер» и «Хранить… лет». Что не помешало мне понять концепцию каталога в отрыве от реального мира вообще.

Более того, в современном мире концепции из «цифрового мира» многим гораздо ближе, чем из «реального». Дискетка — сейчас означает «сохранить» и никак не связана с теми пластиковыми квадратиками, которые были в обращении 10-15 лет назад (то есть она уже не скевоморф, а просто общепринятая пиктограмма). Из-за консумеризации IT даже если в то время человек был во вполне сознательном возрасте, он все равно может не иметь никаких ассоциаций просто потому что был далек от этого.

Готов поспорить, что существует немало людей, ни разу в жизни не видевших лупу, но прекрасно понимающих пиктограмму «Искать». Примеров масса

Кроме того, иногда в погоне за метафорами из «реального мира» люди доходят до маразма. Я НИ РАЗУ не видел реального отрывного календаря в коже со строчкой. И это не говоря уже о капельках-кнопках и леденцовых прогрессбарах.

где например?

Генераторов конечных автоматов? Да полно. Не говоря уже о том, что они тривиально пишутся вручную (до UMS общего назначения там все таки далековато).

Как вы реализуете полноценную system-wide event-driven

Active scheduler — он все ж таки для каждого потока свой. О какой именно «system wide» Вы сейчас говорите? То что процессы могут слать друг другу сообщения (так это присутствует ВО ВСЕХ UI фреймворках — даже Win16).

И да, Active Objects это действительно не кооперативная многозадачность, строго говоря там нет ко-операции, выполнение активного объекта это гарантированно атомарная операция.

Так это практически определение кооперативной многозадачности — ВСЕ операции атомарны, потому что В ПРИНЦИПЕ не могут прерваться (быть вытесненными).

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

Нет, я согласен с Вами, что раз есть подобное поле, оно должно быть правильно заполнено. Я к тому, что не только Внуково должно проверять данные о рейсах (никто не спорит, что они должны), но и Вы сами — деньги то немалые. И вот как раз в данном случае можно даже не копать Орбитсы, Каяки и Тревелосити: для того, чтобы совершить внутренний рейс 100% нужно выйти из транзитной зоны.

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

А чего гадать то? В аэропортах по всему миру есть разделение на внутренние и международные терминалы. Так что для перелета из Цюриха в Женеву нужно выйти из международного терминала и зайти во внутренний. Для выхода из международного терминала, собственно, и нужно пройти таможню — никаких сюрпризов здесь нет. Сюрпризы бывают в некоторых странах (в частности, насколько я помню, США), в которых даже для чисто транзитного международного рейса (влетел из одной страны, вылетел в третью) нужно проходить таможенный контроль и иметь визу.

В Symbian тоже процессы-потоки. Что же до кооперативной многозадачности и юзермод скедьюленга (вернее там даже не столько полноценный UMS, сколько подобие стейт машин) — так этого добра полно кругом, просто никто не ЗАСТАВЛЯЕТ его использовать. Более того, реактивная (event driven) модель вообще не привязана к способу переключения контекстов — она отлично реализуется и в «устаревших» преемптивных планировщиках (который, опять же, в Симбиане, тоже есть, но используется по минимуму). В отличие от Симбиана. Нет, спасибо, я уж как нибудь сам решу какую модель конкурентного исполнения мне использовать.

Короче, говорить о том, что кооперативная многозадачность вообще самая передовая технология (в отличие от «морально и архитектурно устаревшей» вытесняющей) — это где-то за гранью.

С отсутствием исключений в C++ я еще готов смириться — действительно довольно дорогая штука и для эмбеда может быть тяжеловатой, но вот заменять удобный, надежный и читаемый RAII кашей с CleanupStack-ами — это тоже весьма, э-э-э-э… неочевидное решение.

Фишка в том, что в WinCE можно все то же, что можно в Симбиане плюс еще до фига чего сверху.

Кстати, наткнулся сейчас на забавный пост в целом описывает мои собственные ощущения (да, 2005-й год, но мы же говорим об АРХИТЕКТУРЕ, а не о надстройках, которые пытаются скрыть внутреннее убожество)

Скажите, что Вы знаете об архитектуре WinCE и архитектуре Symbian?
WinCE — настоящее hard real-time микроядро (правда в CE6 для повышения производительности появилась ВОЗМОЖНОСТЬ, но не необходимость, исполнять драйверы в адресном пространстве ядра, а также некоторые usermode сервисы были перенесены опять же ядро). Средства разработки: полноценный C++ (с кучей библиотек, включая MFC, WTL и да, включая тот же QT), полноценный (почти) дотнет, несколько ява-машин на любой вкус — ME, SE, полноценный эмулятор, удаленный отладчик и прочие радости жизни.

Symbian — вроде бы и микроядро, но потоки считаются дорогими и поэтому НАСТОЯТЕЛЬНО рекомендуется использовать везде, где можно кооперативную многозадачность в виде Active Objects, убогий диалект C++ с убогим эмулятором (хех, имел счастье писать под него — ОФИЦИАЛЬНЫЙ семпл из SDK работал в эмуляторе, но не работал на реальном девайсе), а какую непередаваемую радость приносило ручное управление временем жизни всех объектов через CleanupStack-и — вот заставить бы всех таких «икспертов», защищающих Symbian остаток жизни писать для этого самого Симбиана — вот была бы потеха.

Уж не знаю, как там все сложится на рынке, но, как человек, который разрабатывал под обе платформы (и под многое другое), я рад, что WinPhone перешел на NT, а Сибиан сдох медленно и мучительно.

С изобретением Smalltalk, Аллан не просто изобрел язык программирования; он придумал всю концепцию Объектно Ориентированного Программирования (ООП) и впервые реализовал ее.

Как я сказал выше, Алан Кей изобрел Smalltalk одновременно с объектно-ориентированным программированием, когда работал в Xerox PARC в начале 1970х.

Што? А это тогда что? Вы, наверное, введены в заблуждение его известной фразой о C++. Если посмотреть на эту самую фразу внимательно, увидим, что Кей говорит о том, что является автором ТЕРМИНА ООП, а не самого ООП. Так то ООП впервые появилось в своем «классовом виде» в алголоподобной Симуле, откуда перекочевала с незначительными изменениями в тот самый C++ (что не только несложно заметить самостоятельно, но еще Страуструп сам неоднократно признавался, что именно Симула оказала наибольшее влияние на дизайн «C with classes»), о котором Кей так пренебрежительно отзывался.

Так что при всей моей любви к message passing и «first class» классам, именно Кей является «отступником от изначального ООП».

Пара замечаний.

malloc в VC рантайме — это очень тонкий слой над HeapAlloc (_malloc_base->_heap_alloc->HeapAlloc), который в свою очередь является субаллокатором над VirtualAlloc (VirtualAlloc умеет выделять только страницами, а Heap Manager затем «нарезает» эти страницы на блоки меньшего размера по требованию клиента). В данном случае единственное существенное отличие от Linux в том, что Windows память коммитит, а Linux — оверкоммитит (по умолчанию).

Простейший тест:

#include <Windows.h>
#include <psapi.h>
#include <memory.h>
#include <stdio.h>

int
main() {
	PROCESS_MEMORY_COUNTERS pmc = {};

	GetProcessMemoryInfo(GetCurrentProcess(), &pmc, sizeof(pmc));
	printf("WS: %d\tPeak WS: %d\tCommit: %d\tPeak commit: %d\n", pmc.WorkingSetSize, pmc.PeakWorkingSetSize, pmc.PagefileUsage, pmc.PeakPagefileUsage);

	auto mem = malloc(1024 * 1024 * 1024);
	printf("malloc(1Gb) - %s\n", (mem != nullptr) ? "check" : "uncheck");

	ZeroMemory(&pmc, sizeof(pmc));
	GetProcessMemoryInfo(GetCurrentProcess(), &pmc, sizeof(pmc));
	printf("WS: %d\tPeak WS: %d\tCommit: %d\tPeak commit: %d\n", pmc.WorkingSetSize, pmc.PeakWorkingSetSize, pmc.PagefileUsage, pmc.PeakPagefileUsage);

	if (mem != nullptr) {
		free(mem);
		mem = nullptr;
		printf("Fre-e-e-e-e-edom\n");

		ZeroMemory(&pmc, sizeof(pmc));
		GetProcessMemoryInfo(GetCurrentProcess(), &pmc, sizeof(pmc));
		printf("WS: %d\tPeak WS: %d\tCommit: %d\tPeak commit: %d\n", pmc.WorkingSetSize, pmc.PeakWorkingSetSize, pmc.PagefileUsage, pmc.PeakPagefileUsage);
	}
}

выдает следующее:

Current: 1445888	Peak: 1445888	Commit: 315392	Peak commit: 315392
malloc(1Gb) - check
Current: 3588096	Peak: 3588096	Commit: 1076162560	Peak commit: 1076162560
Fre-e-e-e-e-edom
Current: 1482752	Peak: 3588096	Commit: 315392	Peak commit: 1076162560

Как минимум в Windows affinity mask на процессе или потоке является обязательной к «исполнению». То есть поток всегда планируется ТОЛЬКО на процессорах, входящих в маску/группу.

Измерения проводились на HP ProLiant 360 G7 с двумя Intel Xeon X5690

Как видите, разница составляет всего чуть более 5%! Результат приятно удивительный. И это – случай максимальной разницы, достигаемый при 32 одновременно работающих потоках с запросами

Просто хочу уточнить, этот случай является худшим только с точки зрения самого теста (100% local vs 100% remote, не совсем понимаю при чем здесь количество потоков — наверное я что-то упускаю из виду). Все таки два Xeon-а в одном пакете — это далеко не худший случай с т.з. тестового окружения. На больших блейдах скорость доступа может отличаться в разы или даже на порядок.

Ну здесь ситуация та же, что и с айпадом: есть любители доказывать, что на нем и музыку «серьезную» пишут и фотки постобрабатывают. Фишка в том, что если в Excel можно рисовать то это еще не значит, что он был создан для рисования (или, что он может выступать полноценной заменой тому же иллюстратору).

Code Writer по всем параметрам уступает даже Notepad++, не говоря уже о серьезных IDE. Fresh Paint — разукрашка для детей. Клевая, но все равно разукрашка и уступает по возможностям даже Paint.Net не говоря уже о создании серьезного контента. OneNote MX — довольно удобен, но лучше все таки с пером, да и заметки я бы все таки относил к потреблению контента (заметки делаются О КОНТЕНТЕ, а не сами являются полноценным контентом). Графолит не пробовал, но судя по сайту — тоже выглядит достаточно удобно для простых случаев.

А почему руки должны уставать? Они ж все время на клавиатуре. Просто когда на экране появляется диалог — проще быстро ткнуть в него пальцем, чем тащить к нему курсор на тачпаде. Еще очень удобно скролить/зумить картинки/браузер.

Но кнопки поиск — нет. Совсем. Разумеется можно искать в магазине приложений в отдельном меню слева, но это нисколько не интуитивно понятно

Ну, во-певых, Search Charm — это основной метод поиска вообще везде, и «неинтуитивно» оно только потому, что еще нет привычки. А во-вторых, попробуйте сразу же после запуска стора набрать какой нибудь текст (по аналогии с поиском по стартовому экрану).

Если в win7 все приложения отображались на панели задач и переключение между ними занимало секунду — две, то теперь при переключении между приложениями надо удерживать alt и судорожно искать требуемую иконку, которые в зависимости от активности окон постоянно меняют свое положение.

Не совсем понял, что Вы имели в виду. Весь классический десктоп — это отдельное «приложение» (вот как браузер — приложение одно, а табов много и у каждого из табов свой контекст и свой воркфолу). Переход между приложениями Win-Tab (или левые углы). Лично мне клик в левом верхнем углу почему то гораздо удобнее, чем старый альт-таб.

Вы используете Windows Metro Desktop вместо старого рабочего стола?

Вы только что придумали собственное название, ну да ладно, я не о том. Откуда вообще появилось мнение, что Modern окружение когда нибудь заменит Classic? Представители Microsoft разных уровней (включая, насколько я помню, самого Синофски пока он еще представлял Microsoft) неоднократно говорили, что Modern — в основном для «потребления» контента. Пока люди будут использовать PC для создания контента классический десктоп никуда не денется.

Откуда вообще появилось мнение, что Modern — только «для пальцев»? Напоминает нытье при появлении мыши: «А-а-а-а-а, мне дали новый метод ввода и теперь я так растерян: я не могу использовать клавиатуру и мышь одновременно.» или еще лучше «Нет, я, конечно, профессионал и справился с этой невероятной сложностью, но средний пользователь ни за что не примет таких изменений». Да КТО МЕШАЕТ пользоваться тачем, мышью и клавиатурой (или даже голосовым вводом) одновременно. Каждый метод ввода для задач, которые удобнее решать именно с его помощью.

Вообще, пользовался Win8 задолго до официального выхода. Поначалу Start Screen действительно был непривычным. Привык дня за 3 и сейчас уже Win7 Start Menu воспринимается как куцее и неудобное — и очень хорошо, что я им никогда толком не пользовался (и не пользуюсь) ни для чего кроме поиска (собственно, ни для чего другого оно толком и не предназначено).

Использовал Win8 на всех классах устройств, которые есть на рынке: десктопы (с одним, двумя и тремя мониторами), лаптопы без тача, лаптопы с тачем, x86 таблетки (с пером и без пера), ARM таблетки. Modern приложениями пользуюсь часто: примерно половина Bing приложений (Weather, News, Finance, Maps, сам Bing, периодически заглядываю в Travel), пользуюсь Mail и Calendar в качестве основной почты (Live и GMail) и календаря (дома, для работы все таки несколько не дотягивают по возможностям), Trackage, MyTime, Freda/BookBazaar, Reader, Xbox SmartGlass, PRadio и т.д… Ну и куча простеньких игр (Cut the Rope, Fruit Ninja, Wordament, Radiant/Radian Defence, Chess4All, Doodle God, Minesweeper, Armed, Blocked In, Angry Birds, etc.).

Прямо сейчас пишу с бестачевого десктопа с двумя full hd мониторами — никакого дискомфорта при использовании нет. В углы между мониторами попадать было трудно, но сейчас там есть однопиксельные «препятствия», так что нужно вести курсор в угол не прямо, а по вдоль края экрана (по кривой) ну или пользоваться Win+C — левая рука все равно всегда на клавиатуре. Практически никаких изменений в использовании «классического» десктопа не появилось

Каждый раз когда того же Руссиновича спрашивают в духе «А какая, мол, текущая рекомендация по размеру страничного файла для системы с N физической памяти на борту» он всегда отвечает в духе «А хрен его знает». Иногда правда расширяет мысль: независимо от того, сколько в системе физической памяти размер необходимого пейджфайла от этого не зависит. Наилучшей рекомендацией (если уж сильно хочется зафиксировать размер) будет «отпустить» размер, погонять все-все свои ворклоады во всех-всех режимах, посмотреть Peak Commit Charge и выставить размер пейджфайла соответственно.

Что же отключения пейджфайла и прочих «твиков», я придерживаюсь мнения, высказанного где-то в этом посте Aux: не знаешь что конкретно ты делаешь — просто не лезь — существует высокая вероятность, что создатели ОС предусмотрели больше, чем способен предусмотреть ты. С другой стороны, я, к сожалению, не могу утверждать что отключение пейджфайла вредно абсолютно всегда (если бы все было так просто, возможности отключения просто бы не было), но к подобным вмешательствам в работу системы нужно подходить основательно и сначала проверить (чаще всего тестированием) действительно ли вообще нужно вмешательство и, если нужно, нужно ли оно именно здесь.

На всякий случай поправлюсь. Про сотни лет использования слова overcommit я, похоже, соврал. Merriam-Webster говорит, что слово используется с 1951-года (все еще задолго до сколь-нибудь продвинутого мемори-менеджмента, но не на сотни лет).

Local/Global. API существуют с одной целью — обратная совместимость, и сами они реализованы через VirtualAlloc, логика работы которого тоже менялась со временем

Первая часть не противоречит ни статье 93-го года, ни тому, что я сказал (я специально выделил «API» болдом) — да, эти вызовы все еще есть, выделяемая ими память ничем не отличается от остальной виртуальной памяти и «разливается из одной бочки» — heap manager-ом (который сам по себе является субаллокатором для NtAllocateVirtualMemory). А вот про «логику работы» — это уже Ваши домыслы (ну то есть особенности реализации менялись — оптимизация, приоритезированные стендбай списки, пейджкомбайнинг, «охлажение» многоканальной памяти и пр., но семантика осталась прежней)

CRT — это вообще другой уровень, это код внутри самого процесса

Это тоже не противоречит тому, что я сказал. С другой стороны, здесь можно долго спорить, что «является ОС», а что нет. msvcrt.dll (без версии) поставляется in-box точно так же как и те же kernel32.dll/kernelbase.dll и как ни крутись — является «частью ОС». С другой стороны, есть рантаймы с каждой версией VC, да еще статически/динамически линкуемые. Это никак не относится к тому факту, что «статья 93-го года» все так же актуальна, как и 20 лет назад.

Про MEM_RESERVE вы всё поняли верно. А про COMMIT — нет. Что бы понять отлтичие, нужно знать как устроены структуры диспетчера памяти. По ссылке, всё есть, читайте про структуры адресного пространства — VAD, PTE.

Нет, я «понял верно» и MEM_RESERVE и MEM_COMMIT. Про дерево VAD-ов и аппаратную трансляцию PDE/PTE (а также дополнительные метаданные самой винды для каждой страницы в виде nt!_MMPFN) я знаю и они к делу не относятся.

Когда вы вызываете VirtualAlloc с флагом COMMIT вы отъедаете КВОТУ (а не саму память) ПРОЦЕССА (а не операционной системы) на ресурсы, резервируя элементы из каталога страниц процесса

Точно так же и «квоты» на рабочий набор процесса никак не относятся к системному «commit limit»-у. Но раз уж мы меряемся длиной, то позволю себе отметить, что PDE/PTE как были невалидными до MEM_COMMIT, так и остаются после. Реальные физические страницы попадают в рабочий набор при soft-fault-ах. Упрощая, можно сказать, что коммит меняет только состояние записей в PFN database (и VAD), а PTE записи обновляются по мере необходимости (demand paged).

Т.е. если вы будете мельчить с вызовами VirualAlloc(COMMIT) то вы просто потеряете возможность выделять память изнутри самого процесса, по тому что негде будет это выделение описать.

Исчерпание (и/или фрагментация) адресного пространства — реальная проблема на 32-битных архитектурах. Забавным образом, она вообще не относится к коммиту. Адресное пространство можно легко фрагментировать (или выделить все и не оставить никому) и при помощи одного только MEM_RESERVE.

Остальные процессы при этом совершенно никак не затрагиваются.

Еще как затрагиваются. commit это «брать на себя обязательства», «обязывать», «фиксировать» и пр… То есть система ОБЯЗУЕТСЯ предоставить Вам страницу, когда она Вам потребуется (а не в момент самого NtAllocateVirtualMemory). Commit charge — это такой общесистемный счетчик, который подсчитывает сколько всего страниц было «обещано». Commit limit — это такой общесистемный счетчик, который считает сколько всего страниц МОЖЕТ БЫТЬ обещано (физическая память, которая может быть выгружена на диск плюс суммарный размер всех страничных файлов). Таким образом, когда процесс делает MEM_COMMIT, но не трогает эти страницы — его рабочий набор не изменяется, но commit charge растет. В то же время, если ядро выделяет физическую память (MDL-ами или из non paged pool-а), то уменьшается commit limit. Менеджер памяти все время следит, чтобы commit charge ни при каких условиях не стал больше commit limit. Подобная ситуация называется overcommit и термин используется при менеджменте любых ресурсов — не только физической памяти. Более того, он использовался за сотни лет до того, как появились компьютеры и означает буквально «осознанное обещание сделать больше, чем ты способен». Так вот, винда не оверкоммитит виртуальную память. Никогда и ни при каких условиях.

Хороший прмер — если в приложении утечка памяти, то рано или поздно посыпятся сообщения об ошибках вроде «Out Of Memory», но посыпятся то они только из одного процесса, а не изо всех сразу.

Действительно хороший пример. Предлагаю Вам попробовать:

add-type -Namespace Win32 -Name Mapping -MemberDefinition @"
[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr CreateFileMapping(
    IntPtr hFile,
    IntPtr lpFileMappingAttributes,
    uint flProtect,
    uint dwMaximumSizeHigh,
    uint dwMaximumSizeLow,
    [MarshalAs(UnmanagedType.LPTStr)] string lpName);
    
[DllImport("kernel32.dll", SetLastError = true)]
public static extern IntPtr MapViewOfFile(
    IntPtr hFileMappingObject,
    uint dwDesiredAccess,
    uint dwFileOffsetHigh,
    uint dwFileOffsetLow,
    uint dwNumberOfBytesToMap);    
"@
 
$mapping = [Win32.Mapping]::CreateFileMapping(-1,  0, 2, 1,  0, $null)
[Win32.Mapping]::MapViewOfFile($mapping, 4,  0,  0, 3Gb)

Ну или используйте Руссиновичевый "testlimit -m" (страницы коммитятся, но не «трогаются», так что рабочий набор не растет).
Зафиксируйте размер пейджфайла (или вовсе отключите), подведите commit charge вплотную к commit limit-у (оба числа хоть и постоянно перемещаются, но достаточно важны, так что показываются в task manager-ах всех виндов начиная как минимум с 2000 — до нее скорее всего тоже, но я просто не помню так что утверждать не берусь) и посмотрите сможете ли Вы почарджить память из другого процесса (хоть еще одним pagefile-backed memory map-ом, хоть VirtualAlloc-ом).

Нет, информация не устарела. Local/Global memory API все еще существуют, но используют они (точно так же как и CRT memory API) единый Heap manager.

Так что все верно, MEM_RESERVE — резервирует адресное пространство (например, если нужен мемори меппинг файл, но не хочется мепить его весь сразу), а MEM_COMMIT — резервирует виртуальную (pagefile backed) память. Если пейджфайла нет, то commit charge limit будет в точности равен объему физической памяти и даже при том, что физически страница не будет впечатана в рабочий набор процесса, можно считать что физическая память будет зарезрвирована и недоступна больше никому

А я наоборот, почти месяц пытался найти желтую или голубую, но везде одни черные (изредка попадаются белые).
Плюнул — взял две черных.