Вы ведь тоже вашу 32-битную поделку под MS-DOS пользовали, а не под перепроектированнаой и вычищанной Windows NT… а почему, собственно?
Потому что в 1995 году никаких Windows у нас еще не было, а компьютеры уже были 32-х разрядными. Зато потом легче было переходить, уже имея 32-х разрядные программы, хоть и под ДОС.
Как раз Himem.sys это и не нужно было делать. Он как раз включал A20.
Вообще с 1995 года мы работали в 32-х разрядном режиме и программа и данные размещались выше первого Мбайта, а Himem.sys использовали только как учетчика занятой памяти. Никакие расширители ДОС при этом не требовались.
Боже упаси. Позарез нужна была программа, которая нормально не работала, как выяснилось потом, из-за А20. Если бы программа работала нормально, и в голову не пришло бы разбираться с ДОС. К тому же, была уверенность, что виновата именно ОС.
А сделать флаг в exe-заголовке «Не выключать А20», видимо, религия не позволяла.
Могу только повторить, что:
Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.
Честно говоря, в тот момент все ходили и скрежетали зубами по поводу потерянных двух недель. Никто и не собирался дальше ковыряться в ДОС'е, а, тем более, создавать свою ОС.
Более всего возмущал сам факт выключения 20-той линии, при том, что до сих пор я не слышал ни об одной программе, которой нужно ее отключать.
Да вполне себе рабочая ОС. Ядро написано высококвалифицированными специалистами. Ошибок не находил, но помарки в ядре XP находил. Может быть и выложу когда-нибудь заметку об этом на Хабре. И потом, это же не просто задачка, это проверка какие ресурсы Вы реально можете использовать на конкретном компьютере.
Да, конечно. Обычно в момент, когда программа задышала, но еще не окончательно готова, я глобально меняю короткие имена на более развернутые, но здесь поленился.
Файлы один раз целиком читаются в память и затем вся работа идет в памяти. Примерно 20 Гбайт для «среднего» масштаба. Тогда скорости для прокрутки хватает. А то, что построчное (самое примитивное) сжатие — так ведь все равно каждый пиксель на экране считается и достается отдельно. Рисуется ведь не «плоская» карта, а перспектива. то есть точки «плоской» карты отображаются в модели иллюминатора не подряд.
Вы имеете ввиду формат JPEG 256х256 как в maps.google.com? К сожалению, моделировать необходимо не только вид в надир. В примере виден горизонт. Представляете, сколько клеток 256х256 нужно загрузить до горизонта? Да и с предсказуемостью следующих клеток не всегда хорошо — модель должна крутиться (т.е. показывать вид при разной ориентации). И «листать» пользователь может куда угодно, задавая будущее или уже прошедшее время при моделировании.
Спасибо за объяснение текущего состояния. Поскольку эти проблемы решались еще когда не то, что большинства программистов на свете не было, а их родителей еще не было, то, разумеется, задачи были как-то решены. А в PL/1 все тупо перенесли из Кобола и дело с концом.
Сейчас программиста, не сталкивающегося с финансово-экономическими расчетами, легко узнать по предложению хранить все в целых копейках. Им кажется, что деньги только складывают и умножают ))
Дело в том, что в языках, имеющих дело с финансово-экономическими расчетами (вроде PL/1), т.е. там, где требуются точные расчеты, числа делятся не на целые и действительные, а на точные и приближенные.
Если в языке нет точных чисел никакие масштабные коэффициенты или предложение хранить деньги в виде целого числа копеек не помогут.
В том же PL/1 точка является признаком только дробной части, а вот показатель степени «E» — уже признаком приближенного числа.
Поэтому в PL/1 0.1Е0+0.2Е0 не равно точно 0.3Е0 как и в других языках (как и в примере).
А вот 0.1+0.2 точно равны 0.3 поскольку это точные числа, представленные в двоично-десятичном виде.
Потому что в 1995 году никаких Windows у нас еще не было, а компьютеры уже были 32-х разрядными. Зато потом легче было переходить, уже имея 32-х разрядные программы, хоть и под ДОС.
Вообще с 1995 года мы работали в 32-х разрядном режиме и программа и данные размещались выше первого Мбайта, а Himem.sys использовали только как учетчика занятой памяти. Никакие расширители ДОС при этом не требовались.
Могу только повторить, что:
Главной же бедой любой обратной совместимости является то, что с каждым годом пользователей, которым она нужна, все меньше и меньше. А учитывать ее приходится всем.
Более всего возмущал сам факт выключения 20-той линии, при том, что до сих пор я не слышал ни об одной программе, которой нужно ее отключать.
Сейчас программиста, не сталкивающегося с финансово-экономическими расчетами, легко узнать по предложению хранить все в целых копейках. Им кажется, что деньги только складывают и умножают ))
При сравнении «физические» типы оказались несравнимы
Если в языке нет точных чисел никакие масштабные коэффициенты или предложение хранить деньги в виде целого числа копеек не помогут.
В том же PL/1 точка является признаком только дробной части, а вот показатель степени «E» — уже признаком приближенного числа.
Поэтому в PL/1 0.1Е0+0.2Е0 не равно точно 0.3Е0 как и в других языках (как и в примере).
А вот 0.1+0.2 точно равны 0.3 поскольку это точные числа, представленные в двоично-десятичном виде.