Мои замечания:
1)забудьте все рекомендации вроде:
Цитата: MaxPhysPage надо выставлять в значение в среднем на 256 Мб меньше общего кол-ва оперативки, но не более 1164 Мб (практический максимум доступный винде без использования
патчей), а MaxFileCache в 512 Мб при объеме памяти до 1 Гб, и понижать это значение вдвое или вчетверо при больших объемах памяти.
Особенно про MaxFileCache : Смотрим сколько адресов реально свободно (с 0xC0000000 и до первого устройства) И на этот размер ограничиваем размер кеша (причем лучше - прямым патчем VCACHE.VXD). БОЛЕЕ ЭТОТ
ПАРАМЕТР ТРОГАТЬ НЕТ СМЫСЛА. Если даже его уменьшение, относительно вышеуказанного значения, гдето "облегчает жизнь" - значит у нас что-то криво в другом месте, и это все равно рано или поздно даст о себе знать.
Любые шаманства с MaxPhysPage - при 1Гб и более (ну возможно 1164 Мб) - бесперспективны. Бывает, что бесполезны и при 768Мб (зависит от остальной переферии). Вообще метод - "гнилой".
MaxPhysPage - НЕ ЭКВИВАЛЕНТНО (хуже) ограничению памяти ДО загрузки винды (3-й метод по вашей классификации), и физическому вытаскиванию "лишней" памяти. А потому возникают сомнения, стоит ли им вообще пользоваться
2) RAM LIMITATION PATCH - не терпит ограничения оперативки посредством MaxPhysPage. Если есть - УБРАТЬ . (MaxFileCache - работе не мешает)
3) Без RAM LIMITATION PATCH систему возможно будет не поставить - повисание после первой перезагрузки (причем иногда, с необратимым повреждением устанавливаемой системы - приходится сносить и ставить
начисто). Поэтому на время установки ставим какой нибудь "ограничитель" вроде burnmem-а (3-й метод по вашей классификации), причем желательно на 256мб или даже менее, а потом уже снимаем ограничение и
разбираемя (причем сначала ставим RAM LIMITATION PATCH, а ПОТОМ снимаем ограничение). burnmem (в отличии от MaxPhysPage) с RAM LIMITATION PATCH - не конфликтует. Либо пользуемся дистрибутивом с интегрированным
RAM LIMITATION PATCH - например: 98IF последних сборок. Лично проверял: Без каких либо проблемм и дополнительных извращений ставится на 2Гб оперативы, причем на этой машине никаким шаманством с MaxFileCache/MaxPhysPage
получить что либо отличное от "синего экрана" либо "Not Enough Memory" "system halted" при загрузке - было невозможно ни в safe mome, ни в normal.
4) Пушной зверек может нас посетить и при 512 Мб оперативы, хотя в этих случаях все ограничиватся правкой MaxFileCache. Сам видел машину, где занята зона адресов 0xD0000000-0xDFFFFFFF (туда отмапилась видеокарта, а все остальные многочисленные устройства "живут" в более старших адресах) и даже вынимание одной планки памяти (оставалось 512мб) не давало возможности запустить DOS. Правда простым ограничением MaxFileCache до 256Мб все лечилось. Но вот стоило воткнуть
вторую планку и систему начинало колбасить неподеццки. Никакими ухищрениями с MaxFileCache/MaxPhysPage "отвоевать" более 512мб доступной памяти - не удавалось. Нынче туда поставлен RAM LIMITATION PATCH,
и все замечательно с 1Гб.
Еще видел случай когда TV-тюнер занял маленький кусочек прямо перед 0xDFFFFFFF, и установка дополнительной планки в 256Мб (стало 512) в эту машину - моментально привела к неработоспособности видеооверлея (второй, после DOS, метод контроля, что "все хорошо"). Опять таки вылечилось все MaxFileCache. Вообще случай довольно редкий, но всеже бывает. Теоретически, особенно на системах с несколькими современными видеокартами, могут быть заняты адреса и в зоне 0xC0000000-0xCFFFFFFF (если заняты полностью - это крест на установке 98
,если частично - можно побороться). Опять таки, теоретически настанут проблеммы и при 256Мб, хотя я плохо себе представляю машину с 2 видеокартами и 256Мб оперативки
, но например при установке Burnmem, на навороченный комп, об этом не следует забывать.
5) Все патчи VCACHE.VXD сводятся к правке в нем 4 байт (ну можно еще версию подправить
) - тех самых, пресловутых, "800Мб" (в 2 местах) следующим образом:
800Мб 512Мб 384Мб 256Мб
смещение (исходно)
00005D25: 20 00 80 00
00005D26: 03 02 01 01
00005D2C: 20 00 80 00
00005D2D: 03 02 01 01
(RAM LIMITATION PATCH тоже правит только эти байты)
Что делается любым 16-ричным редактором, на любую требуемую величину
.
И это более "правильно" чем править MaxFileCache, ибо драйвер все равно выделяе "800Мб" адресов, а потом только использует меньше. Хотя проблемм из-за этого я не разу не наблюдал.
6) RAM LIMITATION PATCH версии более чем 3.2 я не использую, ибо знаю 2 машины на которых старшие версии дают глюки, а 3.2 - работает без нареканий. (обе машины - самые "тяжелые случаи", обе я уже упомянал
ранее, весьма загружены доп. аппаратурой на одной занята зона адресов 0xD0000000-0xDFFFFFFF, на другой 2Гб оперативы правда 0xD0000000-0xDFFFFFFF - свободны, но без патча - вообще "ни гу-гу", ни какими
методами, даже привынимании доп. железа).
7) Хотелось бы поподробнее про :
Цитата: С проблемой распределения памяти патч также справляется, но не всегда, есть довольно много отзывов от людей у которых все равно возникают те или иные глюки при его использовании, так что тут уже как
повезет
Могут ли глюки определятся 2 причинами ? :
а) на этой системе нельзя иметь 512Мб кеша (занята аппаратурой зона
0xD0000000-0xDFFFFFFF)
б) использовался RAM LIMITATION PATCH 5-й версии.
8) RAM LIMITATION PATCH не правит версии патченных файлов, потому возможно обновление (например при установке MDCU) с фатальными последствиями. Про это просто не стоит забывать, чтобы не пялится в черный(синий)
экран, как известное животное на некоторое деревянное изделие
9) "Ошибка памяти" является своего рода "естественной защитой" от установки 98 на новые машины, с большим (>128Гб) HDD . Потому незабываем про BHDD, если он опять-таки не встроен в дистрибутив. Пишу
потому, сам что имел печальный опыт: научил одного человека, как поставить RAM LIMITATION PATCH - через неделю, чуть не был побит (любое доброе дело - наказуемо), за потерянные данные
.
Добавлено: Цитата: Начнем с того, что глюки с памятью в Windows 98 бывают трех видов:
Еще раз перечитал статьи от мелкомягких и умилился их наивности
Не верьте вранью от micrisoft, что MaxPhysPage - заставит систему не видеть лишней памяти сверх того что вы укажете !! (невидеть то заставит, только глюки остануться
)
Цитата: Систему не по детски плющит при объеме памяти более 1.5 Гб (KB304943). Виноват драйвер VCACHE.VXD
Виноват тут таки VMM.VXD (либо еще чтото в ядре системы) с VCACHE.VXD - как раз легко бороться посредством MaxFileCache, либо прямого патченья оного, и тут все боле-мене понятно. А вот то что при больших обьемах памяти есть глюк еще гдето помимо кеша - лечится только патченьем VMM.VXD, либо удалением аппаратным или программным (не MaxPhysPage !! ) лишней памяти.
Цитата: Правда в статье у MS почему-то ничего не сказано о параметре ChunkSize, а он как я понял тоже играет какую-то роль.
А это вообще не по теме. Если и влияет, то опосредовано, как при затирании одной областью памяти другой, может повлиять все что угодно, в зависимости от того, что на что "наехало", и как именно распределились программы в памяти
После любого изменения в глючащей системе все может стать совершенно по другому, надо глюки устранять, а не пытаться под них подстроится.
(хотя без ста грамм там сразу разобраться сложно) 
(сейчас все ОК 
Win98 построен на платформе MS-DOS!