Как стать автором
Обновить

Комментарии 74

Оптимизация памяти не умерла, как бы много памяти не было бы выкуплено, если криво ей пользоваться, то ее никогда не хватит. Алгоритмы изменились, это да.

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

Борьба за проценты все еще выгодна, только уже в другой области – где используют слабые однокристаллки (SoC). Там "влез" по памяти и быстродействию в более дешевый чип – сэкономил, например, $2 на каждом устройстве. А серия в 10 тыс. штук. Как правило профит в $20k окупает содержание программистов, умеющих в оптимизацию.

сэкономил, например, $2 на каждом устройстве

Заменил stm32 чем то типа attiny? ;)

Почти :)

Например, ужался и в STM32F7xx серии влез в младшую модель на $1.4 дешевле (там цены в районе $10). А тот чип еще и в корпусе LQFP-144 вместо LQFP-208 (допустим линий I/O нам хватает там и там). Это 64 точки пайки, примерно по $0.01 каждая. Чуть меньше надо места на плате, чуть проще трассировка, чуть выше ремонтопригодность...

Мелочи. И все-таки на крупных сериях из них набегает заметная дельта по стоимости производства и обслуживания.

STM32F7xx

Монструозная палочка-выручалочка олдскулов, которые патологически не желают учиться линуксу, в котором из коробочки можно получить и сетевой стек, и драйвера камер, аудиокодеков, дисплеев, вместо того, чтобы полгода все это поднимать ручками. На ФОТ сливается многократно больше сэкономленного на стоимости камня.

Инструмент выбирается под задачу. Где-то линукс в самый раз, где-то RTOS, и там тоже есть драйвера периферии и различные стеки "из коробки". А иногда приходится отказываться не только от ОС, но и от HAL библиотек, и делать закат солнца вручную. Глазами отсматривать, какой ассемблерный код сгенерил компилятор и бороться, без преувеличения, за несколько тактов на самых горячих участках. Задачи разные бывают, как и железо.

Что выгоднее: влить деньги в "железо подороже + Linux" или "железо подешевле + bare metal + ФОТ", тоже зависит от вводных. Это если по уму. А если жить по принципу "пофиг на себестоимость, за все платит пользователь", то мы с этого и начали ветку )

влить деньги в "железо подороже + Linux" или "железо подешевле + bare metal + ФОТ"

Процессоры под линукс зачастую дешевле громоздких stm32f7xx. Даже с учётом внешней DDR3.

Процессоры под линукс зачастую дешевле

Не соглашусь с формулировкой. Иногда дешевле, но не зачастую.

Если не трудно, приведите конкретный пример недорого SoC и задачи, которую мы решаем, работая под Linux. Чтобы понимать, какие в этом случае есть альтернативы.

приведите конкретный пример недорого SoC

Для более предметного разговора можно было бы уточнить конкретный парт намбер вашего камня и что за устройство вы разработали (применяемые интерфейсы, периферия).

Предположим, вы используете STM32F767ZGT6. Стоит $7.88 за партию 120 штук.

Для сравнения процессоры:

  1. MCIMX6Y2CVM08AB - $5.84 за партию 150 штук. Наша рабочая лошадка. У нас целая линейка серийно выпускаемых устройств на нем основана: базовая станция LoRaWAN, станция высокоточной навигации GNSS RTK, блок управления ГРК АГНКС/ПАГЗ, ПЛК контроллер, устройство SIP телефонии. Плюс несколько изделий на этапе разработки.

  2. T113-S3 - $4.25 за партию 90 штук. Встроенная память DDR.

  3. T113-i - $3.92 за партию 120 штук.

  4. RV1106G2 - $4.12 за партию 152 штуки. Встроенная память DDR.

  5. RK3308B - $3.82 за партию 120 штук.

  6. STM32MP151CAB3 от того же STMicroelectronics - $3.92 за партию 200 штук.

  7. STM32MP157AAC3 - $6.97 за партию 100 штук.

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

