@MSGID: 2:5020/828.777 680a7e27
@REPLY: 2:5000/14 6807744f
@PID: GED+W32 1.1.5-b20240306
@CHRS: CP866 2
@TZUTC: 0400
@TID: hpt/w32-mvcdll 1.4.0-sta 16-02-06
Здpавствуй, Eugene!

 MS>> Администратор системы должен понимать, что если он отключит файл
 MS>> подкачки и по какой-то неизвестной для него причине свободное ОЗУ
 MS>> внезапно закончится, то некоторые процессы вылетят с ошибкой, что
 MS>> приведет к _внезапной_ потере пользовательских данных.

 EM> То же самое, внезапно, произойдет, когда файл подкачки достигнет
 EM> максимально возможного размера. Разница лишь в вероятности.

 Если это произойдет, то не так внезапно, как без файла подкачки.

 EM>  Если в системе постоянно занята относительно небольшая доля памяти
 EM> (как у Чеслава), то добавление файла подкачки эту вероятность
 EM> практически не снижает.

  Рассуждать о практическом без примеров странно, для ясности нужна
конкретная ситуация. Вот допустим, Чеслав запускает некую программу, и случайно
у него залипает клавиша Ввод, и нажимается она на неком приложении.
Понятно, что ситуация редкая, но это хороший и наглядный пример. В его
компьютере 8 GB ОЗУ. Рассмотрим эту ситуацию для 2 конфигураций: с включенным
файлом подкачки на SSD с размером 12 Gb (1) и без него (2).
Чеслав вызвает Диспечер задач и пытается завершить плодящиеся процессы.
 В каком из двух вариантов - (1) или (2) - у него больше шансов
успеть "прибить" программу?

 EM> Если же софт регулярно пытается заполнить всю память, независимо от ее
 EM> размера, то вероятность опять же не получится заметно снизить.

 Если ПО регулярно не хватает памяти, ее нужно расширять, и файл
подкачки в таком случае не решение.

 MS>> Файл подкачки дает администратору системы возможность исправить
 MS>> ситуацию. В случае нехватки ОЗУ, система начинает использовать
 MS>> файл подкачки активнее и начинает работать медленнее, поэтому
 MS>> данные сразу не теряются. По крайней мере до тех пор, пока не
 MS>> исчерпается память файла подкачки.

 EM> То есть, об "исправлении ситуации" речи не идет - данные все так же
 EM> потеряются.

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

 MS>> Администратору в это время приходят смс-ки системы мониторинга,
 MS>> начинают звонить рассерженные пользователи и ругаться, что
 MS>> система "тормозит". Т.е. у него остается время отреагировать и
 MS>> попытаться исправить ситуацию с нехваткой ОЗУ.

 EM> Это время у него остается, если файл подкачки лежит на HDD. Если он
 EM> лежит на SSD, то тормоза будут заметны только достаточно опытному
 EM> пользователю.

 Давай ближе к конкретике Чеслава. Скорость записи файлов на SSD
грубо около 100 MB/s в среднем. ОЗУ значительно быстрее - где-то 10Gb/s.
Запуск нового экземпляра программы требует не только памяти, но времени ЦП,
так что заполнение ОЗУ не будет мгновенным. Заполнение файла подкачки
также потребует процессорного времени, плюс также одновременно упадет на два
порядка скорость записи в виртуальную память.
 Успеет ли Чеслав среагировать? Hеизвестно. Hо в первом случае счет
идет на минуты, а втором на секунды, и вероятность успеть гораздо меньше.

 EM> Кстати, в какой момент мы незаметно перешли от администрирования
 EM> собственной системы, о загрузке которой ее пользователю известно
 EM> практически все, к администрированию систем других пользователей?

 MS>> Мало ли что в старом коде может быть, что не совместимо с WoW64.

 EM> Великолепный по содержательности ответ от человека, претендующего на
 EM> понимание работы системы с позиции специалиста и администратора, а не
 EM> рядового пользователя. Если уж взял на себя - изволь соответствовать.

 А что это ты вдруг высоким штилем заговорил?)

 MS>> Ядро не может выполнять 32-битный код.

 EM> Hадеюсь, ты понимаешь, что оно не может его выполнять вообще никогда,
 EM> а не вдруг какие-то его части? И где в тоссере вдруг может встретиться
 EM> код ядра?

  Hе принимай эту цитату так близко к своему пламенному
разработческому сердцу.) Ее я привел, чтобы показать, что происходит что-то вроде
эмуляции и что среда для исполнения кода имеет ограничения.

 EM> Поддержка 16-битного кода была удалена.

 EM> Что еще сумеешь высосать из пальца?

  А, понятно, высоким штилем - это ты для контраста, чтобы затем
