640 КБ на самом деле хватит всем

[BOOTor]

Вспомнил молодость и Борланд Паскаль… Сейчас можно заменить на Free Pascal — и старые наколенные научные расчетики идут «на ура» :)

[System12]

А Бейсик, который смог освоить (в меру возраста) мой 8-ми летний сын…
Впрочем сейчас многие не верят в то, что Досовский Суперкалк работал не хуже Экселя.

[System12]

Тяжело, да и лениво вспоминать. В свое время делал и расчеты и графики (правда не цветные). Я лучше Вас рассмешу по теме. С времен ДОС у меня на некоторых форумах остался ник SYS Недавно меня обвинили в том, что я в качестве ника использую ничего не значащий набор из трех букв. А когда-то без загрузочной дискеты жизни не было.
640 кбайт оперативка и 20 мегабайт винт хватало на жизнь. Про видеопамять вообще молчу. Сейчас 32 мегабита в телефоне приходится периодически чистить ибо начинает кричать что ему мало памяти.

[geher]

С времен ДОС у меня на некоторых форумах остался ник SYS Недавно меня обвинили в том, что я в качестве ника использую ничего не значащий набор из трех букв.

Эти люди, наверное, никогда не видели в корне ФС на своем жестком диске с виндой файла pagefile.sys. А он там обычно есть (мало кто выключает подкачку или переносит ее на другой диск).

[easty]

У меня другие файлы в памяти
config.sys
himem.sys
emm386.sys
Я очень стар)))

[pfemidi]

А как же io.sys и msdos.sys? Без них все остальные sys'ы смысла не имеют.

И кстати, загрузочной дискета или винчестер (уже отформатированные) делались при помощи утилиты sys.com. Так что я тоже староват маленько ;-)

[geher]

Смутно припоминаю, что в некоторых более альтернативных версиях DOS эти файлы назывались как-то по другому.
В частности, в PC-DOS и некоторых версиях DR-DOS вроде были ibm.com и ibmdos.com.

[saboteur_kiev]

или тем же format /s
и пропустили autoexec.bat и command.com

[pfemidi]

Я же сказал:

И кстати, загрузочной дискета или винчестер (уже отформатированные)

так что format /s тут не нужен, тут достаточно утилиты sys.

И ещё насчёт autoexec.bat и command.com позанудствую ;-) Разговор начался с того, что пользователь System12 сказал:

С времен ДОС у меня на некоторых форумах остался ник SYS

Поэтому easty и упомянул про config.sys, himem.sys и другие sys'ы, а я добавил io.sys и msdos.sys. Везде одни sys'ы, про bat'ы и com'ы никакой речи не было.

[O1eja]

и command.com

[skygad]

autoexec.bat забыли.
Это же самая первая магия, которую я узнал в ms-dos.
Ну и как уже написали io.sys и msdos.sys

[Alyoshka1976]

А как же 800.com, чтобы выжать несколько дополнительных дорожек с пятидюймового Verbatim-а? ;-)

[MacIn]

Помним такое. Половина дискет в этом формате, никак прочитать теперь не могу.

[speakingfish]

800 — прошлый век. Есть ведь новейший PU_1700 :)

[speakingfish]

Я пользовался gamma — только там было самое оптимальное переключение — по CapsLock. Сейчас только под linux нормально работает переключение по CapsLock и клавиатурная индикация из коробки. Под виндой все переключатели CapsLock имеют разные степени глюкавости.

[MacIn]

Два шифта — наше все!

[DmitryMry]

Пользуюсь этим способом, рекомендую.

[iZENfire]

su.exe же есть — маленькая компактная программка, в отличие от монстра keyrus.com.

[claymen]

emm386 Был exe =)))

[domix32]

Сейчас еще и и файл hiberfil.sys с данными гибернации валяется.

[System12]

Наверное Вы не видели компов со слотами для дискет. А и В это гибкие дисководы. Вы возможно удивитесь, но я застал времена когда диска С в простых ПК вообще не было, только дискеты. И для того чтобы комп заработал надо было обязательно первой вставлять дискету с ДОС. Команда format (буква диска:) стирала содержимое дисков. Команда sys кроме стирания переносила на диск/дискету ДОС. Кстати, для того чтобы загружаться с нового диска С: тоже требовалась команда sys

[sav1812]

Команда sys кроме стирания переносила на диск/дискету ДОС.

Команда SYS ничего не стирала.

[System12]

Вы ошибаетесь. По своей сути команда sys была комбинацией двух команд — форматирования диска/дискеты и переноса ДОС в системный каталог.

[sav1812]

Да нет, я не ошибаюсь. :)

Sys is used to copy the system files from one drive to another drive, allowing that drive to be bootable.

When running sys, the below files will be copied.

command.com
io.sys
msdos.sys
drvspace.bin

https://www.computerhope.com/syshlp.htm

То, что Вы описали — это format + sys.

[System12]

Значит уже склероз. Давно это было.

[Wan-Derer]

Да ладно! Дисководы? Гибкие? ДИСКОВОДЫ?
А насколько они гибкие?

[System12]

Пятидюймовые дискеты легко заворачивались в трубочку. Правда потом обычно не работали. Тонкий пластиковый диск в бумажном конверте с прорезью под головки и механизм вращения. Впрочем лучше читайте Вики ru.wikipedia.org/wiki/%D0%94%D0%B8%D1%81%D0%BA%D0%B5%D1%82%D0%B0

[Alyoshka1976]

ИМХО это был сарказм :-) Ведь НГМД расшифровывается как «накопитель на гибких магнитных дисках»

[MacIn]

A и B были, емнип и в CP/M с 8" дискетами.

[MacIn]

Не, у меня был рабочий Панасоник с CP/M, отдал в музей. Радует посетителей своей работой.

[MacIn]

Не помню модель. Отдельно монохромный черно-зеленый монитор, отдельно ящик с двумя вертикальными 8" НГМБ и отдельно процессорный блок. С то ли модемом, то ли телетайпом встроенным.

[MacIn]

Бог ты мой. Вам точно надо таблички «сарказм» или «шутка» показывать. Там же цитата.

[pfemidi]

«Кто такой Генерал Фейлор и зачем он читает мой диск C:?» © :-)

[MacIn]

Ты кого инвалидом назвал, железяка?

[omgiafs]

Не работе к различному проф. оборудованию иногда приходят майор Аларм и генерал Фейлор.

[Ndochp]

Просто навыки сменились. В том же суперкалке вместо мыши вполне себе использовались целые аккорды на клавиатуре не глядя, от которых остались только воспоминания в виде Alt-буква режима.
У меня вполне работала таблица по расчёту заработной платы, с учетом среднего, вычетов на детей и тд. С собственным меню для пользователя, из которого только по Ctrl-C выйти можно было. И не сказать, чтобы инструмент меня больше напрягал, чем алгоритм.
Писалось это классе в восьмом, изучал я 4 суперкалк по мануалу, так что назвать продукт сильно сложным я не могу.

[lobzanoff]

