Page 2 of 2

Re: ASM есмъ FASM

Posted: Tue Feb 09, 2010 1:35 pm
by Nasarus
Ладно если никто не решается, значить выход один: учить протектэд мод и писать самому :cry: ...

Re: ASM есмъ FASM

Posted: Tue Feb 09, 2010 1:42 pm
by Mario
На уровне приложения под Колибри все достаточно просто и прозрачно. Приложение имеет линейное адресное пространство - куда надо туда и адресуемся в пределах разрядности. Никаких головняков с сегментами. Ну, разве что в старшие адреса, в которых ядро, прямым обращением система не пустит).

Re: ASM есмъ FASM

Posted: Tue Feb 09, 2010 1:43 pm
by Nasarus
Сэнкс за внимание

Re: ASM есмъ FASM

Posted: Tue Feb 09, 2010 6:36 pm
by IgorA
Мною была создана тема viewtopic.php?f=9&t=1175&start=30
в которой я делал программу для создания программ Колибри. Эта программа чем-то похожа на IDE работает под Windows. В ней можно создавать элементы checkbox optonbox и editbox. Но я ее давно не обновлял, потому код который ею создается требует небольших доработок:
1) в элементы editbox нужно добавлять переменные mouse_dd
2) подключение файла editbox_ex.mac заменить на box_lib.mac
вроди это все изменения, которые прошли с того времени.

Re: ASM есмъ FASM

Posted: Tue Feb 09, 2010 11:30 pm
by Heavyiron
Кстати, насчет фасма. Как-то на досуге занимался причесыванием версии для колибри. Например переделал параметры на более привычный вариант (как в родных версиях для других ОС), вроде fasm /rd/1/example.asm /rd/1/example. Это позволило отказаться от эдитбокса "Path:". Минус в том, что придется слегка подкорректировать передачу параметров фасму из тинипада. Стоит этим заниматься или как обычно всем по барабану? :)

Re: ASM есмъ FASM

Posted: Tue Feb 09, 2010 11:43 pm
by Mario
ЕМНИП длинна передаваемого параметра при запуске 256 байт (или уже увеличили?), такой подход скушает глубину вложения пути, что значительно ограничит возможности компиляции.. Я лично плюсов не вижу - аргументация есть? (Кроме того что так кошерно).

Re: ASM есмъ FASM

Posted: Tue Feb 09, 2010 11:57 pm
by Heavyiron
В текущей реализации есть несколько недостатков: во-первых, бинарник ложится в одну папку с исходником, что не всегда удобно, во вторых, я даже и не знал в каком формате передавать фасму параметры, пока в исходниках не покопался, что тоже не совсем юзерфрендли. Насчет ограничения в 256 байт я как-то не подумал даже.

Re: ASM есмъ FASM

Posted: Wed Feb 10, 2010 12:10 am
by Mario
Как варианты:
1) можно сделать, как я сделал для OpenDialog - при старте в качестве параметра передать указатель на именованную область, в которой уже размещать оба пути. Причем возможности для маневрирования достаточно широкие - например, нет ограничения на длину пути, если разделить области только нулевым байтом. Из плюса - не надо менять ядро.
2) Увеличить длину пути передаваемого в ядре. Я вообще не очень понимаю откуда взялось ограничение в 256 байт вообще в Менует. Видимо сказалось отсутствие достаточно развитого менеджера памяти (Вот они гены хромой кобылы!). По идее всего-то надо из одной области в другую перекинуть. Сначала проходим по источнику узнаем длину, выделяем столько памяти сколько надо и указатель вместо области фиксированной и заранее заданной вписать указатель на выделенный кусок который отображается на область приложения. Или вообще можно общую память сразу мапить. Из минусов - нужна доработка ядра.

Re: ASM есмъ FASM

Posted: Wed Feb 10, 2010 12:38 am
by Leency
Heavyiron
Так выглядит значительно логичней. Бинарник и его едитбокс можно опустить чуть чуть ниже.

Re: ASM есмъ FASM

Posted: Wed Feb 10, 2010 3:06 am
by SII
Mario wrote:2) Увеличить длину пути передаваемого в ядре. Я вообще не очень понимаю откуда взялось ограничение в 256 байт вообще в Менует. Видимо сказалось отсутствие достаточно развитого менеджера памяти (Вот они гены хромой кобылы!). По идее всего-то надо из одной области в другую перекинуть. Сначала проходим по источнику узнаем длину, выделяем столько памяти сколько надо и указатель вместо области фиксированной и заранее заданной вписать указатель на выделенный кусок который отображается на область приложения. Или вообще можно общую память сразу мапить. Из минусов - нужна доработка ядра.
А как вообще строки хранятся в КОС? Для эффективной работы с ними обычно лучше хранить длину отдельно (как правило, непосредственно перед строкой), в то же время часто используются строки, заканчивающиеся нулевым байтом (как это принято в Си). Ну а ограничение... Я, есно, не знаю, откуда оно взялось, но если оно не 256, а 255 байт, то можно предположить, что хранится длина, и под неё отведён один байт (как это имеет место в строках Турбо Паскаля). Впрочем, и при ограничении в 256 байт можно предположить, что хранится длина, но тогда не поддерживаются пустые строки (с нулевой длиной).

В общем, со строками стоило бы выработать единообразный подход, не накладывающий жёстких ограничений. Можно, например, хранить их в таком виде:

- указатель на строку указывает на первый байт, занимаемый собственно строкой;
- строка завершается нулевым байтом (как в Си; нередко, но не всегда, это бывает удобно);
- непосредственно перед строкой расположено 2- или 4-байтовое поле с её длиной в байтах (т.е. адрес этого поля равен значению указателя на строку минус 2 или 4; длины в 64К байтов для практических применений, ИМХО, достаточно на всю оставшуюся жизнь, но можно не экономить и отвести все 4 байта).

Кроме того, имеется вопрос о кодировке символов. Конечно, ASCII и его варианты (вроде русских кодовых страниц ДОС и Винды) удобны в программировании, но они очень ограничивают набор символов, что в эпоху повсеместного распространения Юникода как-то не очень смотрится. Что же до означенного Юникода, то там несколько вариантов кодирования символов, причём почти все полноценные используют символы переменной длины (фиксированная длина только при отведении на каждый символ 32 бит -- а это жирно слишком, учитывая, что обычно используются символы латинского и русского алфавитов, для которых во всех прочих вариантах хватает 1-2 байтов).

Re: ASM есмъ FASM

Posted: Sun Feb 14, 2010 2:38 am
by Rock_maniak_forever
Так тоже не плохо, но старый вориант мне ближе, главным образам из-за того, что надо тело-движений меньше делать с прописыванием пути к исходнику и бинарнику.

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