RP2040 в разы дешевле, а Linux на нём умудрились запустить.

Спасибо за список. Allwinner и Rockchip довольно нишевые, кмк, я раньше в эту сторону не смотрел. Теперь буду иметь в виду.

Всем чипам из списка нужна внешняя NAND, большинству – DDR. Было бы честно плюсовать их к стоимости процессоров. В целом решение получается намного круче "голого" STM32F7xx, это очевидно.

Но иногда такие объемы памяти просто не нужны. А нужен deep sleep с потреблением в несколько мкА и сохранением состояния системы.

Что было в моем случае: если упрощенно - приемник и ретранслятор. Слушал несколько каналов (цифровой поток порядка 1 Mbps); демодуляция, декодирование и разбор протокола – в софте. Снаружи там чисто аналоговая часть, выход компаратора с детектора огибающей смотрел прямо в чип.

Сохранял услышанное на SD карту. Что-то должен был передать дальше. Собственно, большую часть SRAM съели буферы, сам код и логика были достаточно простые. Батарейное питание. Конфигурация – через файл на той же SD карте.

Точную модель контроллера уже не вспомню, простите. Что-то из F7хх серии в корпусе LQFP-144.

А ещё жрёт чуть больше. Свой МК можно хоть после каждого кадра спать отправлять

А если вы работаете от батарейки? Есть подозрение, что уводить в сон/будить такой процессор с запущенным Linux энергетически дороже, чем stm с rtos/проприетарным кодом.

Так тут опять ответ зависит от кучи вводных. С одной стороны смартфоны и прочие гаджеты на Linux/Android давно работают от батареек. С другой стороны, на копеечные Padauk не то что Linux, даже RTOS не влезет.

Так же и с RAM. Если она статическая, то может потреблять буквально микроамперы. А если динамическая - то потребление подскакивает на порядки и от CR2032 её не прокормить.

Ну и наконец, насколько вообще в данной задаче нужен Linux? Например, реализовать аналог OpenWRT на HAL можно, но стоимость такой разработки будет астрономическая. И наоборот, для беспроводного датчика температуры и влажности с LCD индикатором восьмибитного МК хватит. И будет он больше года от CR2032 работать.

Можно было б списать на олдскулов, если б они стоили пять копеек за пучок. Бизнес рулит, наймёт и ньюскулов и рептилоидов, если это актуально.

Вот навскидку несколько позиций, которые актуальны, кроме цены:

  • потребление,

  • габариты, вес,

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

  • требование национального производителя, внутреннее производство, санкции и т.п.,

  • сертификация для определённого применения.

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

несколько позиций, которые актуальны, кроме цены

ФОТ забыли. В текущих реалиях ФОТ является определяющим фактором. Железо в наше время стоит дешево как грязь. Экономить доллар-два в себике изделия при зарплатах $2000+ бессмысленно. Собственно поэтому экономически мало оправдано что-либо разрабатывать в России. При таких скромных объемах рынка затраты на разработку рискуют не окупить никогда. Ситуация усугубляется тем, что из-за

инерционности знаний и мышления

олдскулов, которые так и норовят удариться в полугодовую реализацию с нуля того, что уже давным давно было разработано и подключается в сборку линукса одной строчкой: сетевой стек, аудиокодеки, видеокамеры, юсб устройства и т. д. Еще на этапе разработки обнуляют перспективы коммерциализации продукта, зато потом ходят надувают щеки: вот, сэкономил доллар... А то, что ФОТ раздулся на $20000 выше запланированного мало кого интересует.

ФОТ я б всё же выделил в отдельный топик. Тут надо осторожно как с изобретателями велосипеда, так и с любителями попробовать новый фреймворк, про который прочитал или услышал, так и с всё переписать фром зе скретч.

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