Да ладно, в конце 80-х — начале 90-х люди полный цикл бухгалтерии и зарплаты учреждений средних размеров организации делали на SUPERCALC, притом это работало годами практически без присутствия автора (за исключением редкой правки размерностей отчетов в связи с инфляцией), и было заменено только в конце 90-х.

[bazilxp]

Видел заметку о кросс компиляции с помощью GCC под DOS создание ком файлов
на английском. gcc com =)
Еще старый добрый Watcom чет вспомнился

[anprs]

Да-да-да. Сколько же раз меня выручал реализованный за 10 минут метод Ньютона… :)

[BOOTor]

Не хватило упоминания DN, а это для того времени мощнейший набор инструментов.

[easty]

DN мне казался слишком жирным. Volkov Commander наше все

[pansa]

Зато в DN был встроенный тетрис…

[artemisia_borealis]

Ещё в DN был screensaver «Огонь». Очень натурально это пламя выглядело четветь века назад.

[saboteur_kiev]

или можно было запустить резидентный тетрис

[O1eja]

Особенно в части копирования файлов с дискеты на дискету… по сравнению с nc

[MacIn]

Для этого xcopy был, зачем там вообще файловый менеджер?

[svitoglad]

А еще был Norton Commander.
Сейчас уже не вспомню но кажись Volkov Commander 4.0 занимал меньше памяти по сравнению с nc.

[pfemidi]

А на «Правец-16» с которого я начинал весь DOS был болгарский и в комплекте с ним шёл передранный с NC «Команден Организатор», называемый в инструкции просто Коморг.

А ещё из файловых менеджеров того времени был XTreeGold, но я им не проникся вообще.

[speakingfish]

Основной фичей XTree была отрисовка структуры каталогов в псевдографике и возможность быстрого перемещения директорий (это называлось «prune and graft»). Встроенной возможности перемещения директорий не было больше нигде, кроме специальной программы из комплекта Norton Utilities. Позднее эта возможность появилась лишь в DOS Navigator.

[MacIn]

Не «а еще». Волков — это клон NC. Был действительно меньше, ел меньше памяти и летал быстрее. ЕМНИП, его писали на ассемблере, а NC к тому времени — на С или С++.

[zuek]

...а почему никто не вспоминает DOSShell? Достаточно удобная оболочка, пусть и не совместимая по UX с DN/NC/VC/...

[FyvaOldj]

На большинстве DOS-машин после загрузки драйверов и TSR (резидентных программ) едва находилось 600 КБ ОЗУ.

Даже и 480k.
Но сие было проблемой первых версий DOS.
Потом появилось несколько менеджеров памяти, а позже и сама DOS начала это уметь. Как раз ко времени когда на машины стали по мегабайту-два ставить и хотелось их все использовать.

https://ru.wikipedia.org/wiki/HIMEM.SYS#%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C

[Daniil1979]

DOS=UMB, HIGH

[Chugumoto]

В этот размер не уместится даже исполняемые файлы большинства программ-установщиков.

меня вот это постоянно поражает… и вспоминается .kkrieger

[pha]

Кроме оптимизации кода на помощь приходит процедурная генерация текстур и объектов, использование упаковщиков исполняемых файлов.
Плюс к этому избавление от зависимостей (всякие msvcr100.dll).
Но только это не востребовано в большинстве случаев из-за быстрого интернета и дешевого дискового пространства.

[Vanellope]

А упаковщик то все равно перед исполнением будет в память распаковывать.

[pha]

Это верно, но применительно к .kkrieger примечателен был крайне малый размер исполняемого файла (~96 КБ).

[saboteur_kiev]

формат .com исполняемого файла вообще не предполагает размер программы, больше чем 1 страница памяти (64 кбайта).

[MacIn]

1 сегмент.

[Shtucer]

char buffer[320x200];

Так, разве, можно?

[bulaev]

Видимо вместо х должен быть знак умножения.

[Areso]

За местным парсером замечана нежная любовь к этому знаку, потому многие и меняют)

[bulaev]

Серьёзно? Какой поворот! А если объявлена переменная x? Что за глупость.

[Shtucer]

Если объявлена переменная x, то все равно ничего не скомпилируется.

[bulaev]

Это и понятно. Просто не понимаю, зачем менять * на х. Это же ломает код.

[FyvaOldj]

Поскольку у нас есть до 4 ГБ адресуемого пространства (по крайней мере, теоретически), мы можем считывать с диска сложную тайловую графику или даже целые JPG пререндеренной графики. С помощью этой системы вполне возможно создать почти современную видеоигру.

Ну положим были DOS extender:

DOS/4g
cwsdpmi
PMODE

Какие то из них дружны с упомянутым GNU для DOS — DJGPP

И еще куча.

[SinsI]

калькулятор в Windows 10 занимает в состоянии простоя 16,2 МБ оперативной памяти

Любопытно было бы узнать, что же именно там столько памяти требует.

[gandjustas]

Скорее всего окна.

[Massacre]

Скорее всего какие-то абстракции Win10, потому что calc от XP занимает в Win7 x64 примерно 1мб…

[Tutanhomon]

Думаю он на дотнете работает, так что нечему удивляться.

[iSergios]

16 мегабайт памяти… Эх, этого с головой хватало для Windows 95 + Quake :) Там вам и окна, и графика, и «физика», и AI.

[arheops]

Обновления драйверов nvidia вчера запросили 400мб.

[sebres]

А чего тут удивительного, вот список одних только библиотек, который мне выдал listdlls calc на семёрке (нет 10-ки под рукой)...

listdlls calc

Base                     Size Path
0x00000000ffb60000     929792 calc.exe
0x0000000077420000    1744896 ntdll.dll
0x0000000077200000    1175552 kernel32.dll
0x00000000fd1d0000     434176 KERNELBASE.dll
0x00000000fe840000   14196736 SHELL32.dll
0x00000000fe230000     651264 msvcrt.dll
0x00000000ff6b0000     462848 SHLWAPI.dll
0x00000000fe2d0000     421888 GDI32.dll
0x0000000077320000    1024000 USER32.dll
0x00000000fdd00000      57344 LPK.dll
0x00000000fdc10000     831488 USP10.dll
0x00000000fb440000    2191360 gdiplus.dll
0x00000000fd7d0000    2080768 ole32.dll
0x00000000fd6a0000    1232896 RPCRT4.dll
0x00000000ff5d0000     897024 ADVAPI32.dll
0x00000000fd5a0000     126976 sechost.dll
0x00000000fd5c0000     892928 OLEAUT32.dll
0x00000000fb660000     352256 UxTheme.dll
0x00000000fc2f0000    2048000 COMCTL32.dll
0x00000000faeb0000     241664 WINMM.dll
0x00000000fbfe0000      49152 VERSION.dll
0x00000000fd570000     188416 IMM32.DLL
0x00000000fdd90000    1085440 MSCTF.dll
0x00000000f05f0000    1445888 WindowsCodecs.dll
0x00000000fae20000      98304 MPR.dll
0x00000000775f0000      28672 PSAPI.DLL
0x00000000fb320000      98304 dwmapi.dll
0x00000000fcfb0000      61440 CRYPTBASE.dll
0x00000000fd4d0000     626688 CLBCatQ.DLL
0x00000000fb060000     344064 oleacc.dll

