Comments 53
Спасибо!
KOL — отличная библиотека, сделана весьма разумно и добротно. Когда я еще не был веб программистом и писал программы на Delphi я ее использовал, только жалко, что открыл ее под конец использования Delphi :(
GRush не использовал, но судя по всему автор проделал отличную работу. В списке моих авторитетов в программировании добавился еще один пунктик :)
GRush не использовал, но судя по всему автор проделал отличную работу. В списке моих авторитетов в программировании добавился еще один пунктик :)
костыли
Такие труды, а уже не актуально. Какое то странное чувство, обидно что ли.
Видимо достоинство мирового open source в том, что такие «инвестиции» дольше живут и развиваются.
Но естественный отбор это хорошо.
Видимо достоинство мирового open source в том, что такие «инвестиции» дольше живут и развиваются.
Но естественный отбор это хорошо.
Всегда использовал KOL при разработке. Разработчикам большое спасибо!
Как вы умудрились то всегда его использовать?! Чем занимались, сознавайтесь. Ну я понимаю для себя кодить, но ведь в продакшен на KOL пускать не будете?.. Или…
Присоединяюсь, для меня тоже всегда было удивительно, где люди умудряются его использовать (до появления KOL'а помню еще один аналогичный иностранный проект). И ту статью в журнале «Программист» тоже помню, она вызвала у меня еще большое удивление. Я за многие годы так и не придумал куда же действительно можно всунуть KOL, даже в «специфическом» софте, на мой взгляд, проще было чиркануть пару строк на ассемблере (не забывая чистый winapi), чем разбираться в совершенно новом фреймворке. Сам конечно поигрался, но никогда так и не пришлось нигде использовать.
Подписываюсь. Именно это и пытаюсь донести. Как частичка истории — да. Пошумело. Даже сейчас находятся старожилы, которые используют. Выход на продакшен возможен, но оно того не стоит.
у меня это была программа для запуска других программ)) с помоom. коротких команд в окошке выполнить. до сих пор пользуюсь,
весит около 30 кб и, главное, работает.
весит около 30 кб и, главное, работает.
Всё ещё пользуюсь Bars (http://kolmck.net/apps/Bars.zip). Правда немного переделанным под себя. Это такой док для ярлыков программ. Он оказался на столько удачным, что я его использовал на всех своих машинах. Начиная от windows 95. И даже сейчас на windows 7 эта программа у меня работает.
Также мой диплом был сделан с использованием KOL.
Также мой диплом был сделан с использованием KOL.
А в чем вобственно мне сознаваться? :) Я и не скрываю, что программы писал всегда исключительно для себя и знакомых. Паршивый из меня программист, т.к. я самоучка. Ни на что кроме банальных прикладных программ моих знаний не хватает. Вот именно в области «банальных прикладных» программ KOL отлично делал всё, что мне было необходимо.
Быстро, удобно, просто, и классный результат — компактный, быстрый, а с лазарусом ещё и кросплатформенный (под PPC по крайней мере).
А к комментарию CLR — не все знают ассемблер, во-первых, а во-вторых, разбираться в KOL при наличие MCK особенной необходимости нет. Поставил и используй в удовольствие!
Быстро, удобно, просто, и классный результат — компактный, быстрый, а с лазарусом ещё и кросплатформенный (под PPC по крайней мере).
А к комментарию CLR — не все знают ассемблер, во-первых, а во-вторых, разбираться в KOL при наличие MCK особенной необходимости нет. Поставил и используй в удовольствие!
Моя заметка про ассемблер относится к тому роду софта, в каком больше всего люди использовали KOL и на что намекает naum — трояны и тому подобное. Просто как раз для прикладных задачек и повседневного использования KOL особой выгоды-то не давал (хотя может я и ошибаюсь, мне действительно интересно).
Не-не, я не пытался вас задеть как-либо. Просто речь об использовании KOL в продакшен не может быть заведена, если вы не под градусом. Потому и логично было бы предположить, что вы использовали его в своих каких-то наработках / утилитах & etc. Хотя, если б у вас был бы опыт shareware на KOL — было бы интересно послушать и обсудить.
Порадовало начало в стиле «когда деревья были большими». В мои времена больших деревьев был DOS, Turbo Pascal и Turbo C. И все писали текстовые оконно-менюшные библиотеки, чтобы было красиво, как в Norton Commander. При этом круто было писать важные процедуры на ассемблере, поскольку производительность паскаля, например, казалась «диверсией… против ИТ-индустрии». Которой, кстати, у нас тут вообще еще не было. :)
А мораль… Мораль ясна, думаю.
А мораль… Мораль ясна, думаю.
мне кажется это уже не актуально.
весит программа 1 мб или 10 мб? не все ли равно?
у нас в деревне 2 мбит скорость, не надо говорить про замкадье
весит программа 1 мб или 10 мб? не все ли равно?
у нас в деревне 2 мбит скорость, не надо говорить про замкадье
Актуально, и, более того, тут народ собрался понастольжировать. Не мешайте.
Почему актуально? Когда я качаю утилиту 5 Mb и понимаю что делает она чуть больше батника на 1 кб, мне становится грустно. Ну зачем просто так трафик гонять?
Почему актуально? Когда я качаю утилиту 5 Mb и понимаю что делает она чуть больше батника на 1 кб, мне становится грустно. Ну зачем просто так трафик гонять?
Актуальность этого не в объёмах скачиваемого, а в производительности.
Помню, люди с подозрением относились к моим утлитам, написанным на KOL.
— Уж очень маленький размер, это точно не вирус?
— Уж очень маленький размер, это точно не вирус?
Потому что вирусмейкеры-дельферы (их, адекватов, было очень мало, но их уровень зашкаливал. ms-rem, мир его праху, был достоен. один совместный проект дал понимание того, что язык вообще не имеет значение, что бы не требовалось сделать) взяли KOL/MCK на вооружение сразу же. весит почти как WinAPI, но при этом маленькая простенькая удобная оберточка.
Как-то давно писал на этом деле утилитки и оболочки для интернет-кафе. Штука очень приятная.
да, на win98 .net идет не особо — но где теперь delphi а где .net?
.NET это и есть правильный Делфи :)
Уточните что вы имели в виду? А то не понятно за что минус )
Вопрос не ко мне ) А по поводу .NET и Дельфи, я считаю первое большой шаг вперед, благодаря идеологии управляемого кода и абстрагированию библиотеки и среды выполнения от языка. Еще бы от платформы как следует абстрагировались, было бы совсем хорошо. Но и того что есть достаточно, независимые реализации CLR понемногу появляются.
Ох, месье, вы заблуждаетесь.
Само наличие homm'a на хабре уже радует. Я в те годы был слишком многоликим, чтоб меня запомнить, но пересекались не раз на многих ресурсах.
KOL/MCK нашли себя в андеграунде, что не удивительно (90% вирусмейкеров, которые пишут на дельфи, перешли на него, когда писали генераторы / крипторы и прочее).
KOL/MCK — для меня это всегда было что-то далекое и немного бесполезное. VCL давал все что требуется. Без косяков, без диких танцев. Разница в объеме? Ну жали UPX'ом или популярным тогда AsPack'ом 2.хх. В скорости? Не сильно проигрывает. Чем последние версии отличаются от использования VCL от D3? Он плавно превратился в VCL, перенимая многие черты, а многие, к сожа
Для меня сейчас существует только два великих фреймворка/тулкита — VCL и Qt, которые на самом деле жили раньше очень тесно (вспомните CLX). Первый — поражает удобством и охватом (и это за много лет до появления .NET как фреймвокра, а не как идеологии и подхода), второй — поражает удобством, охватом и идеологией (привет .NET).
Хоть запуляйте минусами, но резюмирую (говорю именно про фреймворки):
VCL, Qt — шедевры, появившиеся много лет, опередившие время и живущие до сих пор, более того жить они будут долго. .NET хорошо, но опоздало и как то шатко.
KOL/MCK нашли себя в андеграунде, что не удивительно (90% вирусмейкеров, которые пишут на дельфи, перешли на него, когда писали генераторы / крипторы и прочее).
KOL/MCK — для меня это всегда было что-то далекое и немного бесполезное. VCL давал все что требуется. Без косяков, без диких танцев. Разница в объеме? Ну жали UPX'ом или популярным тогда AsPack'ом 2.хх. В скорости? Не сильно проигрывает. Чем последние версии отличаются от использования VCL от D3? Он плавно превратился в VCL, перенимая многие черты, а многие, к сожа
Для меня сейчас существует только два великих фреймворка/тулкита — VCL и Qt, которые на самом деле жили раньше очень тесно (вспомните CLX). Первый — поражает удобством и охватом (и это за много лет до появления .NET как фреймвокра, а не как идеологии и подхода), второй — поражает удобством, охватом и идеологией (привет .NET).
Хоть запуляйте минусами, но резюмирую (говорю именно про фреймворки):
VCL, Qt — шедевры, появившиеся много лет, опередившие время и живущие до сих пор, более того жить они будут долго. .NET хорошо, но опоздало и как то шатко.
Как-то странное у вас начало выглядит, или VCL и Delphi, но не слова о Builder'e, но при этом упомянули писать на чистом WinAPI, но я даже о том, чтобы на Дельфи кто-то писал на WinAPI не слышал :) А вот о MFC вы не упомянули, почему?
> но я даже о том, чтобы на Дельфи кто-то писал на WinAPI не слышал :)
Распространенное заблуждение, вызванное тем, что когда-то язык паскаль задумывался для обучения студентов и также тем, что порог вхождения у Delphi крайне низок. Но это не отменяет того факта, что у многих Delphi программистов среди настольных книг можно найти Рихтера, Руссиновича, Соломона или знаменитые «синие» манулы от Intel. Никто же не заставляет вас использовать VCL или многие стандартные и распухшие классы. Многие пишут на чистом api, да и ассемблер всегда был в почете у «паскальшиков», пожалуй даже в большем, чем у сишников (объясняется ранними проблемами языка).
Как пример, вот чем некоторые любители занимаются — www.wasm.ru/series.php?sid=8
Распространенное заблуждение, вызванное тем, что когда-то язык паскаль задумывался для обучения студентов и также тем, что порог вхождения у Delphi крайне низок. Но это не отменяет того факта, что у многих Delphi программистов среди настольных книг можно найти Рихтера, Руссиновича, Соломона или знаменитые «синие» манулы от Intel. Никто же не заставляет вас использовать VCL или многие стандартные и распухшие классы. Многие пишут на чистом api, да и ассемблер всегда был в почете у «паскальшиков», пожалуй даже в большем, чем у сишников (объясняется ранними проблемами языка).
Как пример, вот чем некоторые любители занимаются — www.wasm.ru/series.php?sid=8
Отличные статьи, помню до сих пор, какое впечатление производили. Особенно на малообразованную молодежь :)
Еще немного и я напою вас пивом.
Паскальщики это другой вопрос, я тоже писал и на Турбо Паскале и ТурбоВижн не просто слова :)
Но сама среда Delphi как раз и порадила этот RAD подход от IDE, что код, каркасс не писался.
А вставки, написание своих dll и vxd тоже интересно, а всё к тому, что не упомянули MFC ^)
Но сама среда Delphi как раз и порадила этот RAD подход от IDE, что код, каркасс не писался.
А вставки, написание своих dll и vxd тоже интересно, а всё к тому, что не упомянули MFC ^)
По моему на все ваши вопросы отвечает фраза «Для тех, что писал под Delphi, выбор был не велик». Вы не внимательно читали. Ну а про то, что вы не слышали, тут я не виноват.
Вот, как приятно читать вещи типа «укладывалась в несколько мегабайт».
Но, с другой стороны отрисовка градиента «70 раз в секунду» на современном процессоре — маловато (как же игры работают, там более сложные картинки), может тут надо уже видеокарту там задействовать, или directX какой-нибудь, чтобы быстрее рисовалось.
Но, с другой стороны отрисовка градиента «70 раз в секунду» на современном процессоре — маловато (как же игры работают, там более сложные картинки), может тут надо уже видеокарту там задействовать, или directX какой-нибудь, чтобы быстрее рисовалось.
Это очень даже приличная скорость, ну и вдобавок GDI+ тогда еще был в диковинку, вот люди и мучились (а под Win'98 вообще нужно было самостоятельно таскать с собой либу)
GDI+ богомерзкая тварь, которая порождает лишь дикую обертку над существующими реализациями (GDI) и дает падение скорости и кучу головных болей. 80% функционала GDI+ есть в GDI но просто не обернуто по правилам ООП, остальные 20% дописываются в зависимости от задачи, часто вообще не требуются.
Я конечно резко кидаюсь словами, но фиксируем — все зависит от задачи. Использование GDI+ в требовательном софте — неразумно, имхо.
Я конечно резко кидаюсь словами, но фиксируем — все зависит от задачи. Использование GDI+ в требовательном софте — неразумно, имхо.
PNG, сглаживание и полупрозрачность — в GDI где?
А PNG, сглаживание и полупрозрачность без GDI+ невозможно по вашему? Я лишь говорю о том, что GDI+ не есть хорошо в плане соотношения «цена»/качество.
Я это спрашивал, прочитав фразу что GDI+ обёртка над GDI.
Ну, по сути, так оно и есть. GDI — плоское C API, GDI+ — ООП обертка с небольшим дополнительным функционалом, который реализуется и на GDI, но путем использования готовых решений третьих лиц, либо велосипедирования.
GDI+ это специально сделанная совместимой альтернатива GDI, альтернатива, в которой на шаг вперед продвинуты почти все возможности. Она не пользуется GDI ни для чего, и она по возможности пользуется видеокартой. Зря вы её ругаете. На видеокартах с поддержкой её возможностей она не тормозит. А на других видеокартах готовые решения третьих лиц и велосипеды будут тормозить для той же графики ничуть не меньше.
Большая часть времени, как понятно из следующей цифры в 320 кадров, занимает отрисовка круглых уголков. Сейчас почему-то работает чуть помедленнее, чем указано в топике, система за день устала. Но цифры такие:
Отрисовка того, что описано выше 100 раз — 1719 мс.
Без системных ф-ий StretchBlt, наносящих исходное изображение на временное с увеличением — 1016 мс.
Без уменьшения с антиалиазингом — 1609 мс.
Без обоих — 922 мс
Еще и без блита результата на рабочую поверхность — 906 мс.
Вообще без круглых уголков — 306 мс.
Как видно слабых места 2, StretchBlt которую особо не заменишь и создание временных битмапов, которое единственное происходит в предпоследней строчке. Их можно было бы кешировать, но это лишняя память.
Да и вообще такие радикально большие кругляшки на краях (100 пикселей) мало кому нужны. С радиусом 10 пикселей скорость практически не отличается прямых углов.
Отрисовка того, что описано выше 100 раз — 1719 мс.
Без системных ф-ий StretchBlt, наносящих исходное изображение на временное с увеличением — 1016 мс.
Без уменьшения с антиалиазингом — 1609 мс.
Без обоих — 922 мс
Еще и без блита результата на рабочую поверхность — 906 мс.
Вообще без круглых уголков — 306 мс.
Как видно слабых места 2, StretchBlt которую особо не заменишь и создание временных битмапов, которое единственное происходит в предпоследней строчке. Их можно было бы кешировать, но это лишняя память.
Да и вообще такие радикально большие кругляшки на краях (100 пикселей) мало кому нужны. С радиусом 10 пикселей скорость практически не отличается прямых углов.
Использовать KOL начал когда учился в университете. С ним на моей старенькой машинке на Delphi3 проект компилировался 15-20 сек, а не минуту. И работали программы быстрее. Позже сделал замену системных модулей под Delphi3. Тогда существовали только замены для D4,5,6.
Оригинальные RB Controls под KOL портировал я. И знал, что оно тормозит. Тормозит как оригинал, так и портированая версия. Особенно сплитер. Но тогда хотелось чего-то красивого.
И я рад, что мои наработки сподвигли автора топика написать GRush Controls. Когда я их увидел, то стало понятно, что продолжать работать над RB Controls for KOL смысла нет. GRush работали быстро, красиво и не раздували экзэшник. (Привет homm!)
На этом этапе я перестал следить за жизнью проекта Кладова.
Но до сих пор играю в игру AutoWars. kolmck.net/apps/AutoWar.zip
Мой бот всегда побеждает. (Сразимся?)
Оригинальные RB Controls под KOL портировал я. И знал, что оно тормозит. Тормозит как оригинал, так и портированая версия. Особенно сплитер. Но тогда хотелось чего-то красивого.
И я рад, что мои наработки сподвигли автора топика написать GRush Controls. Когда я их увидел, то стало понятно, что продолжать работать над RB Controls for KOL смысла нет. GRush работали быстро, красиво и не раздували экзэшник. (Привет homm!)
На этом этапе я перестал следить за жизнью проекта Кладова.
Но до сих пор играю в игру AutoWars. kolmck.net/apps/AutoWar.zip
Мой бот всегда побеждает. (Сразимся?)
Может утолите моё любопытство? Почему контролы называются GRush?
Sign up to leave a comment.
Другой Open Source