Короче, соблюдать баланс, всё считать и учитывать мнение и возможности коллег

А то, что ФОТ раздулся на $20000 выше запланированного мало кого интересует.

Работать с известным устройством - это обычно уменьшает и ФОТ, и прочие затраты, чем строить проект на пусть более гибком, но неизвестном устройстве, по которому нет ни опыта применения, ни знания подводных камней. Так-то вышеперечисленное и для STM32 существует, и имеет софтовую поддержку.

Расскажите, как линукс позволит сократить ФОТ, если в требованиях к устройству чётко сказано "работать не менее 90 дней от двух аккумуляторов типоразмера 18650" . Довольно массовое устройство, я лично принимал участие в его разработке.

полугодовую реализацию с нуля того, что уже давным давно было разработано и подключается в сборку линукса одной строчкой

Любители расставлять галочки в конфигураторе легко впадают в ступор на пол года, когда дело доходит до жесткого тайминга (это когда RTOS не вывозит). Банально подключить десяток i2c/1w уже надо уметь, чтобы данные не терялись. Не говоря уже про управление силовыми ключами.

У вас просто задачи такие. Блок тормозов в машине у вас тоже на линуксе? Или любой промышленный частотник? Или пульт от ворот? Миллион применений где линукс даром не впился.

Самый интересный вопрос после такого рассказа:

Какой процент сэкономленных денег (т.е. сэкономленных на 1 экземпляре девайса * кол-во девайсов в партии) достаётся потом инженерам, которые всё это наэкономили?

Из личного опыта: не больше 10% в виде разных бонусов (премии, повышения, небольшой процент с продаж конкретно этих девайсов и пр). Но собственный опыт – слишком маленькая выборка )

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

Предвидя возражения, уточню: это не про затягивание разработки (сроки и TTM никто не отменял), а про окупаемость затрат на "мозги" и на "сделать хорошо".

Кому мало RAM будет - пусть новый компьютер покупают!

Рекламный девиз мелкомягких.

Рекламный девиз мелкомягких

А что этот девиз рекламирует? Какие именно компы? :)

Любые, лишь бы поддерживали Windows11.

Любые

Интересная рекламная стратегия ;) Никогда не видел, чтобы рекламировали любой стиральный порошок или любой автомобиль,( чтобы ездил). А с компами это работает

Есть альянсы производителей, венчурные фонды (под которыми ряд перспективных стартапов, которые почти гарантированно взлетят, если чуть заранее спровоцировать спрос), и реклама без бренда - это давно такая же обычная вещь, как и классическая реклама. Просто она тоньше и аккуратнее классики, так как ее цель не грубо впарить и забыть, а отрытие новых рынков либо создание потребности в том, что до этого было никому не нужно. Тут важно не спугнуть потенциального потребителя.

купил тут на днях себе Macbook Air 13 M4, внезапно сразу же после запуска с запущенным Safari занято 7 из 16 GB, ну спасибо майкрософт, и тут переиграл меня)

Видимо такие компы, на которых пойдет вин11. Если у тебя комп ее не тянет - продай, сдай в утиль и срочно беги за новым. Что значит "тянет"? Винда ругается- значит плохой, негодный комп. Им то по барабану, чей комп ты купишь, им главное свою систему втюхать и завязать на свое облако.

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

Интерфейс компьютера Next был лучше, чем у Windows, однако всё в итоге решает цена...

Интерфейсы Next унаследовала MacOS, они не исчезли просто так. В том числе, Виндовс 11 позаимствовал различные моменты из MacOS.

Жалкая копия и неповторимый  оригинал
Жалкая копия и неповторимый оригинал

Где оно в Макосе? И тем более в Виндовс...

ЗЫ: Про Полуось в статье на том сайте дальше, это не подпись, а заголовок )

