Не, наверное есть ещё способ добиться сверхмалого размера EXE с помощью Sphinx C-- (Michael Sheker), но это будет не Си, а Си-минус-минус, к которому переходить от готового кода на Си смысла мало, лучше писать сразу на минусах.
Приложенный в архиве файл MoveWindow.exe занимает, как видите, 3 кб. Что он умеет делать — смотрите в исходнике MoveWindow.Mod и сопоставляйте со своими нуждами. Как по мне — добиться меньшего размера EXE, чем с помощью метода Макса Феоктистова, просто невозможно. Если знаете как — напишите, интересно.
Я бы планировал обязательное уменьшение вашего EXE-шника при переходе от MINGW к DJGPP килобайта на 4 (минимум) до 10-16 (максимум). В пожатом UPX виде разница конечно будет не столь значительная.
Также на простую пересборку вашего кода DJGPP я бы не расчитывал. Скорее всего придётся допиливать и биндинги к API, и код.
В методе Макса Феоктистова DJGPP занимает ключевую роль. Я использую его для получения сверхмалого размера EXE, но сам Макс писал мне что разработал свой линкер исключительно для производства виндовых приложений в то время когда GCC ещё не умел их генерировать (а MINGW ещё не было), и сегодня Макс советует использовать вместо DJGPP и его линкера CygWin или MINGW. Я ещё использую tcc (Tiny C), который умеет генерировать 32- и 64-битный код для Windows и Linux: для небольших приложений код получается достаточно компактным, но конечно не настолько, как по методу Макса. Для бОльших приложений MINGW выигрывает и по размеру кода, и по быстродействию.
DJGPP является программой для DOS, поэтому и не работает под x64. Если хотите, можно попробовать написать батник, который будет вызывать его с помощью DOSBox. У меня в XDev/DosDev подобным образом вызывается Turbo C:
Или же используйте виртуальную 32-битную Windows внутри 64-битной.
Вам могут понадобиться заголовочные файлы DJGPP для WinAPI. Можно взять из MINGW (правда, их придётся модифицировать, всё-таки DJGPP 2.95 это старая версия GCC). Или воспользуйтесь этим:
На будущее, для подобных проектов: есть метод для получения сверхкомпактных .exe (от 1 кб) для Windows, предложенный Максом Феоктистовым (автором Small HTTP Server) на основе компилятора DJGPP, заточенного для генерации .exe, и собственного PE-линкера для Windows. Всё это опубликовано у него на сайте.
Мне удалось прикрутить генерацию .exe данным способом к мультитаргетной среде разработки XDev. Вот пример сверхкомпактной оконной программы с исходниками на языке Оберон-2 (для 32 и 64 бит соответственно):
Раз предпочитаете Дельфи, а не Си, то, возможно, стоит попробовать для разработки компактных игр паскалеподобный Оберон. Если решитесь осваивать — потребует времени на примеривание, разработку биндингов. Но потраченные усилия обязательно окупятся — ведь на XDev можно делать программы не только для Win32/64, но и для Linux, Java microedition и ретро-платформ — DOS, MSX, ZX Spectrum. Если интересно, приходите на форум, будем общаться. :)
Сейчас портирую на Оберон некоторые игры с ZX Spectrum и DOS, например:
Кто-то игры делает, кто-то портирует. Смысл моей работы по портированию — прояснить алгоритмы, вывести их из малопонятного сильно заточенного под платформу или среду разработки вида в сторону мультиплатформенности. Конечный размер игр (их версий для Спектрума) не может превышать 42 кб даже без упаковки — этот лимит продиктован адресным пространством Спектрума (16 кб занято ПЗУ + 6 кб экранная память; страницами 128 кб-моделей я не пользуюсь). Для Windows (методом Феоктистова) — размер ненамного больше (а с UPX — значительно меньше), просто я сейчас использую для вывода графики библиотеку SDL, а разработка графического движка на WinAPI — только в проекте. uFMOD — отличная библиотека, спасибо за наводку! :)
Ключевой момент: «Готов ли Оберон к 64 битам»? Здесь одним «да» или «нет» не обойдёшься, и тут, вероятно, тёрки потому, что Веселовский вкладывает в понятие «Оберон», скорее, Оберон-07 и Активный Оберон, я же вкладываю в это понятие, скорее, Оберон-2 и Компонентный Паскаль, т.к. считаю эти диалекты более пригодными для промышленного использования. А Оберон-07 слишком мал, чтобы комфортно его использовать в повседневных задачах. Даже КП — чрезвычайно маленький язык. И его, на мой взгляд, надо только дополнять. А уж что говорить про О-07, самая свежая редакция которого, к тому же, не выглядит полностью законченной. И Веселовский, видимо, прочитав описание последней редакции, до сих пор не может прийти в себя. Да и вообще вкладывать в понятие «Оберон» самую урезанную ревизию, косвенно предполагая ту же фигню и в других диалектах. Вот чем грешит Веселовский, он передёргивает факты и трактует их в меру своего скромного разумения.
Что вообще можно вложить в понятие «64-битность» в контексте Оберона?
Разумность и целесообразность широкого использования 32-битной арифметики на 64-битных архитектурах, если её разрядности хватает для задачи? Сама возможность работы на 64-битном процессоре 32-битной Оберон-программы, которая не знает о 64-х битах и думает, что их по-прежнему 32? Ну да, в принципе, Оберон-программа может быть номинально 64-битной, но арифметика в ней будет 32-битной. Или 64-битной. Или той и другой вместе (INTEGER и LONGINT). Указатели 64-битными. При этом в Обероне-07 целочисленная арифметика может быть только одной разрядности, потому что там предусмотрен только один целочисленный тип INTEGER.
Наличие типа INTEGER строго размером в 64 бита? Понимать ли под 64-битностью именно то, чтобы тип INTEGER был 64 бита, потому что Веселовский упёрся в это? Если так, то в Дельфи XE4 тип INTEGER остался 32-битным, и горе тем, кто кастовал указатели в INTEGER; а значит Дельфи XE4 тоже не готов к 64 битам. И Java не готова, потому что по стандарту int 32-битный, а для 64 бит надо юзать long.
Вообще возможность работы Оберон-программ на 64-битных процессорах?
Возможность использования как 32-битной арифметики, так и 64-битной?
Разные диалекты Оберона предлагают разные ответы на эти вопросы.
Готова ли последняя виртовская редакция Оберона-07 к 64 битам?
Не будет ли ещё более новых редакций? Кто его знает. Авторы компилеров Оберона-07, готовьтесь к приятному внесению изменений.
Поэтому важный момент: INTEGER в 64-битной реализации Оберона-07 может быть 32-битным. Стоит ли в 64-битном Обероне-07 делать тип INTEGER разрядностью 64 бита или оставить 32, как в Дельфи XE4? Если делать, то будут одни плюсы. Если не делать — другие.
Можно сделать INTEGER 64-битным, вот в Питоне вся целочисленная арифметика 64-битная, и ничего. Но тогда нельзя будет низкоуровневыми средствами кастовать INTEGER в SET, чего конечно Веселовскому не нравится, и он зашёл с этим в тупик. Ибо с одной стороны надо и редакцию соблюсти, от буковки редакции — ни на шаг! С другой наверно это всё дело как-то задумывалось как практический инструмент. На том, что этот тупик пробит в других диалектах Оберона, Веселовский особо не акцентирует. Я же говорю: минимальность Оберона-07, святое соблюдение буквы его последней ревизии, которая, возможно, не окончательная, желание при этом решать на нём какие-то задачи и полный игнор тех фактов, что в других диалектах Оберона эта проблема решена (да-да, и не только в Active Oberon) — это плохой винегрет, которому мы дадим рабочее название «сумбур в голове Веселовского».
Как в рамках зафиксированной редакции Оберона-07, не меняя её, всё-таки его развивать? Или всё-таки поправить явные ляпы в этой редакции самим или ждать, когда это сделает дядька Вирт? Я открою вам секрет: в связи с тем, что Бертран Мейер сейчас заведует в ETH (альма-матер Оберонов) кафедрой, на которой разрабатывается Active Oberon, и любит он не Оберон, а вовсе даже Эйфель, то по дальнейшему развитию Оберонов силами ETH нанесён значительный удар. Если этим не займётся кто-то ещё. OberonCore? Да, возможно. Оберспейс на «продолжателя традиций», извините, не тянет.
Готовы ли Оберон и Оберон-2 к 64 битам?
Абсолютно готовы. В стандарте этих языков нет явной привязки к разрядности. Что всё-таки не мешает делать на них переносимые программы сегодня, не дожидаясь годков 20 новой редакции «Дубовых требований», в которой модуль:
MODULE MustBeStandard; TYPE Int64* = LONGINT; END MustBeStandard.
будет стандартным. Но если то, что такой модуль не стандартизирован — это религия, то никогда уже г-н Веселовский не сможет попрограммить на Обероне-2 под 64 бита.
Готов ли Компонентный Паскаль к 64 битам?
Абсолютно готов. Есть ли смысл делать INTEGER 64-битным, а LONGINT — 128-битным — это отдельный вопрос. В принципе, числовые типы достигли своего насыщения, и, наверное, всё-таки в новой версии Питона целочисленна арифметика не будет 128-битной, а ещё в следующей — 256-битной. Это в моём понимании тупиковый путь. Есть ниша для длинной арифметики, а много где хватает и 32-битных вычислений.
Буду признателен Веселовскому, если он ткнёт носом в такое место стандарта языка КП, где декларируется «жесткая привязка примитивных типов к разрядности», потому что ничего такого я не встречал. Или Веселовского смущает то, что эти типы всё-таки имеют при реализации какую-то разрядность?
Сентенция «а SET напрямую связан с INTEGER», может быть, и имеет смысл в Обероне-07, где всё-таки приходится, ну просто ввиду отсутствия других средств, использовать прямое кастование между этими типами системными средствами, однако в языке КП это уже исправлено: там есть битовые операции BITS и ORD. А в реализации GPCP есть типы SET и LONGSET (по аналогии с INTEGER и LONGINT).
Готов ли Активный Оберон к 64 битам?
Готов, как и остальные Обероны. Вот эту туманную цитату: «Там наконец ввели тип ADDRESS, ну и многие другие неприятные мелочи устранили.» я бы попросил г-на Веселовского прояснить, пусть расскажет нам о других неприятных мелочах. Мелочи — не конёк Веселовского, он обожает обобщать всё до «джедайских сверхсредств, которых вы всё равно не поймёте, простые сельские парни», поэтому ждите потехи.
Говорить о «закукливании» и «замыкании на себя» форума OberonCore — это слишком субъективно, хотя чего же вы надеялись тут услышать от valexey, который является папочкой-основателем форума-«продолжателя». :) Да и говорить, что на Core «все знают и умеют ТОЛЬКО Оберон» — это тоже профанация (попробуй найди хотя бы полтора программиста, который не знает ничего другого?). Да, на Core есть некоторые проблемы с неприятием явных троллей, были и несогласия одних умных людей с другими, и даже очень серьёзные. Но всё-таки поводом существования OberonCore являются сами Обероны. Я предлагаю составить личное мнение по каждому из форумов, но моё таково — что при всех недостатках Core у него есть и достоинства, ему присущ академический флёр. Чистота, хорошая структуризация материала, есть много интересных людей, использующих Оберон в своей деятельности.
Ну а альфа и омега Оберспейса, сама сердцевина его существования — это жажда самовосхвалений основной банды участников, к Оберонам имеющих не то что косвенное отношение, а вообще никакого. Именно поэтому там со скоростью диареи появляются пачками личные разборки, наезды и темы типа "Мы победили!". Если убрать оттуда Ермакова, Губанова, akron1 и ещё пару человек, которые чего-то делают, останется голая болтовня в стиле «я самый умный». Но присутствие этих самых челов даёт им всем право говорить «Мы делаем». А декларируемая «папочкой» форума «свобода» в купе с общим пофигизмом и мусорной подачей информации напоминает тусовку хиппи. Добавьте сюда невозможность редактирования постов, что само по себе плохо для работы (материал закостеневает), хотя наверное хорошо для холиваров.
Так что я бы поостерёгся назвать Оберспейс таким уж идейным продолжателем движения «За Оберон». И valexey не понял, что я не ставил целью расписать все ресурсы по Оберонам в статье, на это есть гугле, и неплохо справляется, а просто рассказал о своей деятельности и своём виденьи Оберонов.
Вы спросите, как борятся с троллингом на VEDAsoft форуме? А пока никак, он просто недостаточно велик для этого явления. Будут проблемы — будем думать. Наверное спорные моменты будут решаться кем-то вроде совета старейшин — тех людей, которые приняли активное положительное участие в работе форума. И сейчас это — форум практиков Оберона, которые пытаются его применять с пользой.
Вобщем, резюме:
OberonCore — «академия» Оберона. Со своей внутренней политикой (а где её нет?)
Oberspace — «курилка» при отделе, имеющем какое-то отношение к Оберону, на двери надпись «Оберон», но внешнее впечатление обманчиво; часто заходят «поболтать» из соседних отделов (ну надо же где-нить расслабиться и перекурить?). Внимание: поскольку здесь курят не только табак, то можно зайти с лучшими побуждениями и получить ни за что ни про что по морде.
VEDAsoft — «клуб по интересам» для Оберон-практиков
Всё же хорошо, что они есть — есть выбор куда пойти (и, надеюсь, всем понятно почему «академиков» и практиков меньше, чем курильщиков?)
Кстати, помимо «основных», есть и другие форумы и форумные темы по Оберону, не такие большие, но тоже интересные. Например, форум по Активному Оберону и ОС A2.
А этот вот товарищ, автор данной статьи, увидел идею публикации и быстренько накатал вот это, сильно смахивающее на рекламную брошюру обильно сдобренную ссылками на свой собственный форум, видимо в рассчете на приток новых участников на оный.
Ну Бог его знает, наверное и ваши потуги многим будет интересно увидеть, как взгляд на Обероны с другой колокольни. Но как же моя статья помешает вашим трудам? Я не более чем рассказал здешнему народу о своей Оберон-деятельности, своём взгляде на Обероны и своём опыте, которые, естественно, подкреплены ссылками (нимало не ожидая, что все сразу ломанутся программировать на Обероне), а вы, видимо, намерены сделать компиляцию из готовых цитат из источников по Оберону. Что ж, флаг в руки.
Да там уже сейчас чёрт ногу сломит. Скоро оно рухнет как любая свалка мусора.
P.S. А ещё обещал в шапке структурировать инфу. «И в точности также из негo постепенно будут выделяться обособленные темы в отдельные форумы». Это я, что ли, писал?
И у нас на форуме на свободу слова ещё никто не жаловался. Ты первый. Хоть там и не зареген.
О, г-н Веселовский, видимо, желает раскрыть тему о том гадюшнике, который творится у него на его личном блоге субъективных оберононенавистников под названием Oberspace?
Это разумеется, статья на Хабре не планировалась. Так получилось.
Да смотрел я на Лиспы и на Питоны с Руби. Форт ещё есть, тоже интересный язык. Но положительное отличие от них Оберона в том, что программу на Обероне поймёт любой грамотный инженер, а на скобочных языках надо каждую скобку штудировать с талмудом в руках. И обучать свою племянницу Лиспу я не стал бы.
Я увлекаюсь языками программирования. Если полагаете, что вру и на самом деле не слышал о Лиспе, то вот вам исходник «цветочка», который я когда-то делал на Лиспе. Ещё пытался на нём сделать карточную игру, но, правда, не очень продвинулся. Зато смог насладиться исходниками игры Abuse. Так что представление о Лиспе есть, и, пожалуй, не будем сравнивать вот так вот в лоб императивную и функциональную классику.
born2fly> А есть ли в природе 64х битный компилятор Оберона под Windows?
Для x86-64 — пока нет. Но, уверен, что появится в ближайшее время.
Остаётся возможность разрабатывать на Обероне для этой архитектуры через трансляцию в Си.
Видимо, нужно готовить новую статью про качественные отличия в семантике Оберонов по сравнению с Delphi и Modula-2. Ага, я ещё ни слова не сказал про моментальную отладку (она в некоторых источниках называется посмертной, но мне больше нравится термин «моментальная», т.к. передаёт суть и лишён некоего налёта некрофилии) и различные полезные фишки Оберонов, как-то: динамическую охрану типов, динамическую модульность, средства для безопасного программирования. Будьте уверены, если бы достоинств у Оберона перед Паскалем и Модулой не было — я бы его точно не юзал. Но на статью нужно время, так что я просто буду иметь это ввиду, отсылая пока что интересующихся к другим источникам. Например, вот моя подборочка документов для быстрого вруливания в Оберон-технологии. Там есть ответы и акценты на полезных отличиях Оберона.
P.S. Мы с вами на Хабре делаем посты и вставляем линки в виде A HREF не потому, что это идеальный способ поделиться ссылкой. Просто это традиционно для веб-технологий и для многих (особенно веб-мастеров) это привычнее, чем что-либо другое. И некоторые люди не поменяют этот способ вставки ссылок ни на более простой и удобный, ни на даже другой, потому что он другой. А я бы предпочёл специализированный редактор, и поверьте, он был бы уж точно не похож на браузер. Это касается и критики Оберона — ведь она часто исходит от личного опыта программиста, который не прощает Оберону уже капс лок, дальше просто не вникает. Я вник, но не жалею.
Какие преимущества, говорите. :) И то, что не надо тратить десять лет жизни на освоение C++ и UNIX-way. И то, что мы в школе учились программировать на неструктурном Бейсике, а могли бы — на модульном Обероне. Но самое важное то, что Оберон ближе к корням (Задумывались, почему Windows 8 не написана на C#?). Он не проповедует свою личную очень авторитетную корпорацию, платформу, архитектуру и виртуальную машину. А напротив — легко ложится даже на те аппаратные ниши, которые разрабатывали ни сном ни духом не ведая про Обероны. Ну попробуйте поработать на C# и Дельфи для Z80. Не то? Ушло в молоко. А на Обероне можно, что я и постарался показать в посте. А, вам не нужен Z80. Да и ради бога, юзайте себе ARM или x86-64. Ага, ещё нишка для Оберонов — микроконтроллеры и прочие Raspberry с Arduino. Через 10 лет будут новые платформы. Туда конечно может быть и лягут .NET и JVM (традиция), но Оберон уж ляжет точно, так что наработки не пропадут. И я советую не использовать существующие Оберон-средства для промышленных проектов быстрой разработки, нуждающихся в плотной интеграции с другими средствами. Они пока не готовы для этого. Но вот чтобы стали готовы — нужны энтузиасты. И ведь что такое Хабр, если не Эльдорадо энтузиастов. Да, было бы здорово если бы каждый воспринял посыл «не готовы» не затем, чтобы критиковать: «тут-то этого НЕТУ!», а реализовал те средства, которых ему не хватает в Оберонах.
А ведь не секрет, что многие языки являются не только техническими средствами, но и средствами конкуретной борьбы «за умы» и выживания друг друга с рынка. Ведущие разработчики современных средств сходятся в том, что технические качества на популярность того или иного средства влияют весьма косвенно. Если хотите знать моё мнение, вокруг любого языка программирования часто воздвигнуто много мифов. Например, что C# — самый безопасный, а Java — самая переносимая. Считаю, вокруг Оберона тоже нужны положительные мифы, и таки да: цель статьи — пиар, но на самом деле пиарить Обероны надо без противостояния другим технологиям, что я и постарался сделать своим постом. Рад, что он вызвал такое бурное обсуждение, что уже даже теряюсь на какой коммент ответить. Спасибо всем!
Как хорошо сказал Руслан Богатырёв на тему синтаксиса: это традиция модульных языков. Выделяется скелет программы, её костяк. Можно делать смысловые пометки выделением цвета или стиля. И примерно туда же двигается программинг. От плоского представления текстов программ на языках (в текстовом формате) — к манипуляции набором принятых решений в визуальных редакторах. И помяните моё слово, когда в новой версии вашей любимой среды разработки появится что-то подобное, только основанное на XML. Как только «великие» придумают как совместить это дело с раскраской синтаксиса. Предпосылки для этого есть уже сейчас (например, javadoc и прочие средства для Code Review). Значит не хватает уже текстового представления? Да, я знаю как глубоко мы в него увязли, но это является и тормозом прогресса же. Можно не юзать diff, можно пользоваться для сравнения исходников встроенными средствами BlackBox. Можно адаптировать системы контроля версий для бинарных исходников. Тут нет проблем. Но почему-то вместо этого (пока) предпочитают навешивать мета-информацию поверх текста либо с помощью тегов, либо отдельным файлом проекта, записанным в своём формате.
Так что бинарные исходники — это исследовательское направление, которое может быть многообещающим, если абстрагироваться от преимуществ готового набора инструментария для работы с текстами (grep и прочее) и начать осваивать новые просторы, находя в них новые достоинства, которых на самом деле много. Например, можно иметь несколько вариантов исходного текста, переключаемые селекторами. Можно вставлять в исходник в качестве комментариев поясняющие картинки, которые очень часто информативнее текста.
Впрочем, в XDev есть поддержка и чисто текстового формата исходников (недавно введена) с привычной для всех раскраской синтаксиса.
www.sheker.chat.ru/
Можно составить мнение о языке Си-минус-минус по статье «Sphinx C-- — язык не для всех»:
www.sheker.chat.ru/c--part1.rar
www.sheker.chat.ru/c--part2.rar
Проект давно не развивается.
zx.oberon2.ru/forum/viewtopic.php?f=32&t=189&p=1385#p1180
Приложенный в архиве файл MoveWindow.exe занимает, как видите, 3 кб. Что он умеет делать — смотрите в исходнике MoveWindow.Mod и сопоставляйте со своими нуждами. Как по мне — добиться меньшего размера EXE, чем с помощью метода Макса Феоктистова, просто невозможно. Если знаете как — напишите, интересно.
Я бы планировал обязательное уменьшение вашего EXE-шника при переходе от MINGW к DJGPP килобайта на 4 (минимум) до 10-16 (максимум). В пожатом UPX виде разница конечно будет не столь значительная.
Также на простую пересборку вашего кода DJGPP я бы не расчитывал. Скорее всего придётся допиливать и биндинги к API, и код.
Так что думайте, стоит ли овчинка выделки.
DJGPP является программой для DOS, поэтому и не работает под x64. Если хотите, можно попробовать написать батник, который будет вызывать его с помощью DOSBox. У меня в XDev/DosDev подобным образом вызывается Turbo C:
github.com/Oleg-N-Cher/XDev/blob/master/DosDev/Bin/compile.bat
github.com/Oleg-N-Cher/XDev/blob/master/DosDev/Bin/build.bat
Или же используйте виртуальную 32-битную Windows внутри 64-битной.
Вам могут понадобиться заголовочные файлы DJGPP для WinAPI. Можно взять из MINGW (правда, их придётся модифицировать, всё-таки DJGPP 2.95 это старая версия GCC). Или воспользуйтесь этим:
github.com/Oleg-N-Cher/XDev/blob/master/WinDev/Lib/C/WinApi.h
(безошибочность не гарантируется, я делал этот биндинг сам)
На будущее, для подобных проектов: есть метод для получения сверхкомпактных .exe (от 1 кб) для Windows, предложенный Максом Феоктистовым (автором Small HTTP Server) на основе компилятора DJGPP, заточенного для генерации .exe, и собственного PE-линкера для Windows. Всё это опубликовано у него на сайте.
smallsrv.com/mkpe/ (если не откроется, есть в кэше гугле)
Мне удалось прикрутить генерацию .exe данным способом к мультитаргетной среде разработки XDev. Вот пример сверхкомпактной оконной программы с исходниками на языке Оберон-2 (для 32 и 64 бит соответственно):
zx.oberon2.ru/forum/viewtopic.php?f=32&t=189#p1180
Раз предпочитаете Дельфи, а не Си, то, возможно, стоит попробовать для разработки компактных игр паскалеподобный Оберон. Если решитесь осваивать — потребует времени на примеривание, разработку биндингов. Но потраченные усилия обязательно окупятся — ведь на XDev можно делать программы не только для Win32/64, но и для Linux, Java microedition и ретро-платформ — DOS, MSX, ZX Spectrum. Если интересно, приходите на форум, будем общаться. :)
Сейчас портирую на Оберон некоторые игры с ZX Spectrum и DOS, например:
Bolder Dash (Владимир Мутель, Turbo C 2.0, DOS): zx.oberon2.ru/dash.htm
Дурак (Вячеслав Медноногов, Laser Basic, ZX Spectrum): zx.oberon2.ru/durak.htm
Dark Woods (Jocke The Beast, Quick Basic 4.5, DOS, no sources (реверс инжиниринг)): zx.oberon2.ru/forum/viewforum.php?f=26
Кто-то игры делает, кто-то портирует. Смысл моей работы по портированию — прояснить алгоритмы, вывести их из малопонятного сильно заточенного под платформу или среду разработки вида в сторону мультиплатформенности. Конечный размер игр (их версий для Спектрума) не может превышать 42 кб даже без упаковки — этот лимит продиктован адресным пространством Спектрума (16 кб занято ПЗУ + 6 кб экранная память; страницами 128 кб-моделей я не пользуюсь). Для Windows (методом Феоктистова) — размер ненамного больше (а с UPX — значительно меньше), просто я сейчас использую для вывода графики библиотеку SDL, а разработка графического движка на WinAPI — только в проекте. uFMOD — отличная библиотека, спасибо за наводку! :)
Ключевой момент: «Готов ли Оберон к 64 битам»? Здесь одним «да» или «нет» не обойдёшься, и тут, вероятно, тёрки потому, что Веселовский вкладывает в понятие «Оберон», скорее, Оберон-07 и Активный Оберон, я же вкладываю в это понятие, скорее, Оберон-2 и Компонентный Паскаль, т.к. считаю эти диалекты более пригодными для промышленного использования. А Оберон-07 слишком мал, чтобы комфортно его использовать в повседневных задачах. Даже КП — чрезвычайно маленький язык. И его, на мой взгляд, надо только дополнять. А уж что говорить про О-07, самая свежая редакция которого, к тому же, не выглядит полностью законченной. И Веселовский, видимо, прочитав описание последней редакции, до сих пор не может прийти в себя. Да и вообще вкладывать в понятие «Оберон» самую урезанную ревизию, косвенно предполагая ту же фигню и в других диалектах. Вот чем грешит Веселовский, он передёргивает факты и трактует их в меру своего скромного разумения.
Что вообще можно вложить в понятие «64-битность» в контексте Оберона?
Разумность и целесообразность широкого использования 32-битной арифметики на 64-битных архитектурах, если её разрядности хватает для задачи? Сама возможность работы на 64-битном процессоре 32-битной Оберон-программы, которая не знает о 64-х битах и думает, что их по-прежнему 32? Ну да, в принципе, Оберон-программа может быть номинально 64-битной, но арифметика в ней будет 32-битной. Или 64-битной. Или той и другой вместе (INTEGER и LONGINT). Указатели 64-битными. При этом в Обероне-07 целочисленная арифметика может быть только одной разрядности, потому что там предусмотрен только один целочисленный тип INTEGER.
Наличие типа INTEGER строго размером в 64 бита? Понимать ли под 64-битностью именно то, чтобы тип INTEGER был 64 бита, потому что Веселовский упёрся в это? Если так, то в Дельфи XE4 тип INTEGER остался 32-битным, и горе тем, кто кастовал указатели в INTEGER; а значит Дельфи XE4 тоже не готов к 64 битам. И Java не готова, потому что по стандарту int 32-битный, а для 64 бит надо юзать long.
Вообще возможность работы Оберон-программ на 64-битных процессорах?
Возможность использования как 32-битной арифметики, так и 64-битной?
Разные диалекты Оберона предлагают разные ответы на эти вопросы.
Готова ли последняя виртовская редакция Оберона-07 к 64 битам?
Не будет ли ещё более новых редакций? Кто его знает. Авторы компилеров Оберона-07, готовьтесь к приятному внесению изменений.
Поэтому важный момент: INTEGER в 64-битной реализации Оберона-07 может быть 32-битным. Стоит ли в 64-битном Обероне-07 делать тип INTEGER разрядностью 64 бита или оставить 32, как в Дельфи XE4? Если делать, то будут одни плюсы. Если не делать — другие.
Можно сделать INTEGER 64-битным, вот в Питоне вся целочисленная арифметика 64-битная, и ничего. Но тогда нельзя будет низкоуровневыми средствами кастовать INTEGER в SET, чего конечно Веселовскому не нравится, и он зашёл с этим в тупик. Ибо с одной стороны надо и редакцию соблюсти, от буковки редакции — ни на шаг! С другой наверно это всё дело как-то задумывалось как практический инструмент. На том, что этот тупик пробит в других диалектах Оберона, Веселовский особо не акцентирует. Я же говорю: минимальность Оберона-07, святое соблюдение буквы его последней ревизии, которая, возможно, не окончательная, желание при этом решать на нём какие-то задачи и полный игнор тех фактов, что в других диалектах Оберона эта проблема решена (да-да, и не только в Active Oberon) — это плохой винегрет, которому мы дадим рабочее название «сумбур в голове Веселовского».
Как в рамках зафиксированной редакции Оберона-07, не меняя её, всё-таки его развивать? Или всё-таки поправить явные ляпы в этой редакции самим или ждать, когда это сделает дядька Вирт? Я открою вам секрет: в связи с тем, что Бертран Мейер сейчас заведует в ETH (альма-матер Оберонов) кафедрой, на которой разрабатывается Active Oberon, и любит он не Оберон, а вовсе даже Эйфель, то по дальнейшему развитию Оберонов силами ETH нанесён значительный удар. Если этим не займётся кто-то ещё. OberonCore? Да, возможно. Оберспейс на «продолжателя традиций», извините, не тянет.
Готовы ли Оберон и Оберон-2 к 64 битам?
Абсолютно готовы. В стандарте этих языков нет явной привязки к разрядности. Что всё-таки не мешает делать на них переносимые программы сегодня, не дожидаясь годков 20 новой редакции «Дубовых требований», в которой модуль:
MODULE MustBeStandard; TYPE Int64* = LONGINT; END MustBeStandard.
будет стандартным. Но если то, что такой модуль не стандартизирован — это религия, то никогда уже г-н Веселовский не сможет попрограммить на Обероне-2 под 64 бита.
Готов ли Компонентный Паскаль к 64 битам?
Абсолютно готов. Есть ли смысл делать INTEGER 64-битным, а LONGINT — 128-битным — это отдельный вопрос. В принципе, числовые типы достигли своего насыщения, и, наверное, всё-таки в новой версии Питона целочисленна арифметика не будет 128-битной, а ещё в следующей — 256-битной. Это в моём понимании тупиковый путь. Есть ниша для длинной арифметики, а много где хватает и 32-битных вычислений.
Буду признателен Веселовскому, если он ткнёт носом в такое место стандарта языка КП, где декларируется «жесткая привязка примитивных типов к разрядности», потому что ничего такого я не встречал. Или Веселовского смущает то, что эти типы всё-таки имеют при реализации какую-то разрядность?
Сентенция «а SET напрямую связан с INTEGER», может быть, и имеет смысл в Обероне-07, где всё-таки приходится, ну просто ввиду отсутствия других средств, использовать прямое кастование между этими типами системными средствами, однако в языке КП это уже исправлено: там есть битовые операции BITS и ORD. А в реализации GPCP есть типы SET и LONGSET (по аналогии с INTEGER и LONGINT).
Готов ли Активный Оберон к 64 битам?
Готов, как и остальные Обероны. Вот эту туманную цитату: «Там наконец ввели тип ADDRESS, ну и многие другие неприятные мелочи устранили.» я бы попросил г-на Веселовского прояснить, пусть расскажет нам о других неприятных мелочах. Мелочи — не конёк Веселовского, он обожает обобщать всё до «джедайских сверхсредств, которых вы всё равно не поймёте, простые сельские парни», поэтому ждите потехи.
Ну а альфа и омега Оберспейса, сама сердцевина его существования — это жажда самовосхвалений основной банды участников, к Оберонам имеющих не то что косвенное отношение, а вообще никакого. Именно поэтому там со скоростью диареи появляются пачками личные разборки, наезды и темы типа "Мы победили!". Если убрать оттуда Ермакова, Губанова, akron1 и ещё пару человек, которые чего-то делают, останется голая болтовня в стиле «я самый умный». Но присутствие этих самых челов даёт им всем право говорить «Мы делаем». А декларируемая «папочкой» форума «свобода» в купе с общим пофигизмом и мусорной подачей информации напоминает тусовку хиппи. Добавьте сюда невозможность редактирования постов, что само по себе плохо для работы (материал закостеневает), хотя наверное хорошо для холиваров.
Так что я бы поостерёгся назвать Оберспейс таким уж идейным продолжателем движения «За Оберон». И valexey не понял, что я не ставил целью расписать все ресурсы по Оберонам в статье, на это есть гугле, и неплохо справляется, а просто рассказал о своей деятельности и своём виденьи Оберонов.
Вы спросите, как борятся с троллингом на VEDAsoft форуме? А пока никак, он просто недостаточно велик для этого явления. Будут проблемы — будем думать. Наверное спорные моменты будут решаться кем-то вроде совета старейшин — тех людей, которые приняли активное положительное участие в работе форума. И сейчас это — форум практиков Оберона, которые пытаются его применять с пользой.
Вобщем, резюме:
OberonCore — «академия» Оберона. Со своей внутренней политикой (а где её нет?)
Oberspace — «курилка» при отделе, имеющем какое-то отношение к Оберону, на двери надпись «Оберон», но внешнее впечатление обманчиво; часто заходят «поболтать» из соседних отделов (ну надо же где-нить расслабиться и перекурить?). Внимание: поскольку здесь курят не только табак, то можно зайти с лучшими побуждениями и получить ни за что ни про что по морде.
VEDAsoft — «клуб по интересам» для Оберон-практиков
Всё же хорошо, что они есть — есть выбор куда пойти (и, надеюсь, всем понятно почему «академиков» и практиков меньше, чем курильщиков?)
Кстати, помимо «основных», есть и другие форумы и форумные темы по Оберону, не такие большие, но тоже интересные. Например, форум по Активному Оберону и ОС A2.
«Так себе» они заточены на x86-64, а на 64-х битах Оберон живёт уже давно. Просто ты не учёл, что мир 64 бит не ограничивается платформой Wintel.
И вообще в Оберонах явной привязки к разрядности особо нет, за исключением системных средств из псевдомодуля SYSTEM конечно.
Да-да, особенно ты без фанатизма.
Ну Бог его знает, наверное и ваши потуги многим будет интересно увидеть, как взгляд на Обероны с другой колокольни. Но как же моя статья помешает вашим трудам? Я не более чем рассказал здешнему народу о своей Оберон-деятельности, своём взгляде на Обероны и своём опыте, которые, естественно, подкреплены ссылками (нимало не ожидая, что все сразу ломанутся программировать на Обероне), а вы, видимо, намерены сделать компиляцию из готовых цитат из источников по Оберону. Что ж, флаг в руки.
P.S. А ещё обещал в шапке структурировать инфу. «И в точности также из негo постепенно будут выделяться обособленные темы в отдельные форумы». Это я, что ли, писал?
И у нас на форуме на свободу слова ещё никто не жаловался. Ты первый. Хоть там и не зареген.
Это разумеется, статья на Хабре не планировалась. Так получилось.
Я увлекаюсь языками программирования. Если полагаете, что вру и на самом деле не слышал о Лиспе, то вот вам исходник «цветочка», который я когда-то делал на Лиспе. Ещё пытался на нём сделать карточную игру, но, правда, не очень продвинулся. Зато смог насладиться исходниками игры Abuse. Так что представление о Лиспе есть, и, пожалуй, не будем сравнивать вот так вот в лоб императивную и функциональную классику.
Для x86-64 — пока нет. Но, уверен, что появится в ближайшее время.
Остаётся возможность разрабатывать на Обероне для этой архитектуры через трансляцию в Си.
Ну и вот ещё темка: Полезные свойства Оберон-технологий, их преимущества. Критика «мэйнстрим»-языков
P.S. Мы с вами на Хабре делаем посты и вставляем линки в виде A HREF не потому, что это идеальный способ поделиться ссылкой. Просто это традиционно для веб-технологий и для многих (особенно веб-мастеров) это привычнее, чем что-либо другое. И некоторые люди не поменяют этот способ вставки ссылок ни на более простой и удобный, ни на даже другой, потому что он другой. А я бы предпочёл специализированный редактор, и поверьте, он был бы уж точно не похож на браузер. Это касается и критики Оберона — ведь она часто исходит от личного опыта программиста, который не прощает Оберону уже капс лок, дальше просто не вникает. Я вник, но не жалею.
А ведь не секрет, что многие языки являются не только техническими средствами, но и средствами конкуретной борьбы «за умы» и выживания друг друга с рынка. Ведущие разработчики современных средств сходятся в том, что технические качества на популярность того или иного средства влияют весьма косвенно. Если хотите знать моё мнение, вокруг любого языка программирования часто воздвигнуто много мифов. Например, что C# — самый безопасный, а Java — самая переносимая. Считаю, вокруг Оберона тоже нужны положительные мифы, и таки да: цель статьи — пиар, но на самом деле пиарить Обероны надо без противостояния другим технологиям, что я и постарался сделать своим постом. Рад, что он вызвал такое бурное обсуждение, что уже даже теряюсь на какой коммент ответить. Спасибо всем!
Так что бинарные исходники — это исследовательское направление, которое может быть многообещающим, если абстрагироваться от преимуществ готового набора инструментария для работы с текстами (grep и прочее) и начать осваивать новые просторы, находя в них новые достоинства, которых на самом деле много. Например, можно иметь несколько вариантов исходного текста, переключаемые селекторами. Можно вставлять в исходник в качестве комментариев поясняющие картинки, которые очень часто информативнее текста.
Впрочем, в XDev есть поддержка и чисто текстового формата исходников (недавно введена) с привычной для всех раскраской синтаксиса.