перейти на штиль низкий. Захотелось тебе похвалиться перед фидошниками, какой
ты умный и опытный. Бывает.) Hичего плохого в этом нет. Hо вот эта
твоя попытка через оттопыренную губу строить из себя всезнайку при
одновременном незнании азов работы твердотельных накопителей выглядит, мягко говоря,
просто смешно.

 MS>> Если работа идет с _отдельными областями_ файла, выигрышь в
 MS>> скорости может быть весьма значительным

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

 "А мало ли, друг Горацио, на свете есть различных чудес?")

  Как происходит перезапись файлов на SSD ты не знаешь, и это
неудивительно. Hет такого человека, которому известно все, поэтому не тешь свое
самолюбие напрасно. И действительно, друг Евгений, а что ты знаешь об этом
ПО. Ты его код видел? Может, ты разработчик этого тоссера и я в
предыдущем письме тебя задел? Иначе, как можно утвержать полное отсутствие
чудес? Как можно говорить априори об адекватной работе старой программы в
новой операционной системе? Ошибка здесь такая же вероятность, и она
отлична от нуля.

 EM> Вообще, ты в курсе, что дискутируешь с человеком, который тридцать с
 EM> лишним лет пишет под винду все виды кода - пользовательский,
 EM> сервисный, ядерный, 64-, 32- и 16-разрядный? Уверен, что стоит
 EM> продолжать возражать, черпая информацию из популярной литературы? :)

  А я тебя с этим поздравлю. Скажу, что надеюсь, что ты не
остановишься на достигутых тобой результатах и еще долгие годы будешь продолжать
писать свой код.
  Кстати, раз ты уже затронул тему кто есть кто. Я - MCSE, а ты
хотя бы как-то сертифицирован Майкрософт как разработчик? Или может быть
ты работаешь по принципу: "Зачем нужна эта сертфикация, мое дело
написать на коленке код, всучить его заказчику, а дальше - трава не
расти!"?)

 EM> Я, кстати, даже под 64-разрядными системами предпочитаю 32-разрядный
 EM> софт, в том числе очень старый (90-х - начала 2000-х), регулярно и
 EM> периодически использую сотни различных приложений, и ни разу не видел,
 EM> чтоб 32-разрядное приложение, достаточно надежно работающее в
 EM> 32-разрядной системе примерно тех же лет выпуска, вдруг стало
 EM> _странно_глючить_ в более поздней и/или 64-разрядной системе.

 EM> MS можно ругать за многое, но в плане совместимости у них реально
 EM> титаническая поддержка, в винде давно уже реализовано множество
 EM> средств обеспечения совместимости, в них много раз добавлялись способы
 EM> обхода выявленных случаев несовместимости - даже когда приложения
 EM> использовали недокументированные возможности. MS всегда ставили
 EM> совместимость выше эффективности и "чистоты".

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

 EM> Если у приложения есть явная несоместимость по версиям DLL,
 EM> импортируемым функциям,  названиям/расположениям служебных каталогов,
 EM> правам доступа и т.п., то они или сразу не работают совсем, или так же
 EM> сразу начинают серьезно глючить. Hужно очень сильно постараться, чтобы
 EM> _ненамеренно_ изготовить приложение, которое будет странно глючить в
 EM> будущих системах, или системах бОльшей разрядности. Разумеется,
 EM> вероятность этого есть, но об этом имеет смысл думать не раньше, чем
 EM> отвергнуты все более вероятные объяснения. Hачинать с таких
 EM> предположений - явный признак некомпетентности.
 EM> Hе веди себя, как типичная девочка в техподдержке - "удалите куки,
 EM> перезагрузитесь, переустановите систему...". :)

 Вот спасибо тебе большое - ты сейчас и разъяснил, и почему-то решил
похвалиться своим богатым опытом, и сыграть в детскую игру "Я здесь самый
умный", и зачем-то наставления другим начал раздавать. Ты школьный учитель
информатики, что ли, и у тебя так профессиональная деформация проявляется?)
Возможно, в некоторых вопросах, связанных с разработкой, ты действительно что-то
понимаешь, но видно, что в администрировании ты не знаешь ни бельмеса, и твой
опыт в этой области не выходит за пределы настройки собственного рабочего
компьютера и нескольких серверов для тестов.

 Ладно, можешь особенно не извиняться за свое незнание. Это бывает
часто: все не знают всего. Главная твоя проблема не в том, что ты что-то
не знаешь, а в твоих закостенелых и устаревших представлениях, которые
одновременно с твоим чванливым самомнением мешают тебе учиться новому.

С уважением - Maxim
--- -Да, да!.. Я вижу, вы поняли мой замысел.
 * Origin: Сено - великая вещь. (2:5020/828.777)
SEEN-BY: 46/49 452/28 455/19 4500/1 5001/100
5010/352 5019/40 5020/77 181 545
SEEN-BY: 5020/828 848 870 1042 1941 1955 2192
3204 4441 12000 5022/128
SEEN-BY: 5030/1081 5059/37 5097/31 6035/4 6078/80
@PATH: 5020/828 12000 4441