Board.KolibriOS.org

diamond, прежде всего - ни каких претензий. НАОБОРОТ - великая благодарность
И ни на чем я не настаиваю, но просто предлагаю обратить внимание на таковую возможность.
Не более. Правда, и не менее....

diamond wrote:Но это всего лишь система связи усилий программистов, когда таких программистов много

Ну, вообще-то, я в теме. И умею пользваться таковым инструментом
diamond, вы должны согласиться, что наличие исходников на svn позволило БЫ (БЫ - обязательно, я и предыдущий пост начал со слова - ВОЗМОЖНО) задать, ПРЕДПОЛОЖИТЕЛЬНО, вопрос serge (про 68:22/23) - а где синхронный апдейт в KolibriInWin ???
Про много... Два - уже польза... Мне, к примеру, все равно каким конкретно числом выражается это "много": я вижу dff, знаю топик ему соответствующий, глаз сразу "цепляется", ну и т.д. - в результате Вы можете увидеть мой пост в этом топике.
Мой предыдущий пост означает попросту, что если бы такие вопросы были у нас логичными, то это было бы не самое плохое.
Вот и все

diamond wrote: Вон, к примеру, kfar давно выложен на svn, и толку?

А не убедительно. Какие наши годы...
Скажем, лет 5 назад я вообще не имел представления о WinApi. Сегодня - совсем другая ситуация. Это я про то, что все течет, все изменяется
Скажем, я сто раз уже натыкался на "рефлекторное" нажатие клавиш, не срабатывающее в KFAR
Настолько же "рефлекторное", насколько таковым для меня является запуск FAR (и в винде тоже) как ФМ
Но готов согласиться, что "любителей FAR-а" на форуме не так уж и много

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

ЗЫ: совсем забыл - С НАСТУПИВШИМ ВАС

diamond, вы должны согласиться, что наличие исходников на svn позволило БЫ (БЫ - обязательно, я и предыдущий пост начал со слова - ВОЗМОЖНО) задать, ПРЕДПОЛОЖИТЕЛЬНО, вопрос serge (про 68:22/23) - а где синхронный апдейт в KolibriInWin ???

Нет. Не должен и не согласен. KlbrInWin и ядро - совершенно разные проекты с совершенно разной кодовой базой и совершенно разными принципами работы. Так что подобный вопрос нелогичен, и совершенно разумным ответом было бы "а почему я, ядерщик, для добавления пары функций в ядро (Kolibri ring-0) должен ещё и разбираться в не связанном непосредственно с ядром коде и думать, как эту пару функций реализовать в совершенно других условиях (Windows ring-3)?"

Дык я и не настаиваю

НО, diamond, позвольте обратить Ваше внимание на то, что:
Вы только-что обрисовали разработчика, который еще Не поднялся (с большой буквы - обязательно, и далее - тоже) до уровня, когда для него Не является принципиальным, на каком языке, и в каком контексте - реализовывать Идею

Fasm, C[++], Delphi, ось - это просто технические подробности, ИМХО
Их не знание - опошлят всю ситуацию, конечно же. Тут возразить трудно: Автор может, действительно, остаться в одиночестве
Но это, все таки, не более чем техника дела (еще раз - имхо)
Вывод: решения является прознозом того, что произойдет. Потому и не спорю, не могу наставать

То есть различия между программированием в ring-0 под Колибри и ring-3 под WinAPI - "техника дела"? Фигасе...

Лично я никогда не был против использования эмуляторов, так как свой изначально писал для облегчения разработки приложений. Другая сторона медали заключается в том, что я всегда был против принятия баг-репортов, основанных на функционировании программ при запуске в эмуляторе. Меня и сейчас неимоверно раздражает, когда люди пишут, что что-то не работает, явно упоминая эмулятор. Хотите сделать программу лучше - тестируйте её на реальной системе. Эмулятор можно упоминать максимум в качестве постскриптума, что в нём, мол, тоже не работает.

mike.dld wrote:Другая сторона медали заключается в том, что я всегда был против принятия баг-репортов, основанных на функционировании программ при запуске в эмуляторе

А первая может заключаться, например, в том, что "ночная сборка" коллеги Leency в реальности работает, а под, эмулем говорит, что @MENU - кривое
Фиг его знает, где Leency его взял - оно менялось последний раз около года назад, мне показалось
Ну это так, что бы далеко не ходить...
Не самая плохая сторона медали, как мне показалось