Ну и строго говоря и 16МБ это не совсем верно, ибо с ним например может запуститься wmiprvse с CIMWin32-провайдером (или еще какой другой, если еще не запущен от чего-то другого), который откушает еще 5-12МБ, и т.д. и т.п.

[pha]

dlls калькулятор в w10

[creker]

Все проще. Калькулятор написан на UWP, который, понятное дело, тянет кучу зависимостей с собой.

[Alexey2005]

Фреймворки — вот что сейчас жрёт львиную долю ресурсов и производительности.
Если вы хотите, чтоб ваша программа весила в 10 раз меньше и работала в 4 раза быстрее, напишите её без использования фреймворков.
Фреймворки решают ровно одну задачу: увеличивают скорость разработки за счёт увеличения ресурсоёмкости готового продукта. То есть по сути позволяют переложить часть издержек, связанных с разработкой, на конечного пользователя.

[RPG18]

К сожалению такой подход в больших проектах приводит к созданию своего фреймворка.

[RPG18]

А это уже как получится. Я в одном таком «фреймворке» на C++ «сборщик мусора» видел.

[acmnu]

Я в одном таком «фреймворке» на C++ «сборщик мусора» видел.

Это часто делается на самом деле. Почти в любом действительно большом проекте на C++ используется сборка мусора. На собеседованиях даже часто спрашивают: "а вы писали свой сборщик мусора?"

[VEG]

У вас в системе может быть некая софтина, которая внедряется во все процессы, и уже от их имени может что-нибудь запрашивать. Не так уж и много смысла писать вот такие вот заявления без подробного разбора «а что там было в адресном пространстве, что за данные передавались» и т.д., желательно с указанием на конкретный код, который что-то там передаёт (калькулятор не такой большой, можно и отреверсить).

[aamonster]

Поиграйте с CP/M-80, там ещё проще (один call 5h на всё — кстати, он довольно долго поддерживался в DOS).

[frog]

CP/M скучна — там идея в работе на разных архитектурах, без прямого доступа к железу. Поэтому всё было медленное, простое и печальное.

[goodwind]

Режим 13h, сколько в свое время с ним провел.
Вот эти вот

mov al, 13h
mov ah, 0
int 10h

первое, что всплывает в памяти когда вспоминаю те времена

[Lsh]

Можно пояснение, для тех, кто под DOS не кодил?

[MacIn]

Сброс дисковой подсистемы. Гуглите int 13 reference. И это не DOS, это функционал BIOS.

[elmm]

Если мне не изменяет память, большая часть досовского функционала висела на 21h

[KMiNT21]

Так и есть. Я даже частично в никнейме своем заюзал. :) km int21

[easty]

10h это функции биоса, 21h это доса. Если нужны обращения на более низком уровне, к железу

[Tippy-Tip]

Прерывания DOS начинались с 20h (завершение работы программы).

[Massacre]

Неа. Это int 10h (графические функции BIOS), функция 0 — переход в выбранный графический режим (13h в данном случае). И можно обойтись двумя командами (mov ax,13h / int 10h)

[frog]

Установка графического режима, вроде (из принципа не полез гуглить :)

[MacIn]

Тьфу, верно.

Я как-то с утра косыми глазами увидел 13 прерывание.

Извините, коллеги.

[goodwind]

После Турбо Паскаля и его библиотеки graph, которая не имела режимов выше 16 цветов, этот режим показался чудом так как позволял использовать аж 256 цветов в разрешении 320х200.
Что забавно, в те времена у меня не было интернета, поэтому режим я подсмотрел через отладчик в какой-то небольшой игрушке, которая его использовала. Откуда-то вычитал про прерывание 10h и его связь с видеорежимами. Поставил на него breakpoint и смотрел что в какие регистры складывается. Уж не знаю почему, но там было именно так: раздельно загружались ah и al. Как выше в комментах уже сказали, можно было обойтись «mov ax, 13h», но на тот момент мне было лет эдак 13-14 и я еще очень плохо понимал ассемблер.
В результате я сделал свою библиотечку graph13h, в которой были процедуры с короткими ассемблерными вставками для выставления режима и простейшие процедуры для рисования примитивов. Позже мне попала в руки потрепанная книга Майкла Абраша про программирование графики и я расширил библиотечку для рендера простейших 3D-сцен, переписал всё что мог на ассемблере. Эта библиотека позже даже имела хождение на форуме, посвященном паскалю где я был в то время модератором (да, за время её написания у нас появился dial-up).
Не знаю зачем я это всё пишу, ностальгия пробрала

[Vitalley]

Осталось только библиотеку запостить.

[goodwind]

С той поры уже столько мертвых винтов утекло, а форум перешел в чужие руки и там уже фиг чего найдешь. Да и нечего там смотреть, есть две или три одноименных библиотек с гораздо более богатым функционалом и более чистым кодом. Не забывайте что тогда мне было лет от 14 до 16 примерно и понятия о красивом и хорошо структурированном коде я тогда особо не имел

[speakingfish]

На CGA фантастикой казались 16-цветная графика разрешением 80x50, 80x100 и 160x100 сделанная из текстового режима. en.wikipedia.org/wiki/Color_Graphics_Adapter#160%C3%97100_16_color_mode
Только не везде она работала, увы.

[iZENfire]

После Турбо Паскаля и его библиотеки graph, которая не имела режимов выше 16 цветов, этот режим показался чудом так как позволял использовать аж 256 цветов в разрешении 320х200.

Это вы, наверное, не тот драйвер использовали. vgaega.bgi позволял из модуля Graph стандартной библиотеки использовать полноцветный VGA-режим работы адаптера и дисплея. С помощью несложных манипуляций видеодрайвер vgaega.bgi возможно было преобразовать в .obj-формат, а затем в формат .tpu-модуля и внедрить (статически скомпилировать) с программой на Turbo Pascal, использующей графический режим, и она становилась автономной (не требовалось дополнительно таскать содержимое каталога \BGI).

[zuek]

*уже когда-то писал в другом треде, но...

Ностальгия пробила

У меня был "Турбо Паскаль", состоящий только из компилятора (я его выдрал из какого-то промсофта - он там использовался для вкомпиливания настроек), но turbo.tpl не было, а руки чесались попрограммировать (К.Г. Финогенов уже начал захватывать полку на книжном стеллаже) на Turbo Pascal (в Доме пионеров нас учили программировать на Turbo Basic, а в школе на "Электрониках" был какой-то Pascal и незабвенный БЕЙСИК УКНЦ), так я с помощью различной подручной литературы написал суррогат CRT.TPU и DOS.TPU, процентов на 90 состоящие из ассемблерных вставок, и нормально у меня и строки на экран выводились, и с файлами работать было можно... к моменту, когда я добрался до графических режимов (на ассемблере я с ним игрался к тому времени больше года), в школу завезли полный дистрибутив Borland Pascal, и всё, на что меня хватило с самописными TPU - написал просмотрщик картинок от sexsonix (спустя пару лет внезапно скачал с какой-то BBS комплект sexonix со своим views.exe, чему очень удивился - вроде, вьюер раздавал только одноклассникам, но, похоже, он попал в Дом пионеров, откуда и расползся достаточно широко; про картинки - они были банальными дампами экрана в режиме 13h и палитрой, проксоренными каким-то байтом, склеенные друг за другом...)