Предполагаю, что имеет место излишнее обобщение. Next явно повлиял на MacOS X ранних версий, скриншоты можно посмотреть тут. Microsoft заимствовала дизайнерские решения Apple - мне это стало очевидно после того, как удалось потыкать старенький G4 после нескольких лет с Windows 7. С Win 11 уже не работал, так что и говорить про неё не буду

Три колонки внизу слева — Finder, слева сверху — меню, только оно теперь горизонтальное вверху, справа — Dock, теперь внизу горизонтально. Классы с префиксом NS — это из NextStep.

Ну так я именно об интерфейсе говорю, а не о классах: изменилось расположение, в сторону "горизонтальных баров".

Почему-то многим это удобнее (как в Виндовс?), хотя ИМХО как раз в оригинальном варианте было лучше:
- меню бывает нужно разве что в самом начале, потом всё на хоткеях - зачем же оно постоянно место отжирает зря?
- док полезен для апплетов-индикаторов, которые всё время на виду, и при этом сбоку для них можно выделить больше места, чем в горизонтальном трее. Особенно на широкоформатном экране - он и так широкий

Ну, в общем, вкусовщина )

микропроцессоры Motorola были лучше, чем интелловские

В плане адресации - да. В остальном - нет. Когда пришла возможность делать out-of-order исполнение, для десктопных процессоров это начало 1990-х, линия m68k умерла потому, что была over-CISC в массе деталей, как именно исполняется команда, какое количество и сложность режимов адресации, и введя эти детали в спецификации своего ISA. А у x86 такого ограничения не было. По тому, например, что в командах (кроме строковых и всяких служебных) не более одного операнда в памяти, она оказалась ближе к требуемому в новые времена (RISC) и потому выжила. Конечно, правительство этому помогло (см. историю про ASCI Red), но это лишь ускорило на несколько лет неизбежную смерть m68k. А у x86 к тому времени был отлаженный 32-разрядный режим.

(Кстати, почему только 16MB? Адрес 32-разрядный, значит, наступал период обновления. Немного раньше S/370 прошла этот путь, 370/XA расширило адрес с 24 до 31 бита. И там было много граблей в первую очередь с софтом, пришлось добавлять режим 24-битной адресации для старого пользовательского кода, а ядерный пришлось массово переписывать, где он зависел.)

Не только в плане адресации. Защита памяти 8086 — нет, 68000 — есть. Режим супервизора — 8086 — нет, 68000 — есть. А главное — 8086 — архаичная система команд со всякими аккумуляторами и специальными регистрами типа sx, dx, 68000 — ортогональная к регистрам, очень логичная система команд.

[​​1. С семейством m68k надо сравнивать 80386 и далее, а не 8086. Защита памяти появилась в 80286, но не страничная. В линии m68k она появилась не в 68000, а в 68010, а это уже 1982 - то есть он ровесник 80286; но у 68010 это требовало внешнего MMU, решение было не из дешёвых (тогда). 68020 аналогично требовал внешнего MMU. Только с 68030 они смогли впихнуть MMU внутрь, а это уже 1987, через два года после 80386.

​2. Неортогональность по регистрам в 32-битном режиме x86 значительно снижена - именно там, где она била больше всего (режимы адресации). То, что она остаётся и сейчас в вариантах типа косое умножение с результатом в xDX:xAX, переменный сдвиг в CL - ни на что реально не влияет.

​3. У m68k нет полной ортогональности по регистрам. Например, можно добавить содержимое D-регистра к памяти, но нельзя то же самое для A-регистра. К A-регистру нельзя добавить произвольную константу. ADDx (аналог ADC) не работает на A-регистрах. То же про битовые операции. Однобитовые операции типа BFCHG не разрешены почему-то для режимов типа (An)+. Когда вы говорите

ортогональная к регистрам, очень логичная система команд

вы почему-то игнорируете все эти тонкости и нелогичности.

​4. Зато есть безумные двойные косвенные режимы типа ([bd,An],Xn,od). Именно они убили всю архитектуру: перевести их на out-of-order исполнение оказалось просто невозможно, причём не технически, а административно: кто-то постановил, как именно в каком порядке они проходятся, для возможности восстановления с любой промежуточной точки. X86 как более примитивный таки избежал этого.

Мне, конечно, нравятся некоторые аспекты m68k, но именно из-за описанного в конце не считаю её настолько лучшей. Мнение типа "m68k была заведомо лучше x86" - это чистый туман размытых воспоминаний, подкрепляемый фанатичными ненавистниками x86. Я пытаюсь быть объективным:)

