@MSGID: 2:5000/14 6807744f
@REPLY: 2:5020/828.777 68067a3c
@CHRS: CP866 2
@TZUTC: 0200
Привет!

21 Apr 25 21:02, you wrote to me:

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

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

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

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

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

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

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

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

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

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

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

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

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

 MS> То же самое относится к подсистемам OS/2 и Posix.

Что именно в тоссере может относиться к OS/2 и Posix?

 MS> Смешанные 32-битные/64-битные процессы не допускаются.

Откуда они в старом 32-разрядном софте?

 MS> 64-битные приложения могут загружать только 64-битные DLL и OCX.

В старом 64-разрядном софте их нет.

 MS> 32-битные приложения могут загружать только 32-битные DLL и OCX.

Как им могут понадобиться 64-разрядные?

 MS> Скрипты и плагины также не могут запускать одновременно 32- и
 MS> 64-битные процессы.

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

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

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

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

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

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

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

Всего доброго!
Евгений Музыченко
fi-do@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20180707
 * Origin: Fox Tracks, France (2:5000/14)
SEEN-BY: 46/49 455/19 466/50 4500/1 5000/14
5001/100 5010/352 5019/40
SEEN-BY: 5020/400 545 848 1042 4441 12000 5022/128
5025/3 75 5027/12
SEEN-BY: 5030/1081 1957 2404 5033/21 5035/85
5051/36 5054/1 5063/3 5066/18
SEEN-BY: 5068/10 5080/68 102 5085/13 5095/20
6001/10 6035/4 6078/80
@PATH: 5000/14 5020/545 4441