LINUX.ORG.RU

FreeDOS 1.0


0

0

Вышел в свет FreeDOS 1.0, как пишут разработчики, это MS-DOS-совместимая OpenSource дисковая операционная система.

Из особенностей:
Easy multiboot with Win95-2003 and NT/XP/ME
FAT32 file system and large disk support (LBA)
LFN support (on command line with 4DOS, which is now freeware: 4DOS for OS/2 is even open source)
LBACACHE - disk cache (harddisks in CHS and LBA mode, diskette)
Memory Managers: HIMEM, EMM386, UMBPCI
SHSUCDX (MSCDEX replacement) and CD-ROM driver (XCDROM)
CUTEMOUSE - Mouse driver with scroll wheel support
FDAPM - APM info/control/suspend/poweroff, ACPI throttle, HLT energy saving...
XDMA - UDMA driver for DOS: up to 4 harddisks
MPXPLAY - media player for mp3, ogg, wmv... with built-in AC97 and SB16 drivers
7ZIP, INFO-ZIP zip & unzip... - modern archivers are available for DOS
EDIT / SETEDIT - multi window text editors
HTMLHELP - help viewer, can read help directly from a zip file
PG - powerful text viewer (similar to V. D. Buerg's LIST)
many text mode programs ported from Linux thanks to DJGPP
GRAPHICS - greyscale hardcopy on ESC/P, HP PCL and PostScript printers
etc.

Думаю идеальная вешь для парка старинных машин где нужно пользовать что-то, где линукс не справляется (о боже! я сказал это!)

скачать можно тут - http://www.freedos.org/freedos/files/

>>> Подробности



Проверено: Pi ()
Ответ на: комментарий от R00T

> Правда? А пацаны-то и не знали... :-( Вечно приходилось ограничиваться
> 64К на сегмент данных. :-(
Нда, товарищ, похоже, совершенно не в курсе, что такое страничная
адресация... Ну да я не жадный, образовывайся:
http://en.wikipedia.org/wiki/X86
Более того, я не ленивый - вот даже цитату приведу:
---
Linux, 386BSD and Windows NT were developed for the 386 because it was
the first CPU to support paging and 32-bit segment offsets.
---

anonymous
()
Ответ на: комментарий от anonymous

---
Linux, 386BSD and Windows NT were developed for the 386 because it was
the first CPU to support paging and 32-bit segment offsets.
---
На всякий случай ещё и переведу, а то мало ли...
Linux, 386BSD and Windows NT были созданы для 386, так как это
был первый проц (из линейки x86), поддерживающий страницную адресацию
и 32-битные сегменты.

anonymous
()
Ответ на: комментарий от R00T

> Угу. А под DOS была 16-ти битное смещение сегмента. Отсюда и 64К.
Да я что, спорю с этим? Нафига ты сюда страничную адресацию приплёл
только - это вопрос.

anonymous
()
Ответ на: комментарий от R00T

Но ведь разница в адресации (16 и 32 бита) - это далеко не всё различие между реальным и защищённым режимом, ибо в защищённом режиме появляются уровни привилегии, развитые средства отладки, совершенно другая система обработки прерываний! Без этого не было бы многозадачных ОС! А в реальном режиме доступны 32-разрядные инструкции (но адресация 16-разрядная)

anonymous
()
Ответ на: комментарий от anonymous

Хм. Это все через расширения.
Если вести речь о MS-DOS, то там ничего 32-х разрядного небыло вообще.
И переключения режимов - тоже небыло.

Все делалось только надстройками и костылями. Иначе терялась обратная совместимость, чем M$ зело дорожат до сих пор.

R00T
()
Ответ на: комментарий от anonymous

> Но ведь разница в адресации (16 и 32 бита) - это далеко не всё
> различие между реальным и защищённым режимом
Это даже не "одно из" различий, так как и защищённый режим спокойно
бывает 16-битным (более того, на 286 другого вообще не было).
Только к нашему спору с R00T это не относится, тем более что он
уже отказался от утверждения, что ДОС использует страничную адресацию.

> Если вести речь о MS-DOS, то там ничего 32-х разрядного небыло вообще.
ДОС ДОСу рознь. Глянь вот сюда, к примеру:
http://freedos-32.sourceforge.net/

> Все делалось только надстройками и костылями. Иначе терялась обратная
> совместимость, чем M$ зело дорожат до сих пор.
Так, да не совсем. Блин, снова тянет лекцию прочесть, а ведь я уже на
работу опаздываю...
Короче, надстройками и костылями всё делалось с подачки PharLap и Co,
пока MS не понадобилось на скорую руку портировать реал-модовое ядро
винды в защищённый режим. Вот тут-то они в серьёз взялись за голову и
разработали DPMI. Это не было костылём и позволило им запустить ядро
винды в защищённом режиме лишь с небольшой доточкой напильником.
Но вот PharLap это не очень понравилось - прямая угроза их бизнесу,
и они основали DPMI Committee, основная цель которого была в том,
чтобы свести применение DPMI обратно в разряд костылей. Они сделали
это довольно успешно - из оригинальных спеков MS было выброшено
всё, кроме интерфейса int31h - именно в этом виде мы знаем о DPMI
сейчас. Изначально же это был полноценный транслятор API, хорошо
интегрирующийся с существующим ДОСом и любым ПО под него, и
позволяющий без всяких костылей портировать досовые проги в защ.
режим, и после этого они ещё могли работать под любыми операционками,
при условии, что те предоставляли DPMI (даже в OS/2 он есть).

anonymous
()
Ответ на: комментарий от anonymous

А где найти не загрузочный образ freedos на cd, который доступен для скачивания,
а уже сархивированный каталог freedos и файлы io.sys, command.com и пр. - т.е., все,
что нужно, что установить dosemu.

anonymous
()
Ответ на: комментарий от anonymous

>> Если вести речь о MS-DOS, то там ничего 32-х разрядного небыло вообще. >ДОС ДОСу рознь. Глянь вот сюда, к примеру: http://freedos-32.sourceforge.net/

Это совсем "не MS"-DOS.

Если же вспомнить MS-DOS, то в ней есть такая программа EMM386.EXE. Она существенно использует возможности 386 и подобных 32-разрядных процессоров: защищенный режим, страничную 32-разрядную адресацию, режим V86 и виртуализацию ввода-вывода.

Верно, что для работы MS-DOS необязателен 32-разрядный процессор; не верно, что в MS-DOS нет _ничего_ 32-разрядного

zaregazza
()
Ответ на: комментарий от zaregazza

А ведь я там написал, что "все делалось чере костыли".

emm386.exe есть ни что иное, как самый настоящий костыль, призванный за уши подтянуть DOS к уровню 386-й машины.

R00T
()
Ответ на: комментарий от R00T

>emm386.exe есть ни что иное, как самый настоящий костыль, призванный за уши подтянуть DOS к уровню 386-й машины.

Ась? Что этот костыль делал-то, кроме эмуляции Extended памяти на Expanded? Или это по-твоему - уровень 386 машины?

alt-x ★★★★★
()
Ответ на: комментарий от alt-x

Вот забавные, все-таки, на LORе кретины живут. Желание дое*ться до каждого слова - в крови просто.

Вы это, ментом не пробовали работать? ДПСником? Для таких, как вы, товарищей - очень прибыльное дело, как мне рассказывали.

R00T
()
Ответ на: комментарий от R00T

Микроядерные системы так вообще из одних костылей состоят, тогда уж.

anonymous
()
Ответ на: комментарий от R00T

>emm386.exe есть ни что иное, как самый настоящий костыль, призванный за уши подтянуть DOS к уровню 386-й машины

Не для этого. В свое время, когда выяснилось, что 1Mб мало, и даже еще не было 286-х, к PC решили подключать дополнительную память (EMS). Доступ к этой памяти программы получали через EMS драйвер. QEMM386 и EMM386 сделали в первую очередь для эмуляции EMS с API драйвера EMS.

Про EMS в конце страницы - http://www.codenet.ru/progr/asm/upmem0.php

kosmonavt
()
Ответ на: комментарий от R00T

>Вот забавные, все-таки, на LORе кретины живут. Желание дое*ться до каждого слова - в крови просто.

В роли кретина тут выступил ты. Не стоит молоть о том, чего не знаешь.

>Вы это, ментом не пробовали работать? ДПСником? Для таких, как вы, товарищей - очень прибыльное дело, как мне рассказывали.

Вот-вот, и об этом тебе тоже рассказывали. Т.е. сам ты и этого не знаешь.

anonymous
()
Ответ на: комментарий от R00T

>mm386.exe есть ни что иное, как самый настоящий костыль, призванный за уши подтянуть DOS к уровню 386-й машины.

Точно костыль:(... осбенно обидно то, что Intel и M$ до 1997года зажимали информацию о UNREAL режиме работы процессоров, когда фактически из REAL режима через дополнительные сегментные регистры без всяких Himem и Emm была доступнеа вся (!!!) оперативная память, без жалких ограничений в 1Mb и без всяких сегментов...

anonymous
()
Ответ на: комментарий от zaregazza

>> Глянь вот сюда, к примеру: http://freedos-32.sourceforge.net/
> Это совсем "не MS"-DOS.
Да, всё верно. Просто R00T сказал, что не было 32-разрядности и
переключения задач в ДОС, т.к. "Иначе терялась обратная совместимость".
Я привёл пример, когда это всё есть и совместимость тоже пытаются
сохранить.

> Если же вспомнить MS-DOS, то в ней есть такая программа EMM386.EXE.
Да, помним-помним эту злобную прогу... Помимо EMS, реализовывала
так же VCPI, GEMMIS и кучу другой левизны. Согласен с R00T, что
это тот ещё костыль был. :)

anonymous
()
Ответ на: комментарий от anonymous

> Точно костыль:(... осбенно обидно то, что Intel и M$ до 1997года
> зажимали информацию о UNREAL режиме работы процессоров, когда
> фактически из REAL режима через дополнительные сегментные регистры
> без всяких Himem и Emm была доступнеа вся (!!!) оперативная память,
> без жалких ограничений в 1Mb и без всяких сегментов...
Ты это брось, кайф не в этом. :) Ну была доступна вся вирт. память,
но только для данных. Код в ней ты уже не погоняешь.
К тому же ни под одной многозадачной ОС такой финт не пройдёт, так
что для практических целей не пригодно. Если скрывали, то и правельно
делали. :)
Вообще, много чего полезного скрывали. VME к примеру, или тот же
DPMI (который в оригинале был)...

anonymous
()
Ответ на: комментарий от anonymous

> Ну была доступна вся вирт. память, но только для данных. Код в ней ты уже не погоняешь.

ZX-Spectrum 128K помнишь? Так вот, там еще и не такой финт ушами делался, что запускать код в области памяти >64K.

anonymous
()
Ответ на: комментарий от anonymous

> ZX-Spectrum 128K помнишь?
Честно говоря, нет. Как-то почти мимо меня прошёл. 48К - это да, а вот
со 128 что-то не получилось.

> Так вот, там еще и не такой финт ушами делался, что запускать код в
> области памяти >64K.
Напомни вкратце, в чём там была проблема. В голове встают неявные
воспоминания, что там всё сводилось к переключению банков памяти,
путём записи в порты, и тогда особой проблемы для исполнения кода
я не вижу.
А вот что касается исполнения real-mode кода в памяти выше первого
мега с flat-адресацией - тут проблемы явно должны быть, ведь,
насколько я помню, регистр IP в риал-моде за 64К никак не уйдёт
(не EIP он там).

anonymous
()
Ответ на: комментарий от kosmonavt

>QEMM386 и EMM386 сделали в первую очередь для эмуляции EMS с API драйвера EMS.

Далеко не только для этого: большинство DOS-программ умеет всё-таки работать через HIMEM.SYS или применяет расширители DOS. EMM386 вообще-то применяли для решения проблемы нехватки памяти: дело в том, что первый 640Кб в DOS - жутко дефицитный ресурс, и оттуда стремятся всё вынести. HIMEM.SYS может только открыть дополнительный 64Кб-сегмент (сверх 1Мб), в который еле-еле впихивается ядро DOS, а ведь драйвера тоже грузить хочется. И вот этот EMM386 использовал страничную адресацию памяти, чтобы латать "провалы" между блоками ПЗУ контроллеров, материнской платы и видеопамятью в адресах A0000-FFFFF, и пихали туда драйвер CD-ROM, русификатор, драйвер мыши и прочие радости жизни (иногда удавалось наскрести свыше 100Кб).

Помните DOS=HIGH,UMB, DEVICEHIGH=..., LH=... ?

anonymous
()
Ответ на: комментарий от anonymous

Забавно пронаблюдать за тем, как решили данную проблему разработчики FreeDos в содружестве с Dosemu. Во первых сам emm386 там занимает всего пару байт, во вторых ядро занимает столько же. В результате под Dosemu во FreeDos запускаются зачастую те программы, которые под родным досом можно было запинать только повыгрузив все что можно, а под поздними версиями вообще нельзя было запинать. Так-то.

eXOR ★★★★★
()
Ответ на: комментарий от eXOR

Скачал fdbasecd.iso: MD5 не совпадает, загрузил диск - на распаковке архива виснет. А так хотелось поиграться в DOS :-)

anonymous
()
Ответ на: комментарий от anonymous

> HIMEM.SYS может только открыть дополнительный 64Кб-сегмент (сверх
> 1Мб), в который еле-еле впихивается ядро DOS
Если для исполнения кода - то да, 64K HMA. А так - himem.sys открывает
всю память, правда только для данных - код реального режима там
не поисполняешь. Доступ осуществляется через интерфейс XMS.
В принципе можно и вообще без himem - через in15h получать доступ
ко всей памяти.

> И вот этот EMM386 использовал страничную адресацию памяти, чтобы
> латать "провалы" между блоками ПЗУ контроллеров, материнской платы и
> видеопамятью в адресах A0000-FFFFF, и пихали туда драйвер CD-ROM,
> русификатор, драйвер мыши и прочие радости жизни (иногда удавалось
> наскрести свыше 100Кб).
Опять же, UMB (про который вы говорите) - это лишь побочное действие
emm386. Была куча других прог, которые открывали UMB и без использования
защ. режима, страничной адресации и тд (umbpci к примеру). Основное
назначение emm386 - реализация EMS и VCPI, а вовсе не UMB.

anonymous
()
Ответ на: комментарий от eXOR

> В результате под Dosemu во FreeDos запускаются зачастую те программы,
> которые под родным досом можно было запинать только повыгрузив все
> что можно
Помню времена, когда в dosemu можно было просто указать в параметре
$_dosmem любую величину, вплоть до мега, и - о чудо - все проги
видели это кол-во памяти. И даже mem говорил что свободно 760К из
640 возможных, и тд. Потом эту возможность, кажется, отменили
(а может ещё работает?)

anonymous
()
Ответ на: комментарий от anonymous

>И даже mem говорил что свободно 760К из 640 возможных, и тд.

Старый трюк. К списку свободных блоков присоединяют участки выше 640К, которые не используются программами. Если не нужна графика, то можно отобрать участок верхней памяти, которую занимает видеобуфер, а для ДОС это приличный объем.

kosmonavt
()
Ответ на: комментарий от kosmonavt

>которые не используются программами

В смысле системой.

kosmonavt
()
12 октября 2006 г.
Ответ на: комментарий от anonymous

Многозадачные ОС прекрасно существуют и без защищенного режима, страночной адресации и т.д. Другое дело что Win, Линухи и т.д. используют именно защищенный режим :) Есть многозадачные ОС на 8-16 битных процах с линейной адресацией :)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.