С семейством m68k надо сравнивать 80386 и далее, а не 8086

Ага, давайте сравнивать 68000 из 1979 с 80386 из 1985

Защита памяти появилась в 80286, но не страничная

И оказалась даром никому не нужна. А ещё и адресация осталась 16-битной. Это через 3 года после 68000.

через два года после 80386.

То есть выяснили, что страничное MMU в 68k появилось за 3 года до 386.

Например, можно добавить содержимое D-регистра к памяти, но нельзя то же самое для A-регистра.

А давайте ещё регистры посчитаем. 8 штук D и 7 штук (не считая стека) A. А в х86 ВСЕГО 7 регистров. Или это не считается? Тогда становится неясно зачем амд добавило r8..r15 регистры, наверное дураки были, ведь и так было всё офигенно замечательно с "равноправными" регистрами, их 7 штук хватало всем.

кто-то постановил, как именно в каком порядке они проходятся,

Насколько я помню, в 68060 команды не могли продолжаться, только заново переисполняться. Ну и в x86 можно найти ужасы, типа rep movsb. И ничего -- живут как-то, на "микрокоде" дешифруют и исполняют. Так что это плохой аргумент -- технические проблемы вполне решаемые для OoO.

это чистый туман размытых воспоминаний

А вы сколько килобайт кода собственноручно написали для 68к? А то вдруг

Я пытаюсь быть объективным

окажется не очень правдой.

А ещё и адресация осталась 16-битной. Это через 3 года после 68000.

где вы видели в х86 16-битную адресацию? Наверное имелось ввиду, что адресация не стала 32-битной? Ну так и не должна, процессор то 16-битный. Однако по сравнению с 8086 и 8088 количество адресных линий возросло с 20 до 24

Так многие опускают, что память напрямую связана и с быстродействием. Приложение хоть раз должно записать и хоть раз прочесть что-то из выделенной памяти. А скорее всего много, много раз. Если память много, то и время обработки большое. Если мало, то и программа быстрая. Конечно, все несколько сложнее, но суть такая.

Вот только если вспомнить, что оперативная память - это промежуточная память между кешем CPU и внешними носителями информации, то всё начинает выглядеть иначе. Посмотрите на зависимость производительности почти любой СУБД от доступной ей оперативной памяти и сразу поймете, о чем я веду речь.

Речь вообще не про производительность. И не про СУБД.

А тогда при чем тут "быстрая программа, если памяти мало"?

BIOS начинался с 0xF0000, а вот видеобуфер как раз с 0xA0000. И именно он ограничивал память основного сегмента. Загружая драйвера и некоторые резидентные программы в свободные области памяти между видеобуфером и BIOS, можно было заметно сэкономить память в основном сегменте.

Самое смешное, что уже в i80286 DOS получал доступ к дополнительным ~64К памяти, благодаря тому, что смещение относительно сегментного регистра могло пересекать мегабайтный барьер.

Точно, там же еще видеопамять была )

Самое смешное, что уже в i80286 DOS получал доступ к дополнительным ~64К памяти, благодаря тому, что смещение относительно сегментного регистра могло пересекать мегабайтный барьер.

HMA, ага, поздние ДОСы умели использовать эту область и предоставляли API, чтобы выделять там память.