2diamond: Если по большому счету, то ДА
Давайте попробуем проверять теорию на реальных примерах.
Ну например на введении 68:21/22/23
diamond, вот скажите честно: serge не сумел бы сделать синхронное сопровождение
((serege: sorry, я еще не достаточно хорошо знаю форум, чтобы блистать разнообразием в примерах))
Даже, если Вы в это не верите (ну ПРЕДПОЛОЖИМ, что serge уж необратимо заточен под gcc), дык повторюсь: " Какие наши годы"
Жизнь впереди большая, имхо

Ну я, естественно, не могу уверенно высказываться за Serge, но я на его месте в описанной ситуации - нет, не смог бы. Даже на своём месте (вообще-то предыдущие строки я писал в первую очередь о себе) я до сих пор не продублировал, например, функцию 69 в полном объёме.

diamond, повторюсь: я ни на чем не настаиваю, я просто предлагаю подумать...
Типа: Новый Год - новые мысли

diamond wrote:нет, не смог бы

Не верю

Кому надоели обруаные иконки программ Колибри в Винде, предлагаю версию KlbrInWin переписанную на С-- с иконкой более высокого разрешения.

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

Заметил пару багов в новой версии эмулятора:
1 Окно со скином фиксированных размеров (Y=4) растягивается
2 Если файловый менеджер (любой) запускает файл на исполнение, то сам зависает
3 CapsLock, ScrollLock и NumLock считаются включенными, когда соответсвующая клавиша нажата и отключаются как только она будет отжата. Этот баг работает и в старой версии.

Asper wrote:1 Окно со скином фиксированных размеров (Y=4) растягивается

Ну и не надо теребить окна стиля Y=4, сами по себе они не растягиваются, в чём проблема-то?

Asper wrote:2 Если файловый менеджер (любой) запускает файл на исполнение, то сам зависает

Да неужели? Любой файловый менеджер, любой файл и обязательно зависает? Исследования этого заявления ну никак не подтверждают.

Asper wrote:3 CapsLock, ScrollLock и NumLock считаются включенными, когда соответсвующая клавиша нажата и отключаются как только она будет отжата.

И что, какой-то программе это важно?

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

2. Может быть на твоём компьютере и не подтверждаются, но зато подтверждаются на моём ftp://kolibrios.org/users/Asper/pictures/hangup.7z и дело не в фм, а в функции 70.7. Там в файле I40EMUL.INC после метки server_run_prg стоит вызов функции WaitForSingleObject, которая принимает в качестве параметра бесконечное время ожидания сигнала (INFINITE=-1).
Поначалу я поставил ret после call release_shared, чтобы исключить вызов WaitForSingleObject, как в предыдущей версии, но это не понравилось kfar'у


Тогда я просто заменил -1 и все заработало.

3. По-настоящему пока что ни одной, но отрисовку индикаторов у ZKEY я поначалу тестировал в эмуляторе, пока не понял что не стоит искать ошибку там где её нет.

Вообщем вот здесь исправлены пункты 2 и 3.

Ну и "исправления"... То, что исправляется заменой одной строчки, оставлено, а изменения в двух других случаях некорректны. То, что эмуляция состояния *Lock неверна, видно из прилагаемого примера (расширение .kex из-за того, что файл с пустым расширением не даёт залить форум; обратите внимание на отзывчивость к нажатиям CapsLock на реальной системе и под предлагаемым вариантом). Второе изменение намертво гробит всю обратную связь от функции 70.7, в частности, под этим не может стабильно работать отладчик.

Нажимаю CapsLock следующая строчка в консоли выводит измененное состояние CapsLock и на реальной системе и в этом варианте, вот только строчки на реальной системе выводятся чаще чем в эмуляторе, что вобщем-то оправдано и к предлагаемым изменениям отношения не имеет. В чём некорректность-то? Согласен с тем, что 0 не стоит передавать функции WaitForSingleObject, но и -1 по-моему не лучший вариант, любое другое значение годится. А отладчиком я даже и не пытался воспользоваться через KlbrInWin потому и не совсем понимал, для нужна обратная связь, спасибо за разъяснения. Я согласен что предлагаемые мной изменения не оптимальны, это всего лишь вариант, чтобы не быть голословным.