о текущей директории (англ., компьютерное)

[avva]

Реймонд Чен: Why does each drive have its own current directory?

Во всех версиях DOS и Windows командная строка "помнит" отдельно текущую директорию для каждого диска. Если на C: сделать cd foo, потом пойти на D: и там сделать cd bar, а потом вернуться "c:", то окажешься в запомненной директории foo. Так было всегда, но я никогда не понимал, зачем это нужно. У такого поведения были свои преимущества, но были и недостатки.

Из этой записи Чена я наконец узнал, зачем это так сделано: для совместимости DOS 2.0 с программами DOS 1.0. И по этой причине текущая директория так работает во всех версиях DOS и Windows, включая самые последние. Потому что когда-то нужно было, чтобы программы для DOS 1.0, не знавшие что такое "директория", могли писать в разные директории на дискетах, когда их запускали в DOS 2.0. Бедный, бедный мой мозг.

Было бы полезно сделать подборку записей Реймонда Чена (а у него немало записей в таком духе) обязательной для изучения будущими программистами в университетах.

Comments

[fyysik.livejournal.com]

В юникс были не батч файлы, а уже сразу плотные шелл-скрипты, с гибкой логикой и обработкой переменных.
Батч-файлы вообще от перфокартной технологии идут.

Насчет РАДИКС - да, я ответил кому-то за вами. Скорей для простоты переняли традицию без технологии сжатия.

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

Экстентов я не застал точно. Посему основной спасительной командой был squeez - собрать непрерывные файлы в единый блок, чтоб теоретически доступное место стало реально доступным. Очень смеялся года три назад, когда выяснилось, что пресловутая проблема пожирания памяти Firefox-ом примерно в этом и состоит:)

Так что с последним тезисом не согласен никаким боком. Разве что за ооочень солидное материальное вознаграждение.

P.S. Застал СP/M и для 16-разрядников. И даже его "мультизадачное" расширение - MP/M

[mfi.livejournal.com]

Ну, если плясать от еэсовских перфокартных заданий и JCL - приходило в голову, но отбросил, уж сильно они от нормальных shell-ов отличаются. Но в CP/M батчей просто не было вообще, как класса.

Про РАДИКС - ага. Точнее, Гэри Килдалл перенял понятие окончания имени - хорошая идея была, даже если осью поддерживалось только .COM. А сама длина имени в 8 байт - FILE9999.TXT - это просто - заведомо больше, чем можно было поместить файлов на дискету :-)

Слэши в плане оппозиции двух миров - пожалуй соглашусь тоже.

Насчет экстентов - Wiki говорит, что я ошибаюсь, может я помню экстенты дескрипторов файла в каталоге (но зачем они тогда?) а не экстенты файлов? Я как то писал на Macro-11 самопальную файловую систему для дискет - и мне пришлось разбираться с главным каталогом жесткого диска RT-11.

Материального вознаграждения предложить не могу, но в итоге мы имеем слеши и трехбайтовое окончание имен - маловато для родственных связей :-)

П.С. Ага, я видел ее для 16-ти разрядников тоже - но это сразу стало столь несерьезно... В конце концов, весь софт CP/M отлично бегал под MS DOS, требуя минимума поддержки от разработчика (помните разницу между .COM и .EXE и специальный режим intel процессора?). Oн выглядел там чужим и убогим - но он был!

Когда мы впервые увидели MS DOS, первый вопрос всей команды был - а утилита поддержки ххх (не помню имя, но мы из нее не вылезали) - тут пойдет? Она есть? И ответ "Да", был решающим. Тут же появился PC Tools, не говоря уже о Нортоновских утилитах, крывших CP/M-овские как бык овцу, но для нас было главное, что в первые же минуты мы не оставались с незнакомым софтом (или без него) в руках. А если учесть, что dBase-3, редакторы текстов и SuperCalc остались неизменны (скопируй информацию клиентов as is и продолжай разработку), то переход на другую ОС был вопросом решенным. Умные парни сидели в Microsoft.

[skylump.livejournal.com]

Ой, а расскажите, в чем была принципиальная разница между COM и EXE? Я попробовал погуглить, но на поверхности ничего не нашлось.

[vveakling.livejournal.com]

COM-файл - это просто бинарный кусок кода, имел ограничение на размер - 64К.
А у EXE (во временах MS-DOS) в начале файла шёл кусок данных описывающий расположение отдельных сегментов кода внутри файла, таким образом обходилось ограничение на размер. Во времена Windows формат развился дальше.

[mfi.livejournal.com]

COM - расширение запускаемого файла, вся адресация команд и данных которого находится внутри единственного 64К сегмента, как у 8-разрядной машины. Т.е. программу, написанную для 8-разрядной архитектуры, например - интел 8080, можно запустить на процессоре 8088/8086. Понятно, что надо что то сделать с системными вызовами ОС, они разные у CP/M и MS DOS (но это решалось). Т.е. на первом ПС под Досом можно было писать и запускать программы, как для CP/M, со старым расширением .com. Либо даже собственно CP/M, пока нет нужных программ для MS DOS.

Для EXE файлов таких ограничений не было, можно было использовать все адресное пространство 16-разрядной машины (1 мегабайт), использовать разные адресные экстенты для данных, для разных частей кода и т.п. Загрузчик понимал, куда что положить в памяти - что в начало, что в конец и т.п., т.е. один файл мог раскидываться по частям, а не одним непрерывным куском в память.

[dmitry zuikov (from livejournal.com)]

Вообще-то адресное пространство 16-битной машины это как раз 64K. 8086 вроде бы могли адресовать до 2²⁰ памяти по схеме сегмент-смещение, но 384 килобайта были зарезервированы.

насчет экстентов

[(Anonymous)]

/Я как то писал на Macro-11 самопальную файловую систему для дискет - и мне пришлось разбираться с главным каталогом жесткого диска RT-11/
А это точно была RT-11, а не RSX-11?

Re: насчет экстентов

[mfi.livejournal.com]

Неа, Рафос, разные ОС ДВК и т.п.

Клинит меня что то.