А потом я поступил в институт на "неИТ" специальность, и с программированием подзавязал, а когда решил вернуться, уже везде был Windows95 и все мои навыки "изощрённого программирования" оказались ненужными, но это совсем другая история...

[ooprizrakoo]

Действительно ли Билл Гейтс произнёс фразу «640 КБ должно хватить всем»? Её история довольно туманна, однако чаще всего её приписывают Биллу, так что, возможно, он действительно такое говорил.

Откуда туманность? Во-первых, нет ни одного источника, где приводилась бы эта цитата, во-вторых самого Билла спрашивали:

QUESTION: «I read in a newspaper that in l981 you said '640K of memory should be enough for anybody.' What did you mean when you said this?»

ANSWER: «I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time.»

[hdfan2]

Это называется «постправдой». Нужно просто очень часто повторять одно и то же обвинение (безо всяких доказательств), и через какое-то время оно становится правдой. А на вопрос о доказательствах удивлённо ответить: «Но ведь все это знают!». Используется сейчас всеми кому не лень.

[MacIn]

Точнее, он сказал на одной из конференций, что речь шла о том, что 16 бит/640к хватит всем ближайшие 10 лет. А не вообще и всегда.

[gandjustas]

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

[MacIn]

Отчего минусите? Это его воспоминание на конференции 89 года.

[computershik73]

Пробовал сделать псевдомультизадачную программу под DOS. Чтобы и документы читала, и jpg-шки. Всё делала, но с тучей тормозов, хотя открытие jpg было написано на ассемблере. Или код неэффективный, или DOS не умеет эффективно работать с Apple iMac…

[MacIn]

А в чем именно выражались тормоза? Медленное чтение файла? Так неудивительно. Низкое разрешение таймера? Тоже не новость.

[pfemidi]

Для DOS в своё время была библиотека под названием CTask, как раз позволяла делать многозадачность на голом DOS без всяких дополнительных приблуд. Я её даже в своё время использовал когда программировал для банкоматов. К сожалению сейчас не смог ни нагуглить, ни наяндексить, везде сплошные Task in C, классы CTask и прочее, что к делу совсем не относится. Был у меня где-то дистрибутив этой библиотеки CTask, но насколько я помню он записан на дискете 3" так что даже если и найду его, то прочитать дискету 3" мне уже давно не на чем.

[saboteur_kiev]

Многозадачность в дос решалась через резидентные программы.
Да и вообще вся многозадачность обычно заключается в оседлании прерывания таймера, что делает сейчас любая многозадачная система.

[pfemidi]

В CTask как раз через таймер многозадачность и делалась. А разве её можно сделать по-другому? Как вы правильно заметили, все шедулеры ныне этим и занимаются. Правда сейчас шедулеры не на int 8 сидят, а на RTC или ещё на чём, int 8 уже никто давно не трогает.

Эх… А когда-то игрушки CGA'шные, жутко большие, аж по 32 килобайта размером, садясь на int 8, и музыку играли 8-мибитную, и экран обновляли, а сев при этом ещё и на int 9 клавиатуру обрабатывали и даже (что мне казалось дико невозможным в то время!) блокировали Ctrl-Alt-Del.

[vvzvlad]

В win 3.11 такая и была, емнип.

[vitalyvitaly]

Интересна концепция машинки HP-150, она же Touch Screen, вышедшей еще до первой Windows, по железу это был не PC, совместимость только на уровне кастомизированной DOS, запущенной поверх «собственной многозадачной ОС» в ПЗУ. Компьютер мог работать и без DOS в качестве терминала. По крайней мере, вот, как это описано в ее мануале

The HP 150 system contains a large amount of system management code located in Read Only Memory. In general, the firmware is not designed to be utilized by
ystem programmers. The operating system BIOS serves as the interface to
irmware located functionality.
The HP 150 firmware is a rather complex multi-tasking operating system in
tself. MS-DOS runs on the firmware as a single task from the firmwares
perspective. Essentially all of the terminal functionality of the HP 150 is
mplemented in the firmware. The firmware implements much of the BIOS device
driver functionality in addition to the terminal personality.

[computershik73]

Пришлите мне дискету по почте :)
Или сходите в любое госучреждение/библиотеку. Флопики еще не вымерли. Даже у меня есть, вставил после апгрейда старого ПК на почётное место.
Upd: Да и забыл, сам работаю сисадмином в одном госучреждении, там осталась много раритетных дискет, в том числе и с MS-DOS ;)

[Pochemuk]

У меня даже года 2-3 назад был специально приобретен FDD-USB привод. Тому как если придется переставлять Win2K3 Server, то дрова на RAID нужно либо внедрять в дистрибутив, либо устанавливать с флоповода — других носителей Win2K3 на этом этапе не видит.

[potan]

Видел пару DOS-подобных 32-битных систем, в которых все программы размещались в общей памяти с OS и имели полный доступ ко всему железу. Выглядело интересно, но мне уже тогда надоело писать на C++ и ассемблере, а языки, которыми я увлекался, типа Haskell, там не поддерживались.
Может и сейчас что-то подобное живое есть.

[potan]

Вспомнил одну из.
Сейчас она под GPL.

[Hottych]

Ну на самом деле в 13ом режиме полноценную игру не сделать. Нужен mode X или Y с планарным представлением видеопамяти для быстрого битблитинга(простите за некрасивое слово).

[frog]

Большинство VGA'шных игр, включая самые известные, скажем, Sierra'овские, были в самом стандартном 320x200x256.
mode-x стали использовать позднее и не так уж часто. Потому что у него были проблемы с некоторыми видеокартами.

[Alexandr400]

Минимализм был когда-то в плюс. Программы так уплотнялись и зализывались (железо развивалось неспешно), что представляли из себя почти совершенство. Сейчас из за изобилия памяти код часто пишется небрежно, раздуто. Например какая-нибудь игрушка в 40 гб на диске содержит всего несколько шикарных локаций с туманом, заходящим солнцем и шевелящимися травинками — с прохождением в 10 мин. Но к прежнему методу не возврата. Этот бег не остановить.

[GutenMorg]

Да, Alexandr400, этот бег не остановить… Думаю, что наблюдаемый нами «вариант развития событий» выгоден и производителям ПО и «кузнецам железа». С одной стороны: можно быстро создавать монструозные (по объему кода) продукты с функционалом калькулятора, а с другой постоянно увеличивать продажи все более мощного оборудования…

[n0th1ng]

Потому что в играх выбор такой — скорость загрузки/графон/занимаемое пространство на диске. Можно выбрать только 2. В век терабайтных хардов и приставок с 50гб блюреем естественно жертвуют занимаемым пространством на диске.

[WRP]

Размер исполняемого файла калькулятора зависит в большей мере от компилятора

[schetilin]

Так здесь не про размер файла, а про размер памяти используемой калькулятором.

[WRP]

На размер памяти, используемой калькулятором, влияет много факторов.
Талант программиста один из них )

[saboteur_kiev]

Все-таки dosbox сейчас более выгодный вариант, чем виртуалбокс, в том числе и за счет рендеринга экрана. Оригинальное разрешение на современных мониторах слишком мелкое. А возможность любую старую игру смотреть в 2x/3x со сглаживанием — отлично возвращает в жизнь и MOO и KB и другие игры.

[Karpion]

DOS в сущности является операционной системой реального времени (ОСРВ).

Ну, это крайне спорное утверждение. Как минимум, существование резидентных (TSR) программ может помешать реалтаймовости. А ещё — в DOS отсутствует асинхронная работа с диском (пишите жалобу на BIOS), так что на период обращения к диску программа не может выполняться.

тончайший интерфейс DOS между приложением и оборудованием даёт ей преимущество в этой области использования

Осталось понять, зачем тут вообще нужен DOS, если выгоднее запустить 32-битную программу, которая сама в себе несёт драйвер для работы с файловой системой и всё остальное.

в режиме VGA 320x200x256

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

[el777]

Видеорежимы чем плохи? Понятно, что памяти мало, нужно было показать максимум возможного.
Конкретно VGA 320x200x256 вообще был один из лучших. Показать 256 цветов в то время — было очень круто. Понятно, что пиксели были громадные и даже на тех маленьких мониторах смотрелись как лампочки. Но все равно — это первый значительный шаг к какой-то нормальной многоцветной картинке. До сих пор помню картинку на обложке журнала ("Компьютерра" кажется), с которой заинтересовался этими возможностями и стал экспериментировать с графикой. Тем более рассчитывать координаты было довольно легко 320 = 2^8+2^6, вся видеопамять помещалась в 1 сегмент — можно было быстро и удобно перебрасывать картинку на экран.

[pfemidi]

320x240 обеспечивал так же небезызвестный «Mode X», доступный на всех VGA. Тот же режим 0x13, только в некоторые регистры видеодаптера записывались немного другие значения. Довольно много интро, демок и даже игрушек в то время в этом режиме было.

[goodwind]

Помню такой, как раз в книге Абраша кажется и описывался. Также он назывался Chain-4. Там была хитрая организация памяти, которая позволяла иметь 4 страницы видеопамяти по 64кб, которые шли одна за одной. Его было классно использовать для скроллинга экрана — ты просто смещал «окно». Или можно было одну страницу показывать пока рисуется на второй, потом перемещать «окно» на начало второй, получая практически моментальное обновление экрана. Крутая штука

[Tippy-Tip]

Нынешняя FreeDOS – 32-битная ОС.

[Karpion]

Если Вы лезете в железо напрямую — то зачем Вам вообще DOS? Это же ДИСКОВАЯ операционная система — а тут Вы лишаете её ейного основного заработка!

[geher]

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

DOS тут точно не при делах.
DOS вообще не поддерживал графику и работал в текстовом режиме.
Вся графика была на совести кода в ПЗУ видеоадаптера и работающих с видеоадаптером напрямую программ.
А видеорежимы определялись скромными возможностями электроники того времени: медленные процессоры, медленная и дорогая память.
Если тогдп кто-то забомбил бы хотя бы VGA, то оно стоило бы как самолет и рисовало бы со скоростью черепахи. А когда все ускорилось и подешевело, тогда и понеслось: сначала VGA, потом всякие XGA, потом всякие 3D ускорители.
Да и сами режимы не так уж и страшны. А уж для того времени они были огромным достижением.
А некоторые игры на графике CGA смотрелись лучше, чем некотооые современные игры на самых навороченных видеокартах.

[Karpion]

Вы не поняли.

Сначала IBM решила использовать ублюдский процессор и пригласила Балла Гейтса, заключив с ним особый контракт (можете рассказывать, что при капитализме не бывает коррупции). Это было два независимых решения с разной мотивацией.

Затем по ряду причин (не буду рассказывать — лень) эта платформа стала популярной — т.е. таких компьютеров с DOS стало много, для них было написано много программ. этот процесс — саморазгоняющийся. естественная монополизация рынка.

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

Что же касается «видеорежимы определялись скромными возможностями электроники того времени: медленные процессоры, медленная и дорогая память» — то Вы делаете мне смешно.
Начнём с того, что CGA был сделан так, что программисту приходилось извращаться и интерливом (т.е. строки экрана шли в памяти не подряд, а сначала все чётные, потом все нечётные). И ещё нельзя было обращаться к видеопамяти в момент работы луча — это портило картинку. Т.е. CGA безумно сильно грузил процессор.

Это ни разу не достижение. Это — самое настоящее капиталистическое вредительство. Особенно уродский VideoBIOS, в который так и не удосужились запихнуть нормальные драйверы типа BGI.

[geher]

Сначала IBM решила использовать ублюдский процессор.

Нормальный процессор для своего времени. Не надо его обижать.
Проблема была не в процессоре, а в том, что накрутили вокруг него. И в слишком сильной обратной совместимости следующих поколений компьютеров.

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

Вполне нормальное решение — адресовать большую память через небольшое окно. Так много где реализовано.
Естественно, архитектура диктовала аппаратные решения (например, размер сегмента). Но архитектура сама диктовалась поставленными задачами и узкими рамками возможностей (кстати, именно потому в первых PC был 8088, а не 8086).

И не стоит забывать, что основным предназначением IBM PC была совсем не работа с графикой. Отсюда и перекос в сторону передачи основной вычислительной мощи и памяти для программ, а не для "картинки".
Вот когда PC стал позиционироваться еще и как игрушка, тогда графические адаптеры стали постепенно самостоятельными компьютерами мощи и стоимости, сопоставимой с основной частью (а то и превосходящей).

Начнём с того, что CGA был сделан так, что программисту приходилось извращаться и интерливом (т.е. строки экрана шли в памяти не подряд, а сначала все чётные, потом все нечётные). И ещё нельзя было обращаться к видеопамяти в момент работы луча — это портило картинку.

А это все определялось совсем не архитектурой ЭВМ и не бедным DOS, а особенностями передачи данных из видеопамяти в монитор. Реализовать по другому тогда еще просто не могли, поскольку на той элементной базе получалось слишком сложно и дорого. Всегда приходилось чем-то жертвовать. Тут пожертвовали простотой работы с видеопамятью в пользу простоты реализации "другой стороны" (передачи всего этого добра в более дешевый монитор с чересстрочной разверткой).
И для того времени это было реально достижение.

Особенно уродский VideoBIOS, в который так и не удосужились запихнуть нормальные драйверы типа BGI.

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

[sav1812]

А это все определялось совсем не архитектурой ЭВМ и не бедным DOS, а особенностями передачи данных из видеопамяти в монитор.

Ой ли?? А «особенности» эти не разработчиками ли определялись? :)

Реализовать по другому тогда еще просто не могли, поскольку на той элементной базе получалось слишком сложно и дорого.

«Неправда Ваша, дяденька!» © :)