На самом деле ограничение 640К, это не из-за подпрограмм BIOS, да и вообще такого ограничения не было ни в IBM PC, ни в IBM PC XT. Это ограничение появилось только в компьютере IBM PC AT в 1984-м году, потому что после 640К там начиналась область видеопамяти для EGA-адаптера.

В PC XT же можно было поставить с помощью плат расширения до 704К, если там видеоадаптер MDA, или до 736, если там CGA

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

Платы расширения памяти а-ля RAMpage тогда стоили совсем уж неприличных денег. И это был единственный способ расширить не так чтобы и большую память тех компов. Привычных планок памяти тогда же ещё не было, память просто распаивалась на материнке, и её там было мало. Ранние IBM РС умели только в 64К памяти, потом в РС ХТ максимум стал до 256К, и АТ увеличила до 512К.

Не совсем так. Как я помню, первые IBM PC поддерживали до 256кб. PC XT уже поддерживали до 640кб. Я сам тогда пользовался Искрой 1030 с 512Кб памяти. AT уже были на 286 процессоре и могли, вроде, то ли в 4Мб то ли в 16Мб - тут точно не помню уже

Неа, первые IBM PC поддерживали или 16, или 64К памяти, это было обусловлено чисто технически, там ОЗУ было на том древнем n-MOS процессе,который требовал напряжение смещения подложки, соответственно, на материнке не было даже разведено соответствующих линий адреса, эти пины там использовались для подводки напряжения смещения. Но вот через пару лет, как раз к выходу ХТ, они перешли на новые чипы, работающие только от +5В, и добавили ещё две линии адреса, и тогда уже поздние IBM PC стали поддерживать столько же памяти, сколько и PC XT, 256К.

Я сам тогда пользовался Искрой 1030 с 512Кб памяти.

Я только про оригинальные IBMовские компьютеры начала 1980-х пишу. Все те бесчисленные клоны, аналоги или просто сделанные "по мотивам", которые выходили во второй половине 1980-х, и в СССР, и за границей, от них уже несколько отличались, хотя как раз тогда и более-менее сформировался канон "640К"

Ну а 286 имел ограничение памяти до 16 мб, хотя найти такую конфигурацию тогда было нереально. В основном 2-4 метра они имели.

Канон 640К образовался исходя из кол-ва адресных линий в 8086\8088.
Их всего 20, что позволяет в принципе адресовать 1МБ памяти. Но кроме набортной рамы, нужна еще пямять для отображения на девайсы, вот и выбрали для физической памяти верхнюю границу в 640К, сразу, на первом писюке (5150), а не когда-то потом.

Обратите внимание, что кроме 286-AT (5170) существует еще 286-XT (5162) и там, не смотря на то что у проца 24 адресных линии, адресовать можно все равно только мегабайт, причем физ памяти не более пресловутых 640К. EMS карточки на мегабайты не в счет, они через окно в первом мегабайте работают, переключая свои банки.

AT (5170) как раз решил эту проблему, добавив рабочие 4 линии, т.н "gate A20" и спецификации на Extended память (XMS, все что выше мега)

Это ограничение появилось только в компьютере IBM PC AT в 1984-м году, потому что после 640К там начиналась область видеопамяти для EGA-адаптера

А кто мешает в XT хоть EGA, хоть VGA воткнуть? Ограничения в 640К вот не было, а после втыкания тогда появится? (развернуто ответил выше)

Туда помещались текстовые редакторы, файловые менеджеры, базы данных, бухгалтерские программы, игры, софт для FIDO (типа "электронная почта по модему"), BBS ("сайты"), в общем всё что работало на MS DOS.

Прямо вот так все вместе и помещались? И прямо вот так параллельно работали?

По очереди, разумеется.

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

А сейчас эта вкладка браузера 200М отъедает. И что из того?

Плохо. Рукожопие процветает.

на сайтах, у которых странички по 50 килобайт никто не сидит.

