Здравствуйте, Аноним, Вы писали:
А>Как показывает практика, открытие исходного кода положительно сказывается на проекте.
Мне, как пользователю HTMLayout абстрактный опен-сорс в вакууме не интересен. Текущая ситуация с одним основателем, регулярным баг-фиксом и динамичным развитием, более чем подходит.
Могу только пожелать коммерческого успеха и популярности библиотеке в будущем
Здравствуйте, ShaggyOwl, Вы писали:
А>>Как показывает практика, открытие исходного кода положительно сказывается на проекте.
SO>Мне, как пользователю HTMLayout абстрактный опен-сорс в вакууме не интересен. Текущая ситуация с одним основателем, регулярным баг-фиксом и динамичным развитием, более чем подходит. SO>Могу только пожелать коммерческого успеха и популярности библиотеке в будущем
Это недальновидно.
c-smile один, а количество работы со временем всегда растёт. Иногда в геометрической прогрессии: (Windows,Mobile,Linux)*(HTMLayout,Sciter,TIScript)*(x86,x64), добавьте сюда OSX — к кол-ву штук, которые надо собрать, хотя бы разок запустить, выложить, прибавляется не 1, а сразу 6. Или 8, или 10, смотря какие там будут комбинации: OSX это еще и PowerPC (это там где порядок байт другой и SIGBUS при чтении без выравнивания, в общем, свои неожиданные сюрпризы), Linux на каком-нибудь ARM и т.д.
Я знаю как это бывает — один человек не вывезет за весь мир. Рано или поздно придется выбирать:
1. нанимать еще людей, со всеми вытекающими: отстранение самого опытного в руководство, проблема обучения людей, качества результата, библиотека станет небесплатной => вопросы «за что платить деньги если нет хорошего туториала?», «как можно положиться, если в новых билдах регулярно что-то ломается?» => еще люди на тестирование и т.д. и т.п. пошло-поехало.
2. отрывать лишние яйца: сказать, у нас будет только Win32, Win64, Windows Mobile. Остальные пусть бреются.
3. выдать независимые части в коммунити, например, поддержку экзотических графических платформ, полуавтоматическое тестирование, написание туториалов/документации. Автор остается на месте, делает только то, что ему нужно, и не делает того, что не нужно. Некоторые фетиши при этом могут пострадать, вроде single-small-DLL-under-1MB.
4. по принципу «не надо бояться работы», продолжать планомерно делать все в одиночку => постоянное замедление развития, увеличение срока между релизами => с логичным концом, когда в один прекрасный день осознаешь, что весь его потратил на текучку, а самый нижний пункт в TODO был добавлен 3 года назад.
5. более «мягкий вариант» п.1: компания становится подразделением другой, маркетинг, работу с кадрами и пр. берут на себя другие люди, автор становится главным разработчиком и архитектором, продолжает делать то, что делал, насколько это укладывается в интересы всей корпорации.
Мне тоже исходники целиком не интересны. Но вот уже в отношении Mac OS X неоднократно звучали намерения просто взять gtk (пусть даже без X11), а это уже значит, что пользователи видят: программа запускается на OSX только для галочки, не интегрируется в систему (Finder, Spotlight, Dock, Services Menu etc.), уже принесена жертва. Почему? Понятно почему, три подложки использовать, это уже слишком. И такая судьба будет у всех прочих благих пожеланий.
Здравствуйте, yarus23, Вы писали:
Y>Как показывает практика открывают совсем дохлые проекты, коммерческая перспектива которых стремилась к нулю и они и так были ни кому не нужны.
Расскажите это Гоголю с его Андроидом — http://android-developers.blogspot.com/2008/10/android-is-now-open-source.html
Это не агитация за open source, просто попытка опровергнуть ваше утвержедние.
Здравствуйте, Аноним, Вы писали:
А>Как показывает практика, открытие исходного кода положительно сказывается на проекте.
Как показывает практика даже просто делание билиотеки free создает гимор для разработчиков.
Вот из сегодняшних писем на моем почтовом ящике:
Dear sirs are you the owners for the antispy ware XP Antispyware. If so I need to know how to remove it from my laptop as it has jacked my laptop and I cant even log onto the internet with it now and I keep getting random web sites loaded on my laptop. Your imeditae response to this problem would be appreciated as my next step is to wipe my hard drive and if I do that I will lose far to much valuble information for my business.
А>Так как доступ к исходному коду свободный, любой квалифицированный разработчик сможет улучшать проект,исправлять ошибки. А>Для того, чтобы исходный код можно было использовать в проприетарных (закрытых) приложениях, можно выложить исходники под лицензией Lesser GPL (LGPL). А>Исходники должны открываться тогда, когда они нужны сообществу. Иначе может получиться как с FAR'ом — не так давно его исходник открыли, но время уже упущено — время FAR'а уже прошло, и желающих внести свою лепту в его развитие можно пересчитать по пальцам одной руки.
Если нужны то да. Тебе нужны? Если да то зачем?
Лично мне исходники FARа никогда не нужны были. Работает — и ладно. Тем и ценнен что работает.
А>То же самое касается и многих других проектов, разработчики которых открыли исходники слишком поздно.
Каких например?
Скажем кого радует открытость кода Mozilla или WebKit? Есть здесь люди кто реально хоть раз туда лазил? Если да то а) зачем и б) что нашел?
Здравствуйте, Кодёнок, Вы писали:
Кё>3. выдать независимые части в коммунити, например, поддержку экзотических графических платформ, полуавтоматическое тестирование, написание туториалов/документации. Автор остается на месте, делает только то, что ему нужно, и не делает того, что не нужно. Некоторые фетиши при этом могут пострадать, вроде single-small-DLL-under-1MB.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Аноним, Вы писали:
А>>Вы планируете открыть исходный код HTMLayout?
CS>Я уже писал как-то здесь: htmlayout/sciter будет открыт в public domain если я по каким-то причинам CS>не смогу/не захочу продолжать проект дальше.
CS>И в настоящее время исходники в общем-то не закрыты. CS>Они открыты тем людям кто подписал NDA и четко обозначили зачем они им нужны. CS>Т.е. если это коммерческиий интерес то доступ платный. CS>Если это коммерческий инетрес но вы можете внести свою лепту то я предоставлю доступ бесплатно CS>ко взаимной пользе. Здесь на форуме есть люди у которых есть доступ. CS>Например если у кого-то есть потребность/желание/возможности в портировании на какие-то платформы — CS>пишите.
Хотелось бы HTMLayout для Win64, Linux, *BSD, Mac OS X
CS>Код местами нетривиальный и сильно специфический. В том смысле что сильно помочь в понимании CS>того что происходит в том или ином случае наличие исходников врядли поможет. CS>Как вообще устроен html/css движок можно посмотреть на примерах FF или WebKit. CS>Но практика показывает что открытось Gecko и WebKit тоже слабо помогает. У меня CS>несколко попроще/компактнее но тем не менее.
Как показывает практика, открытие исходного кода положительно сказывается на проекте.
Так как доступ к исходному коду свободный, любой квалифицированный разработчик сможет улучшать проект,исправлять ошибки.
Для того, чтобы исходный код можно было использовать в проприетарных (закрытых) приложениях, можно выложить исходники под лицензией Lesser GPL (LGPL).
Исходники должны открываться тогда, когда они нужны сообществу. Иначе может получиться как с FAR'ом — не так давно его исходник открыли, но время уже упущено — время FAR'а уже прошло, и желающих внести свою лепту в его развитие можно пересчитать по пальцам одной руки.
То же самое касается и многих других проектов, разработчики которых открыли исходники слишком поздно.
Здравствуйте, c-smile, Вы писали:
CS>Делая Linux порт так и хочется весь этот стафф линуксоидный выбросить и написать на голом FB каком.
Просто выберете наиболее удобный для себя вариант. Критерии удобства — на ваш вкус. Кому будет нужно что-то ещё — дадите исходники и сами слепят по аналогии.
Если у вас сейчас есть выделенный porting layer — все просто. Ну, не очень сложно, по крайней мере .
Здравствуйте, yarus23, Вы писали: Y>... потому что сам принцип двухпанельных консольных файл менеджеров стал технологическим трупом. Улыбнуло. А как же Total Commander? Мне бы такой "технологический труп"
Проблема Far в его "консольной" технологии, имхо.
Здравствуйте, Кодёнок, Вы писали:
Кё>Мне тоже исходники целиком не интересны. Но вот уже в отношении Mac OS X неоднократно звучали намерения просто взять gtk (пусть даже без X11), а это уже значит, что пользователи видят: программа запускается на OSX только для галочки, не интегрируется в систему (Finder, Spotlight, Dock, Services Menu etc.), уже принесена жертва. Почему? Понятно почему, три подложки использовать, это уже слишком. И такая судьба будет у всех прочих благих пожеланий.
Описал так, что пора если не лезть в петлю, то по крайней мере начинать ее вязать
Единственная серьезная проблема у HTMLayout — это портирование на другие платформы. И я, признаться, не вижу легкого пути ее решения. Может быть, это неразрешимая задача.
В остальном — свежие фичи, баг-фиксы, поддержка, все тип-топ.
Здравствуйте, Аноним, Вы писали:
А>Вы планируете открыть исходный код HTMLayout?
Я уже писал как-то здесь: htmlayout/sciter будет открыт в public domain если я по каким-то причинам
не смогу/не захочу продолжать проект дальше.
И в настоящее время исходники в общем-то не закрыты.
Они открыты тем людям кто подписал NDA и четко обозначили зачем они им нужны.
Т.е. если это коммерческиий интерес то доступ платный.
Если это коммерческий инетрес но вы можете внести свою лепту то я предоставлю доступ бесплатно
ко взаимной пользе. Здесь на форуме есть люди у которых есть доступ.
Например если у кого-то есть потребность/желание/возможности в портировании на какие-то платформы —
пишите.
Код местами нетривиальный и сильно специфический. В том смысле что сильно помочь в понимании
того что происходит в том или ином случае наличие исходников врядли поможет.
Как вообще устроен html/css движок можно посмотреть на примерах FF или WebKit.
Но практика показывает что открытось Gecko и WebKit тоже слабо помогает. У меня
несколко попроще/компактнее но тем не менее.
А>Хотелось бы HTMLayout для Win64, Linux, *BSD, Mac OS X
Win64 уже давно есть. А вы будете портировать на Mac OS X/Linux/BSD или это риторическое замечание?
Думаю что открытие исходников принесет великий разброд и шатание масс, потому что код достаточно сложен в понимании и уйдет не один месяц чтобы в нем разобраться. Собственно это hardcore c++, совсем не для новичков. А у профи боюсь времени мало, у них дети, жены, любовницы — надо кормить. То же ядро линукс двигают корпорации и наемные программисты а не хакеры-романтики забесплатно. Я согласен с точкой зрения автора — открыть тогда когда он не сможет по каким-либо причинам поддерживать проект.
А>Как показывает практика, открытие исходного кода положительно сказывается на проекте.
Как показывает практика открывают совсем дохлые проекты, коммерческая перспектива которых стремилась к нулю и они и так были ни кому не нужны.
Far например открыли потому что он стал плохо продаваться. Если бы его открыли раньше, у него было бы не больше пользователей чем сейчас, потому что сам принцип двухпанельных консольных файл менеджеров стал технологическим трупом.
А>Уважаемые разработчики HTMLayout!
А>Вы планируете открыть исходный код HTMLayout?
Совершенно согласен с c-smile: пока автор АКТИВНО поддерживает свой проект с закрытыми текстами — открывать их не имеет смысла — любые вопросы проще решать через автора. Да, может хотелось бы большего, но я не уверен, что изучение чужого кода, внесение в него изменений и самое главное отладка стоит того. Тем более, что по набору возможностей HTMLayout уже давно позволяет реализовать практически любой интерфейс, пусть даже ценой дополнительных усилий.
Что касается поддержки комюнити, то совсем не факт, что это будет лучше. И Far Manager совсем не показатель. Есть и обратный опыт, когда разрабочик Cobian Backup (имхо отличного и бесплатного продукта) открывал исходники, поддавшись на уговоры и закрывал их обратно, поскольку ничего хорошего из этого не вышло.
Здравствуйте, c-smile, Вы писали:
CS>И в настоящее время исходники в общем-то не закрыты. CS>Они открыты тем людям кто подписал NDA и четко обозначили зачем они им нужны. CS>Т.е. если это коммерческиий интерес то доступ платный. CS>Если это коммерческий инетрес но вы можете внести свою лепту то я предоставлю доступ бесплатно CS>ко взаимной пользе. Здесь на форуме есть люди у которых есть доступ. CS>Например если у кого-то есть потребность/желание/возможности в портировании на какие-то платформы — CS>пишите.
Есть возможность в оптимизации на асме.
Так же есть возможность в портировании на FreeBSD, но это врятли =)
мыло: ASMelancholy@gmail.com
Здравствуйте, Melancholy, Вы писали:
M>Есть возможность в оптимизации на асме.
асм я не использую в принципе ибо он разный на x86 x64 и на Mobile. За предложение спасибо.
M>Так же есть возможность в портировании на FreeBSD, но это врятли =)
Угу. FreeBSD как GUI платформа представляется проблематичной. В принципе порт на Linux должен
и там работать с минимальными доделками.
Здравствуйте, c-smile, Вы писали:
M>>Так же есть возможность в портировании на FreeBSD, но это врятли =) CS>Угу. FreeBSD как GUI платформа представляется проблематичной. В принципе порт на Linux должен CS>и там работать с минимальными доделками.
Собственно, а почему? Там просто надо скомпилить в местный формат ELF-ов, xlib там остаётся тем же.
PS: мой порт на SWT чувствует себя неплохо. Выложу в OpenSource как только с товарищами из США согласую.
Здравствуйте, alsemm, Вы писали:
A>Здравствуйте, yarus23, Вы писали:
Y>>Как показывает практика открывают совсем дохлые проекты, коммерческая перспектива которых стремилась к нулю и они и так были ни кому не нужны. A>Расскажите это Гоголю с его Андроидом — http://android-developers.blogspot.com/2008/10/android-is-now-open-source.html A>Это не агитация за open source, просто попытка опровергнуть ваше утвержедние.
Это сугубо маркетинговый ход для Android и Chrome. Google Earth например не окрыта. Google search engine тоже.
Касательно OS вообще. Самая распространненая consumer OS это Windows. Исходники закрыты. Но открыты тем кому это нужно.
Т.е. успех/неуспех не определяется открытостью/закрытостью.
OpenSource имеет смысл на определенных проектах. Но в большинстве случаев OpenSource как community based модель разработки не работает.
Особенно в UI. Linux GUI effort это модель с бору по сосенке. Хозяина нет — порядка нет.
Например сейчас в Linux GUI зверинец альтернативных API работы со шрифтами и графикой: XWindow+XFont, XWindow+XftFont, Cairo+XftFont, Pango+Cairo. Это заставляет снимать шляпу перед разработчиками GDI. Там конечно своих заморочек хватает (каша с DDB/DIB), но core функциональность стабильная и расширяемая. Даже GDI+ можно втащить в GDI если нужно.
Делая Linux порт так и хочется весь этот стафф линуксоидный выбросить и написать на голом FB каком. Но сколько же можно лисапеты то писать...
Как показывает практика даже просто делание билиотеки free создает гимор для разработчиков.
Чья практика показывает? Практика Linux? Или практика Qt, boost, OpenSSL или libxml2? Или практика FreeBSD, KDE или Gnome? Или может быть практика Android? И в чём собственно может заключаться гемор?
Скажем кого радует открытость кода Mozilla или WebKit? Есть здесь люди кто реально хоть раз туда лазил? Если да то а) зачем и б) что нашел?
Лично я туда не разу не лазил, но прекрасно представляю для чего туда люди лазают. Трудно представить более совершенную среду для установки собственных расширений, чем у Mozilla Firefox; и именно благодаря открытости исходных текстов и возможности досконального изучения принципов и механизмов работы Firefox, Thunderbird, etc. существует такое огромное количество расширений для них, в том числе очень нужных и эффективных.
Мне, как пользователю HTMLayout абстрактный опен-сорс в вакууме не интересен. Текущая ситуация с одним основателем, регулярным баг-фиксом и динамичным развитием, более чем подходит.
Каким образом открытость Qt или Boost мешает их регулярному баг-фиксу или динамичному развитию? Ответ: никаким!
Мне кажется, что вы немного путаете тёплое с мягким ...
Во-первых: Open-Source != педалить за бесплатно. На этом деле люди умеют зарабатывать кучу денег.
Во-вторых: Open-Source не всегда означает получить продукт бесплатно. Например Qt открыта, но небесплатна (по крайней мере, была до того, как её не купила Nokia и не расхалявила). Скажем в случае открытия исходников HTMLayout каким образом это сказывается на technical support и Buy HTMLayout Support now? ИМХО: никаким.
В-третьих: Open-Source != мусорка исходных текстов. Open Source, как правило, открывает исходники для чтения для всех, и для записи для тех кто в состоянии внести свою лепту в развитие продукта. Прекрасный пример тому: boost.
Всегда в лицензионом соглашении можно прописать, что для бесплатного использования библиотеки вы обязаны собирать данную библиотеку динамически и поставлять её вместе со своим продуктом + указать ссылку об использовании такой библиотеки в about/help местах продукта. К примеру так поступает сейчас Qt!
Вот такие вот размеры получились:
Full htmlayout: Not compreesed: 1,470,464 bytes, UPX compressed: 602,624 bytes
htmlayout, no <richtext>: Not compreesed: 1,212,416 bytes, UPX compressed: 504,832 bytes
htmlayout, no <richtext>, no AGG and so no SVG. essential version(*): Not compreesed: 1,085,440 bytes, UPX compressed: 455,168 bytes
htmlayout, --"-- and no JPG and PNG libs (loading through Imaging API so requires COM initialization), minimal version(*): Not compreesed: 999,424 bytes, UPX compressed: 397,312 bytes
На примере библиотеки Qt мы можем наблюдать разбиение продукта на логические модули по мере его развития. Т.е. если Qt версий 3.Х.Х собиралась в одну единственную dll, то начиная с версии 4, библиотека разбита на несколько модулей. Теперь, если я разрабатываю продукт с помощью Qt я тащу реально только те модули, которые мне действительно нужно, не прихватывая например неиспользуемые возможности QtAssistantClient4.dll, QtDesigner4.dll, QtNetwork4.dll, QtOpenGL4.dll, QtScript4.dll, QtSql4.dll, QtSvg4.dll, а беру только QtCore4.dll, QtGui4.dll и QtXml4.dll. Мне кажется, что подобное можно проделать и с HTMLayout, и если я, к примеру, не использую AGG, SVG и Richtext, то не тяну соответственно HTMLayoutAgg.dll, HTMLayoutSvg.dll и HTMLayoutRtf.dll, а беру только лишь HTMLayoutCore.dll и HTMLayoutGui.dll.
Что лично мне нравится при использовании библиотек с открытым исходным кодом, так это возможность собственно-ручно собрать эти библиотеки. При этом я:
Могу сам указать с какой CRT и каким образом линковаться. Будет ли эта CRT лежать в msvcrt.dll, в msvcr70.dll, в msvcr80.dll или в msvcr90.dll, или CRT вообще будет находиться в моём модуле, т.к. я слинкую его с CRT статически. Я вот даже не знаю, использует ли HtmLayout.dll С-Runtime, в зависимостях файла нет ссылки на msvcrt.dll, есть только ссылка на kernel32.dll, при этом судя по таблице импорта из kernel32 не импортируются CRT-шные функции, соответственно HtmLayout либо вообще не использует CRT либо линкуется с ней статически. При этом если верно второе, то при собственноручной сборке, я бы ни в коем случае не линковал бы HtmLayout.dll с CRT статически, а слинковал бы её с той же самой CRT динамически, что использую в своём проекте, а именно: msvcr90.dll + манифест бы ей встроил верный.
Могу сам убрать неиспользуемые мной фичи из целевой dll-ки. Часто библиотеки предоставляют такой механизм. Наример boost можно собирать с опциями
--without-math, --without-graph и --without-python, чтобы не компиллить неиспользуемые мной библиотеки. Или Qt можно собрирать с опциями -no-libjpeg, -no-libtiff, -no-libmng, -no-gif и так далее чтобы удалить некоторую функциональность из целевой dll-ки, либо собирать с опциями -system-libjpeg, -system-libtiff, -system-libmng, -system-gif чтобы такую функциональность сохранить, но реализована она будет через системные dll винды, что опять же уменьшит размер целевой dll-ки. Ведь как удобно было бы самому собрать HtmLayout.dll, при этом при сборке указать ключи наподобие: -no-agg, -no-svg и -no-richtext и при этом получить более чем на треть меньший размер HtmLayout.dll. Не правда ли?
Сам решаю упаковывать мне целевую dll с помощью UPX или нет. Лично меня нисколько не смущает размер целевого модуля (который и так будет запакован по самое нихочу в инсталляционном пакете с помощью Solid LZMA), зато смущает то, что упакованная dll-ка будет требовать больше памяти, будет грузиться дольше во время загрузки приложение всилу распаковки модуля, а также такая dll-ка потерят своё свойство разделяемости ибо при сбросе страниц оперативы позже будет подгружаться из файла подкачки, а не из своего родного модуля. Хотя, пардон, я конечно же могу распаковать dll-ку обратно, получив 1,8MB (1925120 bytes) вместо заявленных на сайте 600KB: "Small distribution size: HtmLayout.dll is about 600KB".
Здравствуйте, c-smile, Вы писали: CS>Код местами нетривиальный и сильно специфический. В том смысле что сильно помочь в понимании CS>того что происходит в том или ином случае наличие исходников врядли поможет.
Вот лично мне и не нужно понимать что происходит в недрах HTMLayout.dll, я не собираюсь править/отлаживать исходные коды, мне и смотреть на них не за чем ибо нет практического интереса: как правило, чтобы хорошо разбираться в таких достаточно больших по объёму проектах как HTMLayout, необходимо пройти некую обязательную "фазу накопления знаний", на которую у меня совершенно нет времени, следовательно я даже не пойму ничерта в сорцах HTMLayout. Мне лишь необходимо собрать HTMLayout.dll таким образом как я хочу и слинковать её как я хочу. И в конце концов я соберу именно DLL, слинкуюсь с HTMLayout динамически и честно поставлю её вместе с продуктом. Однако всилу закрытости исходников HTMLayout я лишён подобных удобств. :(
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Rakafon, Вы писали:
R>Могу сам указать с какой CRT и каким образом линковаться. Будет ли эта CRT лежать в msvcrt.dll, в msvcr70.dll, в msvcr80.dll или в msvcr90.dll, или CRT вообще будет находиться в моём модуле, т.к. я слинкую его с CRT статически. Я вот даже не знаю, использует ли HtmLayout.dll С-Runtime, в зависимостях файла нет ссылки на msvcrt.dll, есть только ссылка на kernel32.dll, при этом судя по таблице импорта из kernel32 не импортируются CRT-шные функции, соответственно HtmLayout либо вообще не использует CRT либо линкуется с ней статически. При этом если верно второе, то при собственноручной сборке, я бы ни в коем случае не линковал бы HtmLayout.dll с CRT статически, а слинковал бы её с той же самой CRT динамически, что использую в своём проекте, а именно: msvcr90.dll + манифест бы ей встроил верный.
Это можно решить системой автоматических билдов разных вариантов DLL. У c-smile сейчас этого нет, но мы добавим
R>Ведь как удобно было бы самому собрать HtmLayout.dll, при этом при сборке указать ключи наподобие: -no-agg, -no-svg и -no-richtext и при этом получить более чем на треть меньший размер HtmLayout.dll. Не правда ли?
Большого выигрыша тут не получить, поэтому и заморачиваться особо не стоит.
R>Сам решаю упаковывать мне целевую dll с помощью UPX или нет.
Ну так распакуй. А потом перепакуй каким-нибудь 7zip'ом в инсталляторе.
R>Вот лично мне и не нужно понимать что происходит в недрах HTMLayout.dll, я не собираюсь править/отлаживать исходные коды, мне и смотреть на них не за чем ибо нет практического интереса: как правило, чтобы хорошо разбираться в таких достаточно больших по объёму проектах как HTMLayout, необходимо пройти некую обязательную "фазу накопления знаний", на которую у меня совершенно нет времени, следовательно я даже не пойму ничерта в сорцах HTMLayout. Мне лишь необходимо собрать HTMLayout.dll таким образом как я хочу и слинковать её как я хочу. И в конце концов я соберу именно DLL, слинкуюсь с HTMLayout динамически и честно поставлю её вместе с продуктом. Однако всилу закрытости исходников HTMLayout я лишён подобных удобств.
Именно это можно скоро будет достаточно просто сделать.
Здравствуйте, Cyberax, Вы писали:
C>Большого выигрыша тут не получить, поэтому и заморачиваться особо не стоит.
Судя по сообщению от c-smile (К вопросу о размерах
), то разница между Full Version и Minimal Version составляет 1,470,464 bytes — 999,424 bytes = 471,040 bytes, а это как никак (471,040/1,470,464=0.32) минус треть от размера полной версии. Так что думаю в особых случаях можно и заморочиться.
C>Ну так распакуй. А потом перепакуй каким-нибудь 7zip'ом в инсталляторе.
Ну так я и написал:
... Лично меня нисколько не смущает размер целевого модуля, который и так будет запакован по самое нихочу в инсталляционном пакете с помощью Solid LZMA
... Хотя, пардон, я конечно же могу распаковать dll-ку обратно, получив 1,8MB (1925120 bytes) вместо заявленных на сайте 600KB: "Small distribution size: HtmLayout.dll is about 600KB"
Просто мне кажется не совсем честным пункт на главной странице официального сайта "5. Small distribution size: HtmLayout.dll is about 600KB uncompressed.", в то время как в скачанном SDK HTMLayout.dll весит более 700КБ, будучи при этом запакованной UPX-ом!
C>Именно это можно скоро будет достаточно просто сделать. C>Это можно решить системой автоматических билдов разных вариантов DLL. У c-smile сейчас этого нет, но мы добавим :)
Т.е. я так понимаю вы запустите Cruise Control, который будет собирать разные версии HtmLayout.dll, в том числе слинкованную с различными CRT динамически/статически? VC++6, VC++7 (VS.Net-2003), VC++8 (VS.Net-2005), VC++9 (VS.Net-2008) и VC++10, которая скоро выйдет с поддержкой существующего пока только в draft'ах нового стандарта С++. При этом если слинковать со всеми этими CRT статически и динамически, то получится 10 вариантов DLL. Плюс платформы 32bit и 64bit => 20 штук. А Borland C++ Builder, MinGW, etc.? И вся эта dll-ная кодла будет лежать пожатой UPX-ом в SDK? Зачем весь этот гемор ради следования религиозным догмам типа "ни за что не откроем сорцы даже в режиме read-only". Или вы боитесь, что при их открытии их кто-то банально свистнет, нарушив все права собственности и не будет при этои подобающим образом наказан? Не пойму что такого плохого в том, что пользователи HtmLayout будут иметь возможность собирать HtmLayout.dll на целевой девелоперской тачке с использованием своих инструментов разработки со своей уникальной environment, также, как они это делают в случае использования Boost, Qt, OpenSSL, LibXml2, ZLib, etc.?
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Rakafon, Вы писали:
C>>Большого выигрыша тут не получить, поэтому и заморачиваться особо не стоит. R>Судя по сообщению от c-smile (К вопросу о размерах
), то разница между Full Version и Minimal Version составляет 1,470,464 bytes — 999,424 bytes = 471,040 bytes, а это как никак (471,040/1,470,464=0.32) минус треть от размера полной версии. Так что думаю в особых случаях можно и заморочиться.
100Кб в запакованном виде.
R>... Хотя, пардон, я конечно же могу распаковать dll-ку обратно, получив 1,8MB (1925120 bytes) вместо заявленных на сайте 600KB: "Small distribution size: HtmLayout.dll is about 600KB"[/q]Просто мне кажется не совсем честным пункт на главной странице официального сайта "5. Small distribution size: HtmLayout.dll is about 600KB uncompressed.", в то время как в скачанном SDK HTMLayout.dll весит более 700КБ, будучи при этом запакованной UPX-ом!
Ну а что тебе не нравится-то, я не понимаю?
R>Т.е. я так понимаю вы запустите Cruise Control, который будет собирать разные версии HtmLayout.dll, в том числе слинкованную с различными CRT динамически/статически? VC++6, VC++7 (VS.Net-2003), VC++8 (VS.Net-2005), VC++9 (VS.Net-2008) и VC++10, которая скоро выйдет с поддержкой существующего пока только в draft'ах нового стандарта С++. При этом если слинковать со всеми этими CRT статически и динамически, то получится 10 вариантов DLL. Плюс платформы 32bit и 64bit => 20 штук.
Угу. Только всё ещё хуже будет, когда добавятся Linux и Mac OS X
R>А Borland C++ Builder, MinGW, etc.? И вся эта dll-ная кодла будет лежать пожатой UPX-ом в SDK?
BCB вообще никому не нужен. MinGW будет.
R>Зачем весь этот гемор ради следования религиозным догмам типа "ни за что не откроем сорцы даже в режиме read-only". Или вы боитесь, что при их открытии их кто-то банально свистнет, нарушив все права собственности и не будет при этои подобающим образом наказан?
Это вопросы к c-smile. Он за лицензирование исходников получает деньги, которые идут на поддержку библиотеки. Эта одна причина сама по себе может быть важнее всех твоих доводов.
R>Не пойму что такого плохого в том, что пользователи HtmLayout будут иметь возможность собирать HtmLayout.dll на целевой девелоперской тачке с использованием своих инструментов разработки со своей уникальной environment, также, как они это делают в случае использования Boost, Qt, OpenSSL, LibXml2, ZLib, etc.?
См. выше.
Тем более, что распространение в бинарной форме в виде кучи DLL-ок не так уж и необычно. Скажем, так многие коммерческие 3D-движки распространяются.
Здравствуйте, Cyberax, Вы писали:
R>>А Borland C++ Builder, MinGW, etc.? И вся эта dll-ная кодла будет лежать пожатой UPX-ом в SDK? C>BCB вообще никому не нужен. MinGW будет.
Конечно лучше бы Delphi, но BCB тоже вполне используется у достаточно целевой для HTMLayout аудитории небольших фирм и шараварщиков.
R>Т.е. я так понимаю вы запустите Cruise Control, который будет собирать разные версии HtmLayout.dll, в том числе слинкованную с различными CRT динамически/статически? VC++6, VC++7 (VS.Net-2003), VC++8 (VS.Net-2005), VC++9 (VS.Net-2008) и VC++10, которая скоро выйдет с поддержкой существующего пока только в draft'ах нового стандарта С++. При этом если слинковать со всеми этими CRT статически и динамически, то получится 10 вариантов DLL. Плюс платформы 32bit и 64bit => 20 штук.
А вот тут я не понял нафига все это счастье нужно?
Я вообще не вижу смысла зачем собирать разными компиляторами и RTL.
Здравствуйте, FR, Вы писали:
R>>>А Borland C++ Builder, MinGW, etc.? И вся эта dll-ная кодла будет лежать пожатой UPX-ом в SDK? C>>BCB вообще никому не нужен. MinGW будет. FR>Конечно лучше бы Delphi, но BCB тоже вполне используется у достаточно целевой для HTMLayout аудитории небольших фирм и шараварщиков.
Так никто же не мешает использовать HTMLayout из Delphi. Речь идёт о том, чтобы компилировать HTMLayout им.
Здравствуйте, Rakafon, Вы писали:
C>>Большого выигрыша тут не получить, поэтому и заморачиваться особо не стоит.
R>Так что думаю в особых случаях можно и заморочиться.
Изложи свои особые случаи.
C>>Ну так распакуй. А потом перепакуй каким-нибудь 7zip'ом в инсталляторе. R>Ну так я и написал:
... Лично меня нисколько не смущает размер целевого модуля, который и так будет запакован по самое нихочу в инсталляционном пакете с помощью Solid LZMA
R>... Хотя, пардон, я конечно же могу распаковать dll-ку обратно, получив 1,8MB (1925120 bytes) вместо заявленных на сайте 600KB: "Small distribution size: HtmLayout.dll is about 600KB"
Много воды утекло. Пришлось добавлять PNG.lib (за для поддержки animated PNG) и JPEG.lib.
Потом добавилась AGG, потом пришлось втсраивать полную UNICODE table c PGBA (http://crl.nmsu.edu/~mleisher/ucdata.html)
Выкинуть что-то можно конечно. Но стоит ли та овчинка выделки.
C>>Именно это можно скоро будет достаточно просто сделать. C>>Это можно решить системой автоматических билдов разных вариантов DLL. У c-smile сейчас этого нет, но мы добавим R>Т.е. я так понимаю вы запустите Cruise Control, который будет собирать разные версии HtmLayout.dll, в том числе слинкованную с различными CRT динамически/статически? VC++6, VC++7 (VS.Net-2003), VC++8 (VS.Net-2005), VC++9 (VS.Net-2008) и VC++10, которая скоро выйдет с поддержкой существующего пока только в draft'ах нового стандарта С++. При этом если слинковать со всеми этими CRT статически и динамически, то получится 10 вариантов DLL. Плюс платформы 32bit и 64bit => 20 штук. А Borland C++ Builder, MinGW, etc.? И вся эта dll-ная кодла будет лежать пожатой UPX-ом в SDK? Зачем весь этот гемор ради следования религиозным догмам типа "ни за что не откроем сорцы даже в режиме read-only". Или вы боитесь, что при их открытии их кто-то банально свистнет, нарушив все права собственности и не будет при этои подобающим образом наказан? Не пойму что такого плохого в том, что пользователи HtmLayout будут иметь возможность собирать HtmLayout.dll на целевой девелоперской тачке с использованием своих инструментов разработки со своей уникальной environment, также, как они это делают в случае использования Boost, Qt, OpenSSL, LibXml2, ZLib, etc.?
Открытие исходников стоит денег. Например разработка комплекса лицензий аналогичных Мозилловской MPL стоит в пределах 20тыс USD.
Короче, мне проще открыть их скажем десятку людей а не гадать кто исхитрился скомпилировать очередной
"I have a program called antivirus 2010 that has invaded my computer and the file says it originated at your company. Do you know anything about this program and how I can remove it from my computor."
А так у меня хоть есть шанс вычислить того злыдня.