Вспомним «Специалист», разработанный, правда, несколькими годами позже, но на той же элементной базе, на отечественных аналогах TTL логики серии 7400 — К155.
Так вот в этой машинке разработчик (преподаватель ПТУ, к слову) как-то сумел «совместить приятное с полезным», обеспечив возможность «одновременного» обращения в области видеопамяти и процессора, и контроллера «дисплея».
Так что и «реализовать могли», при наличии на то желания, и не так уж и дорого — десяток-другой корпусов серии К155. :)

Всегда приходилось чем-то жертвовать.

Ну да… ну да… :)

[geher]

Ой ли?? А «особенности» эти не разработчиками ли определялись? :)

Разработчиками, но не DOS и не IBM PC, а видеокарты. Причем определялись исходя из стоящей задачи — сделать достаточно дешево.

Вспомним «Специалист», разработанный, правда, несколькими годами позже

Ключевые слова — несколькими годами позже.
Микросхемы подешевели, появились новые решения для аналоговой части.
При этом несколькими годами позже уже был EGA (на год раньше "Специалиста").
При этом "Специалист" был монохромным, что сильно упрощало аналоговую часть.
При этом графика "Специалиста" была монохромная.

[Karpion]

Нормальный процессор для своего времени.

Время этого процессора закончилось примерно при переходе с IBM-PC к IBM-PC-XT: на IBM-PC-XT он уже явно не тянул ту аппаратуру, которую ему поручали обслуживать.

Проблема была не в процессоре, а в том, что накрутили вокруг него.

Простите, а что вокруг него накрутили? HDD? Графический видеоадаптер? Так никуда же не деться — их в любом случае надо было прикручивать. У других систем прикручивали.

И в слишком сильной обратной совместимости следующих поколений компьютеров.

О!
А чем была обусловлена эта совместимость? Ответ: привязкой к DOS!
Не было бы DOS — можно было бы и процессор поменять (где-то здесь я рассказывал, как надо было делать: поставить два процессора, один для DOS-программ, второй для операционки и новых программ).

Те фирмы, которые сами контролировали архитектуру компьютера и операционку — меняли процессор; некоторые — неоднократно. IBM, HP, Sun, Acorn, Apple — меняли. И только писюки держались за совместимость — ибо аппаратуру и операционку контролировали разные фирмы.

Вполне нормальное решение — адресовать большую память через небольшое окно. Так много где реализовано.

Нет, это извращённое решение. Необходимость применять его много где — обусловлена нехваткой ума у проектировщиков при создании первой модели; либо нехваткой решительности у менеджеров при наступлении необходимости рефакторинга.

в первых PC был 8088, а не 8086

Это непринципиально: адресация и система команд у них были одинаковые, различалась только шина данных.

И не стоит забывать, что основным предназначением IBM PC была совсем не работа с графикой.

Значит, при появлении графики — нужен был рефакторинг. Не было бы DOS (точнее, этой дебильной системы разделения аппаратуры и операционки по разным производителям) — сделали бы.

Вот когда PC стал позиционироваться еще и как игрушка, тогда графические адаптеры стали постепенно самостоятельными компьютерами мощи и стоимости, сопоставимой с основной частью (а то и превосходящей).

Мы говорим о периоде «CGA-EGA-VGA». Игрушки были — но не являлись важной частью экосистемы.

Отсюда и перекос в сторону передачи основной вычислительной мощи и памяти для программ, а не для «картинки».
{...}
Тут пожертвовали простотой работы с видеопамятью в пользу простоты реализации «другой стороны» (передачи всего этого добра в более дешевый монитор с чересстрочной разверткой).
И для того времени это было реально достижение.

Вижу взаимно противоречивые параграфы.

Сложно было впихнуть много кода в ограниченный объем.

У меня ощущение, что Вы не видели объём кода BGI-драйвера.
Для разных видеокарт — от 4 до 8 килобайт (ну, те, что я для обсуждения этого вопроса просматривал — где-то в районе 1993-го года).

[geher]

Простите, а что вокруг него накрутили? HDD? Графический видеоадаптер?

Стандартизированную обвязку: контроллер памяти, шину ISA для карт расширения, выделенный диапазон памяти под BIOS и ПЗУ карт расширения, правила реализации ПЗУ плат расширения и т.п.

А чем была обусловлена эта совместимость? Ответ: привязкой к DOS!
Не было бы DOS — можно было бы и процессор поменять (где-то здесь я рассказывал, как надо было делать: поставить два процессора, один для DOS-программ, второй для операционки и новых программ).

Программная совместимость имела значение, но совсем не из-за "чужой" ОС.
У IBM имелась собственная совместимая ОС (PC DOS). После была еще куча систем, включая AIX и OS/2. Главное — совместимость со старыми программами.
Не буду спорить на предмет обоснованности такого решения с отказом от радикальной смены архитектуры, но современый яблокомпьютер при всей его привязке к одной конторе пришел в итоге к той же "убогой" архитектуре x86.

Нет, это извращённое решение. Необходимость применять его много где — обусловлена нехваткой ума у проектировщиков при создании первой модели; либо нехваткой решительности у менеджеров при наступлении необходимости рефакторинга.

Необходимость этого решения определялась всегда ограничениями архтектуры.
В частности, 16 бит процессор не может без извращений адресовать больше 64 К памяти.

Это непринципиально: адресация и система команд у них были одинаковые, различалась только шина данных.

Непринципиально для архитектуры, но принципиально для стоимости разработки периферии. Новая перифеоия под 16 бит процессор сильно повлияла бы на цену конечного продукта.

Значит, при появлении графики — нужен был рефакторинг. Не было бы DOS (точнее, этой дебильной системы разделения аппаратуры и операционки по разным производителям) — сделали бы.

Про рефакторинг согласен. Но DOS тут никаким боком, поскольку с графикой он не работал вообще. Ничто не мешало сохранить текстовый режим и навернуть что-ть новое для графики.

Вижу взаимно противоречивые параграфы

Противоречия нет.
Хотите быстро — вот вам текстовый режим.
Хотите графику — мучайтесь.
Не зря в бизнесе первое время преобладал совершенно текстовый MDA, у которого, кстати, текст качественней отображался и часто параллельный порт для принтера имелся.

У меня ощущение, что Вы не видели объём кода BGI-драйвера.
Для разных видеокарт — от 4 до 8 килобайт (ну, те, что я для обсуждения этого вопроса просматривал — где-то в районе 1993-го года).

Проблема доайверов для поддержки графических режимов видеокарт не являлась проблемой DOS, поскольку та с графикой не работала.
ПЗУ самой видеокарты содержало достаточно своего барахла, чтобы добавлять туда еще и драйвера. И ни у кого не возникало желания увеличивать это ПЗУ еще на несколько килобайт.
Потому вся забота о графическом выводе легла на программистов, работающих с графическими программами. А у них со временем появились стандартные библиотеки, избавляющие от гемороя прямого "общения" с картой.
А с появлением более других графических ОС стало логичным размещать драйверы не в ПЗУ видеокарты, а включать их непосредственно в ОС, что существенно упросьило их обновление в случае необходимости.

[pfemidi]

Не было бы DOS — можно было бы и процессор поменять (где-то здесь я рассказывал, как надо было делать: поставить два процессора, один для DOS-программ, второй для операционки и новых программ).