Часть софта и вместе помещалась тоже — попытки сделать какую-никакую многозадачность были в ДОСе, кроме того, очень распространены были TSR-программы, которые «висели» в памяти и активировались на события, тот же русификатор клавиатуры.

qemm386

Расскажите о таблицах данных того времени, этакий прародитель эксель или сложнее? Могу конечно по гуглить но я помню был эксель с дизайном 80x25 из аски символов как far/norton

SuperCalc - текстовый дедушка Excel'а.

Скрытый текст

FoxBase - предок FoxPro. Вполне приличная система управления файловыми БД. Шустро летала на тех 640 килобайтах, обсчитывала зарплату для тысяч сотрудников.

Скрытый текст

Ну и де-факто стандарт тех десятилетий, сам FoxPro. Вершина своей эволюционной ветки, умел в SQL на своих файловых базах с очень неплохой оптимизацией. Когда через годы Borland решила догнать его на этом фронте, и выкатила свое BDE (Borland Database Engine), то разница в быстродействии и надежности была столь разительна в пользу старого доброго FoxPro, что эта неудача сыграла важнейшую роль в закате Borland.

Скрытый текст

Для более серьёзных задач в качестве БД использовали Btrieve. Для разработки в локальном, а в продуктиве - с сервером на Novell Netware

Clipper еще был, СУБД + язык программирования + текстовый интерфейс.

Вы, наверное, будете смеяться, но на тех компьютерах работал не только некий прародитель Excel, но и сам Excel. И ещё и под виндой:

Тут следует упомянуть, что самые первые IBM PC могли поставляться вообще с 16KB памяти, и на 1981-й это ещё стоило примерно 100. Так что 640KB было какой-то несбыточной цифрой на те времена (4100, на персональный компьютер - нереально). А на потом думали вообще сменить архитектуру. Проблема в том, что, условно, MS-DOS задержался на десять лет по сравнению с тем, что ожидали (в заметной мере, в своих наполеоновских планах) авторы железа, программ, журналисты и прочие, и, несмотря на то, что адресация далее 1MB была уже в 80286, массовое переписывание кода на новый стиль стало быть позволено уже только в середине 1990-х. Вот об этом бы почитать подробнее, каким образом и почему индустрия впала в такой заклин.

Там было "примерно 100 долларов. Так что 640kB было какой-то несбыточной цифрой на те времена (4100 долларов..."

Кажется, форматтер символы доллара понял как ограничители формулы.

Под MS DOS понаписали много софта, и переписывать его под новый процессор без крайней необходимости - кому это было надо?

Это же не OpenSource, где можно взять исходники и новый компилятор, и попробовать собрать.

Смысл что-то менять появился тогда, когда вышла Windows, с "встроенной графикой", причем достаточно распространилась, чтобы пользователи начали задумываться: оставить привычную надежную DOS-программу XXXXX (работающую в окне Windows, в режиме виртуального x86), или купить новую версию чисто под Windows?

DOS-extenders, если вы под адресацией имеете ввиду именно защищенный режим появились вместе с 286 в 80х, где было удобно или нужно, там и использовали, откуда середина 90х и какой-то заклин, мне, например, непонятно.

Так-то память выше мегабайта можно было и в реальном режиме использовать, за xms память не помню, а ems точно работала через окно в первом мегабайте, так что кому память не нужна была вся разом, этим и удовлетворялись.

Ещё напомню, что 286 компы были не только в виде AT, но и XT

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

А это не был "заклин". DOS долгое время имела преимущество в массе сфер. Для бизнесовой - под ней было написано куча кастомного бухгалтерского и учётного софта. Для промышленной - в ней был реалтайм, которого не было в винде. Для игровой - в ней был прямой доступ к видеоустройствам, с максимальной производительностью, недоступной в винде до появления DirectX. А ограничений памяти в DOS, в общем-то, не было, ибо появились всякого рода DPMI-extenders.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации