Нужен файл msdos.sys от Win95

Спроси то что копировало... а вообще дуракам везёт

 

2 aleksej:
Мою фразу, про то что копировали "через Volkov Commander" пропустили? Я видел обе панели. Та, что была с диском после форматирования - была пустая (про то что показ скрытых файлов был включён, иначе бы не смогли выделить для копирования IO.SYS и MSDOS.SYS - надо говорить отдельно или нет?).
В конце концов, если кто-то захочет - может провести "следственный эксперимент".

2 John Freeman

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

 

iunnamed, вот именно, что стоило сказать про отключённую/включённую функцию показа скрытых файлов потому, что:
command.com привязки к бутсектору не имеет в отличии от двух .sys'ов. Его месторасположение можно указать в config.sys с помощью комманды shell, в autoexec.bat переменной comspec или вручную по требованию во время загрузки.
Сам я не пробовал делать форматирование с переносом системных файлов при отсутствии command.com в заданном месте, но чтото мне подсказывает, что в этой ситуации процесс пройдёт молча, либо ругнётся, но таки перепишет .sys'ы.
И в этом случае (если предположить гепотетически, что было именно так), если command.com отсутствовал на диске источнике системных файлов во время форматирования с ключом /s только .sys файлы переписались (с атрибутом hidden/system разумеется), а их отображение было в волкове отключено, то и могла сложиться такая видимость. По другому обьяснить не могу, так как ваших познаний умалять не хочу. Хотя....
Референсные AMI/AWARD/PHOENIX биосы отродясь не имели таких сомнительных фич, как помощь в засовывании системных файлов на нужную дорожку, если юзер методом записи их на диск ошибся. Тут вы, извините сильно мимо.

 

2 aleksej:
Спасибо большое за ответ, но тут, видимо, мы с вами немного не понимаем друг друга.

Начать хотелось бы с "умаления моих знаний". Хотел бы сделать акцент на том, что невозможно знать абсолютно всё. Можно попытаться логически из существующих фактов (посылок) сделать какой-то, опять-таки, более или менее логичный вывод.
Например из фразы "скопировали с загрузочной дискеты через Volkov Commander файлы COMMAND.COM, IO.SYS, MSDOS.SYS" логически можно сделать следующие умозаключения:
Вывод 1: т.к. файлы были скопированы "через Volkov Commander", то, соответственно, в последнем должно было быть включено отображение скрытых и системных файлов, иначе скопировать IO.SYS и MSDOS.SYS не смогли бы, т.к. не смогли бы их выделить (их бы не было в панели).
Вывод 2: опять-таки, т.к. файлы были скопированы "через Volkov Commander", то следовательно они были просто скопированы, без всяких соответствующих изменений в загрузочной области диска (что делает, например, команда sys с ключом /s)
Вывод 3: т.к. копируют обычно из панели в панель, то содержимое второй панели (куда копируют) обычно видно на экране, а следовательно видно, что и на ней нет никаких файлов (если уж рассматривать все возможные ситуации, то тут сразу следует оговориться о случае, когда на экране только одна панель, а при копировании вручную прописывают путь куда копировать в диалоговом окне копирования - тогда, действительно, содержимое второй панели неизвестно).
Видите? Всё быстро и просто можно почерпнуть из самого первого моего поста в этой теме, всего лишь сделав несколько логических умозаключений. Просто априори предполагал, что каждый может сделать их сам.

Сразу скажу, что ни в коем случае не хочу умалять ваших познаний. Люди, к сожалению, очень часто просто невнимательны.

Теперь, вернёмся к нашему вопросу о том "Кто же запускает IO.SYS?".
На момент написания моего первого поста в этой теме, для меня это тоже было непонятно. Не буду с вами спорить и даже соглашусь с утверждением, что "Референсные AMI/AWARD/PHOENIX биосы отродясь не имели таких сомнительных фич, как помощь в засовывании системных файлов на нужную дорожку, если юзер методом записи их на диск ошибся. Тут вы, извините сильно мимо.", однако, если присмотреться к моему посту, то там был оборот "скорее всего" - означающий, некоторое сомнение в изложенной мысли - т.е. она является логическим предположением. Согласитесь, что предположение, что "BIOS может передавать управление IO.SYS" куда более правдаподобно и наиболее вероятно нежели утверждение, скажем, что "управление IO.SYS передаёт господь бог"?

Для начала заглянем в Wikipedia - IO.SYS:

Дальнейший текст нас мало интересует, т.к. IO.SYS уже запустился. Таким образом, мы имеем такую картинку:
1. Запускается BIOS
2. BIOS читает первый сектор диска и передаёт ему управление
3. Если этот сектор - загрузочный сектор DOS, то загружаются первые три сектора IO.SYS и им передаётся управление
Собственно, на шаге 3 IO.SYS запускается. Нам нужно понять, кто это делает между BIOS и IO.SYS.
Передача управления схематично выглядит примерно так:

BIOS => Первый сектор диска => IO.SYS

Т.к. вы утверждаете, что BIOS этого сделать не может, значит это делает первый сектор диска.

После посящения меня такой мысли - заглянул в дамп загрузочной дискеты от WIN98SE. Помимо всяких текстов:

Invalid system disk
Disk I/O error
Replace the disk, and then press any key

В самом начале были также и такие (пробелами между расширением выравнены, до DOS 8.3 формата):

Код:

IO      SYS
MSDOS   SYS

Рискну предположить, что на жёстком диске это выглядит, примерно, также. Что и доказывает мысль, о том, MS-DOS, начиная с некоторой версии становится абсолютно безразличен к тому, где именно в корне текущего диска распалогаются эти файлы (про COMMAND.COM вы уже совершенно точно и правильно написали - его можно положить в любой каталог и прописать к нему путь).

Рискну также предположить, что команда sys с ключом /s всего лишь прописывает этот самый "индифферентный" загрузочный сектор в начало диска, а файлы IO.SYS, MSDOS.SYS и COMMAND.COM просто копирует, как это делает тот же Volkov Commander.


John Freeman был ближе всех к правильной мысли ("Мозги то включи, на СВЕЖЕОТФОРМАТИРОВАННЫЙ..."), т.к., видимо, при форматировании без ключа /s первый сектор прописывается, но не копируются упомянутые выше системные файлы.

 

Не так - бутсектор отношения не имеет к, он не файл даже, после формата он скорее всего просто НЕ СТЁРСЯ(предположение), так как не является частью ФС равно как и MBR. А если формат был Quick то это очевидно сразу так.

Аналогично возможно твоя версия доса не пользуется бутсектором 1 раздела, а только MBR или что-то похожее, там это в DOS 7+ сильно поменяли.

 

iunnamed, ну что тут можно сказать - тёмная сила электричества, не иначе.
Вообще родные MS копировальщики иногда себя ведут забавно и чёрт его знает, что format.com там оставил после себя в вашем случае. Запустили бы fdisk с недокументированным ключом /mbr и неизвестно, прошёл бы этот финт у вас. Что то видимо осталось после форматирования в mbr, что привело к такому эффекту.

Например, родной MS загрузчик nt-based осей не сносится утилитой sys никак. Ежели к примеру на FAT раздел после WinNT например захочется вернуться к DOS. Раньше это было некоторой проблемой. SYS просто ругался - не хватает места в MBR для записи. И FDISK /MBR не всегда спасал. А вот ежели поставить на такой диск DOS с помощью родного инсталлятора, то он замечательно подчищает всё в MBR и спокойно ставит DOS. Чего почемуто не может зачастую сделать SYS.COM
Такие вот дела.

 

версии 7+

именно