Для Apple ][e в своё время существовала Z80 SoftCard, правда от Microsoft, а не от самого Apple, плата расширения с Z80 и минимальной обвязкой. Вставляешь её в слот на материнке и Apple ][e превращался в комп с Z80, на котором можно было запускать вполне себе обычный CP/M. Я даже реально это дело руками щупал.

[iZENfire]

В частности, 16 бит процессор не может без извращений адресовать больше 64 К памяти.

Вы что-то путаете. Ширина шины данных не имеет никакого отношения к ширине шины адреса — восьмибитный Zilog Z80A может адресовать 65536 байтовых ячеек памяти напрямую, потому что у него разрядность шины адреса 16 бит.
У 16-битных Intel 8086, 80186 разрядность шины адреса 20 бит, поэтому для прямой адресации им доступен 1 МБ памяти 16-разрядных ячеек. У 16-битного Intel 80286 разрядность шины адреса 24 бит, поэтому для прямой адресации ему доступен 16 МБ памяти 16-разрядных ячеек.

[MacIn]

Вы говорите о разном: человек сказал об «адресовать за раз без извращений», а вы говорите о доступной памяти. За раз можно адресовать только один сегмент, 64к, после чего его надо переключать. Регистр 16 битный — адресуется за раз 64к. А так-то можно, если переключение страниц аппаратно через регистры реализовать, и на 8080 хоть гигабайт использовать.

[iZENfire]

Да, вы правы, в ранних x86-процессорах Intel была реализована так называемая «сегментная» адресация реального режима с размером одного «сегмента» до 64k. По этой причине программы DOS формата .COM не могли иметь размер больше размера сегмента — для больших программ приходилось использовать формат .EXE и (или?) оверлейную структуру программы.

[MacIn]

И. Оверлейная система может перегружать оверлеи в exe.

[Pochemuk]

Союз «или» здесь не подходит — COM-файлы не могли быть оверлейными. Это просто кусок исполнимого кода в формате «as is».
И грузится в память за один раз полностью.

Другое дело EXE-файл. В его заголовке есть информация о размере изначально загруажемой части. А остальное может подгружаться позже по мере необходимости в отдельные области памяти.

[artemisia_borealis]

А ещё ведь под DOS прекрасно LaTeX работал, называлось всё это emTeX.
Вот, например, LaTeX installation instructions for emTeX.
Книжки, статьи, дипломы, диссеры прекрасно писа́ли.

Справедливости ради надо и про экстендеры памяти вспомнить, emm'ы там всякие, ну, т.е. 640К всё же маловато было и расширение даже до 1М это было круто и желанно.

[divanus]

В 2013м году перенес жкх БД из фокспрокса в юзабилити 1с :)
Было весело и приятно вспомнить школьные годы и реально круто решить проблему одной управляющей компании — разработчик просто умер уже и никто из 1с интеграторов не мог подойти :)

[h0use]

Вспомнились теплые, ламповые истории про Коммандера Кома и Коммандера Нортона.

В работе с памятью emm386.sys наше все, особенно с загрузкой ядра в верхние страницы памяти, освобождали все 640к памяти.

[Pochemuk]

Да… Такие фичи здорово облегчали жизнь.

Насчет 640K не уверен, а вот 1024K, действительно, хватало много для чего, если с умом подойти, а не тяп-ляп.

Лет так 25 назад наваял одну программу для расчета с потребителями на СУБД Clarion. Экзешник весил около 800K. Даже если загрузить драйверы в верхнюю память, она в доступные после этого 580K не лезла. Хорошо, что Clarion поддерживал оверлейные структуры. Написал утилиту, которая анализировала вызовы процедур, обнаруживала циклы, рекурсии и взаиморекурсии, строила дерево вызовов и распределяла модули по оверлейным областям. Так, чтобы вызывающий и вызываемый модуль загружались в разные оверлейные области. Это чтобы вызываемый не затирал данные в вызывающем.
В результате памяти стало хватать на всё :)

И эта программа прекрасно работала под DOS, Win95/98, WinXP. А вот под Win8/8.1 не работает :( Тому как в Win8 прекратилась эмуляция DOS. Приходится запускать ее из DOSBox. Но в этом случае нет вывода на LPT. Поэтому вывод делается в файл (вместе со всеми управляющими символами), а потом этот файл распечатывается из Винды.

В общем, несмотря на то, то «1С: Управление снабжением» закупили еще 2,5 года назад, ее до сих пор внедрят никак. А моя программулина, несмотря на все недостатки и несоответствия законодательству, с помощью всяких костылей еще активно используется.

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

[geher]

Насчет 640K не уверен, а вот 1024K, действительно, хватало много для чего, если с умом подойти, а не тяп-ляп.

Когда-то и 64К хватало.
Видел в свое время, как народ на компьютере из коры и веток (был такой Корвет) творил.

[Pochemuk]

:) Ну так тут речь плавно свернула на полноценную DOS. А последние ее версии на 64K как бы вряд ли встанут. Разве что само ядро в урезанном виде.

Что касается специализированных ОСей, то читал где-то как FORTH-машину на контроллер с 16K заливали. И ведь поместилось же! И сама машина и управляющая программа под ней.

[FForth]

Да, Вы правы классический вариант Форт-системы помещается примерно в 8Кб флеш контроллера.
В рамках PC есть и проект OpenBios www.coreboot.org/OpenBIOS на базе стандарта IEEE 1275-1994 активно используемом в Sun компьютерах. Во FreeBSD Форт тоже используется в качестве загрузчика, а Форт системы под DOS тоже многофукциональны.

P.S Язык Форт в СССР и России www.computer-museum.ru/histsoft/fortran_sorucom_2011.htm
Астро-Форт (И.Р. Агамирзян) Была очень функциональна (с многочисленными пакетами расширения) под ДОС. Сейчас тоже есть Форт системы ещё развиваемые авторами в рамках ДОС (DX-Forth)

[MacIn]

В 64 битном режиме ведь нет виртуальной машины 8086? Она ведь должна была использоваться NT для эмуляции DOS.

[DRDOS]

Когда ностальгируешь можно еще не то надумать!
С системами реального времени вы как то погорячились :)
Лучшая операционка это OS/2… Жаль такой шедевр угробили :(

[sav1812]

OS/2 была лучшей DOS… :)
Помню, как 386-я машинка с 8 Мб оперативки и OS/2 Warp 3.0 второй системой были счастьем для женщин-медстатистиков в таёжном Приморском селе, которых замучала долгая перезагрузка системы из-за регулярно виснувших программ, «накорябаных» какими-то «варягами на Clipper.
А тут — диспетчер задач, и все проблемы. :))

[Shtucer]

Ну, диспетчер задач изкоробочный там был так себе. Ежели какой криворук в своем приложении повесит очередь сообщений PM, то все, и диспетчер не запустится. Спасал только WatchDog (или я забыл как он назывался, столько лет уже утекло).

[pfemidi]

В OS/2 был WatchCat, который с началом буржуйского рождества рисовал в ВарпЦентре иконку с котом, одетым в рождественскую шапку (в остальное время кот был без шапки) и в полуосёвых конференциях говорили: «Кот шапку нацепил!» и все кто был в курсе понимал о чём речь, отвечая: «Ну значит скоро Новый Год!»

А насчёт переполнения PMQUEUE был какой-то параметр в config.sys, может быть даже недокументированный, но был. Как раз против этого дела. Помню точно что был, но за давностью лет уже не помню какой.

[Shtucer]

Какой-то был, да. Но без WatchCat всё равно как без рук. На его фоне подоспевшая 4 NT с её Ctrl-Shift-Esc была вообще молодец. Но полумуху я любил не за это, конечно.

[sav1812]

Ну, диспетчер задач изкоробочный там был так себе. Ежели какой криворук в своем приложении повесит очередь сообщений PM, то все, и диспетчер не запустится.

Насколько я помню, это касалось «родных» приложений OS/2.
Не припоминаю, чтобы систему можно было «убить» из сеанса DOS. А большего мне и не нужно было. Народ и так был счастлив: ­всё познавалось в сравнении. :)

[pfemidi]

На любом процессоре без VME (а VME в те времена был только у Intel) достаточно в сеансе DOS запустить следующий код:

cli
jmp $

и вуаля, полное подвисание всего кроме кнопок Reset и Power. Чем мы, апологеты Интела, в своё время тролили любителей AMD. Правда сейчас у любителей AMD появилась ответка в виде Meltdown, которому Intel подвержен, а AMD как выяснилось нет.

[sav1812]

На любом процессоре без VME (а VME в те времена был только у Intel)

Вот я и говорю — всё работало нормально. ;) :)

И потом, Вы приводите случай злонамеренного нарушения работы системы, а меня интересовало решение проблемы нестабильно, некорректно работающих программ.
Была, помнится, в Clipper такая проблема: при попытке сохранения из программы на дискету, если дискета в дисководе отсутствовала, программа «вешалась» и, соответственно, требовалась перезагрузка системы. Ошибку отсутствия дискеты «программисты» обработать корректно почему-то не сочли необходимым.
Перевод этих «шедевров программистского зодчества» в сеанс DOS под OS/2 проблему решил хотя бы в плане сокращения потерь времени на «перезагрузку».

Большего я тогда добиться не мог — разработчик переписывать своё творение отказался — а пользователи и этому были очень рады. :)

[MacIn]

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

Это жонглирование словами, не более. Замкнутый цикл — вполне себе «некорректно работающая программа».

[speakingfish]

Для многозадачности под DOS достаточно было DesqView. Софт прекрасно работал и в тексте и в графике; и форматирование дисков не тормозило всю систему, в отличие от Win9x.

[speakingfish]

О, да. Только в OS/2 был DOSBox из коробки — и можно было в окне запустить с дискеты загрузочный диск, например некоторые игры под DOS делались как загрузочные диски.

[Nomad1]

Выше много чего славного вспомнили, но все же, keyrus.com, коллеги. RIP, Dmitry Gurtyak.

[goodwind]

keyrus был, пожалуй, на всех машинах которые я тогда видел. Сначала я даже думал что это часть ОС, но потом мне по знакомству скопировали оригинальный дистрибутив MS-DOS 6.2 и я был неприятно удивлен

[svitoglad]

Это вам значит не приходилось MS-DOS с нуля ставить поэтому и не знали о keyrus.

[goodwind]

о чем, собственно, и был мой комментарий

[OldGrumbler]

Эх, ностальгия… когда-то русификатор rk (тот, что менял раскладку по двум шифтам и вместо буквы «Ё» рисовал три черточки ☰ ) был мной расковырян и снабжен редактором раскладки. Под дос, с псевдографикой и, кажется, драг-н-дропом. Можно было в русской раскладке разместить любые символы. Конечно же, в первую очередь Н и р из латиницы — потому что FIDO )))

[MacIn]

Гораздо круче в той эпохе смотрятся Norton Utilities, котрые рисовали псевдографикой с подменой символов на ходу, чтобы рисовать мышь и границы окон.

[speakingfish]

Для красивых границ окон обновляли знакогенератор при старте. Только мышь на лету обновляла знакогенератор. Я тогда тоже делал такую «графическую» мышь — в виде библиотеки и резидента.

[MacIn]

Только мышь на лету обновляла знакогенератор

Об этом и речь.

[sav1812]

Да, спасибо человеку за его труд и светлая память…

[Dioxin]

На Спектруме я мечтал о 640 КБ ОЗУ.
И да — весь код только на асме.

[Alyoshka1976]

Я мечтал запустить на нем CP/M. Хотя ISDOS тоже была неплоха.

[zabbius]

У меня тогда шаблон порвался. Поскольку на момент моей встречи с IS-DOS, ИскраСофт давно торговали коврами, а не писали софт для спектрумов. Отдельно запомнился хак, который заставлял TR-DOS выполнять код с дискеты при любом обращении к ней.

[vladd12]

Ностальгия, которой у меня не было, но увы и ах) DOS всегда красив.

[ainoneko]

DOS всегда красив.

Песня про DOS.

[kazenniy]

Чудесный мир некромантии.

[goodwind]

Спасибо что не назвали некрофилией. Некоторые это так зовут

[hdfan2]

Да, славные были времена. Хорошо, что они уже кончились.

[jia3ep]

Некоторое время назад тоже решил разобрать старые диски и даже комп 286 приобрел под это дело. Какие-то проекты удалось восстановить с дискет и их код попал на GitHub. Вот, например, редактор шрифтов под DOS, написанный на Паскале: github.com/codeatcpp/Font-Editor

Интересно, что дискеты до сих пор читаются, но на запись уже работают не идеально. Наверное процесс восстановления данных, особенно с 5'' дискет или с кассет DC600A — это отдельная тема.

[aborisoglebskiy]

Неизгладимое впечатление оставил windows 1.0, кажется, влезавший на 1.44 флопик. В составе было 4 или 5 приложений, в том числе Corel для векторной графики.

[psy06]

Эх ностальжи :) Мы с приятелем на 3м курсе Техноложки сделали в качестве курсача Арканоид, с крутым 256 цветным графоном и 3Д заставкой зарендеренной в 3Д Студио 2.0. Все графические элементы поместились в один файл размером 320х200, а спрайты взрывов я покадрово срисовал с Command & Conquer…

[iZENfire]

На кнопочных мобильных телефонах Nokia долгое время можно было загрузить J2ME-игру или приложение размером не больше 64КБ. Мобильные телефоны Sony-Ericsson в своём расцвете позволяли работать с jar-файлами свыше 128КБ, запускать несколько приложений и переключаться между ними по специальной кнопке и пункту экранного меню. На продвинутых смартфонах Nokia можно запустить Age of Empires III The Asian Dynasties на экранах с разрешением от 320x240 до 360x640 пикселей. Размер J2ME-приложения (jar-файла) при этом около 700КБ. Конечно же, это — «лебединая песня» старых технологий, достигших совершенства при таких ресурсах, включая ограниченный объём оперативной памяти и зачатки 3D-акселерации.

[harlong]

Эх, были времена, двухбайтовый com-файл срабатывал…
0xFA (cli)
0xF4 (hlt)