Прошу простить за офтопик, но где еще спросить если не здесь?
Я тут для собственных нужд затеял разработку библиотеки компонентов (только WinAPI).
Конешно не все сразу. Для начала CMyStatusBar. Смысл то в том, что в результате удобства будет не меньше чем у VCL (как насчет MFC не знаю, ибо не знаю я ее), а размер проги будет измеряться десятками килобайт а не сотнями или тысячами, как это щас принято, почему-то.
Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком?
Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К
Тагды посоветуйте хороший паковальщик.
Ассемблерщик я, ассемблерщик…
С уважением, Бадян.
В те далекие времена, когда байты были еще битами...
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Здравствуйте уважаемые господа.
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
А чем WTL не устраивает? Если не использовать CString, который CRT тянет то размеры получаються минимальны. Шаблоны минимизируют размеры выходного кода. Точнее грамотное их использование. Ты предлогаешь что то новое?
Здравствуйте Бадян, Вы писали:
Б>Я тут для собственных нужд затеял разработку библиотеки компонентов (только WinAPI).
Я глубоко солидарен с тобой, а потому приглашаю посетить мой сайт: http://cprime.hypermart.net
Я тоже не люблю MFC и тоже предпочитаю чистый API. Предлагаю сотрудничество. Если хочешь создавать подобные компоненты, у меня есть кое-какие идеи, подробности почтой.
Б>Конешно не все сразу. Для начала CMyStatusBar.
Посмотри у меня на сайте. Этот StatusBar (как впрочем и кое-что еще) уже реализован. Исходники выложены.
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
Насчет ATL/WTL. Это гораздо лучше (в смысле минимализации и оптимальности кода), чем MFC. К тому же ATL/WTL компоненты довольно легко встраивать в приложения, написанные на чистом API. Но есть и свои недостатки (не буду о них — это слишком долго, да и для многих неубедительно).
Б>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder?
Это (IMHO) не лучший вариант. Не даром на западе дельфисты не ценятся.
Мне никогда не нравилась MFC. (c) Charles Petzold
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
а вот кто бы мне объяснил, почему это из двух приложений с одинаковой функциональностью приложение MFC получится больше чем на чистом API В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
Re[2]: Есть ли смысл в библ. компонентов на чистом API?
O$>Здравствуйте Бадян, Вы писали:
Б>>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
O$>а вот кто бы мне объяснил, почему это из двух приложений с одинаковой функциональностью приложение MFC получится больше чем на чистом API В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
А посмотри сколько будет весить сама mfcXX.dll — около 1Mb.
Попытаюсь угадать следующий вопрос — так она же везде стоит?
Ответ: нет не везде, а если стоит, то может быть не та версия, так что ее придется прилогать к своему exe. И что получается...
Re[3]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте dupamid, Вы писали:
Б>>>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
O$>>а вот кто бы мне объяснил, почему это из двух приложений с одинаковой функциональностью приложение MFC получится больше чем на чистом API В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
D>А посмотри сколько будет весить сама mfcXX.dll — около 1Mb. D>Попытаюсь угадать следующий вопрос — так она же везде стоит? D>Ответ: нет не везде, а если стоит, то может быть не та версия, так что ее придется прилогать к своему exe. И что получается...
Ну, давай посмотрим На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
Аналогичная ситуация с местом, занимаемым на диске.
Так что недостатков у MFC много, вот только про размер — ненадо, а?
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком? Б>Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К Б>Тагды посоветуйте хороший паковальщик.
кстати о паковальщиках — ради сомнительного удовольствия в виде экономии места на диске ждать пока программа распакуется в памяти в те же "мегатонны"
Re[4]: Есть ли смысл в библ. компонентов на чистом API?
O$>Здравствуйте dupamid, Вы писали:
Б>>>>Господа, не смейтесь, ибо это не смешно. Судите сами VCL, MFC, ATL/WTL утвердили стандарт на огромнейшие приложения. Тогда как на API минимальная прога весит чуть более килобайта. А достаточно функционально наполненная может уместиться и в 20К.
O$>>>а вот кто бы мне объяснил, почему это из двух приложений с одинаковой функциональностью приложение MFC получится больше чем на чистом API В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
D>>А посмотри сколько будет весить сама mfcXX.dll — около 1Mb. D>>Попытаюсь угадать следующий вопрос — так она же везде стоит? D>>Ответ: нет не везде, а если стоит, то может быть не та версия, так что ее придется прилогать к своему exe. И что получается...
O$>Ну, давай посмотрим На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
O$>Аналогичная ситуация с местом, занимаемым на диске.
O$>Так что недостатков у MFC много, вот только про размер — ненадо, а?
Насколько я понял, здесь речь шла об ОДНОЙ программе, а не о пакете программ.
Re[5]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте dupamid, Вы писали:
D>Насколько я понял, здесь речь шла об ОДНОЙ программе, а не о пакете программ.
Странно, а я понял что уважаемый Бадян хочет стать автором библиотеки, которою как минимум будет использовать он во всех своих программах, а как максимум — все программисты всего мира во всех своих программах.
Re[2]: Есть ли смысл в библ. компонентов на чистом API?
O$>Здравствуйте Бадян, Вы писали:
Б>>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком? Б>>Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К Б>>Тагды посоветуйте хороший паковальщик.
O$>кстати о паковальщиках — ради сомнительного удовольствия в виде экономии места на диске ждать пока программа распакуется в памяти в те же "мегатонны"
Нуу... теория в том, что пока с диска читаются 50 метров екзешника (со скоростью 5 м/сек), простаивают 2ГГц лошадиных сил.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Sinclair, Вы писали:
S>Здравствуйте Odi$$ey, Вы писали:
O$>>Здравствуйте Бадян, Вы писали:
Б>>>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком? Б>>>Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К Б>>>Тагды посоветуйте хороший паковальщик.
O$>>кстати о паковальщиках — ради сомнительного удовольствия в виде экономии места на диске ждать пока программа распакуется в памяти в те же "мегатонны" :no: S>Нуу... теория в том, что пока с диска читаются 50 метров екзешника (со скоростью 5 м/сек), простаивают 2ГГц лошадиных сил.
А ты диск пожми :) А то ведь два экземпляра пятидесятиметрового пакованного экзешника займут 100 метров памяти, в то время как непакованного — немногим более 50.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[4]: Есть ли смысл в библ. компонентов на чистом API?
O$>Здравствуйте dupamid, Вы писали:
O$>Ну, давай посмотрим На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
... А потом клиент ставит какой-нить драйвер сканера с др. версией MFC для интерфейса
и все остальное валится нафиг.
У меня была такая ж: один драйвер хотел одну версию MFC,
а другой (COM-объект) — другую. Очень весело.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re[5]: Есть ли смысл в библ. компонентов на чистом API?
O$>>Ну, давай посмотрим На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
М>... А потом клиент ставит какой-нить драйвер сканера с др. версией MFC для интерфейса М>и все остальное валится нафиг. М>У меня была такая ж: один драйвер хотел одну версию MFC, М>а другой (COM-объект) — другую. Очень весело.
разные версии mfc42.dll ? а в чем выражалось "хотение"? (просто не видел такого никогда)
Re[6]: Есть ли смысл в библ. компонентов на чистом API?
O$>разные версии mfc42.dll ? а в чем выражалось "хотение"? (просто не видел такого никогда)
Это было давно. Помню только, что с одной стороны были Oracle Objects for OLE,
с другой — практически все остальное.
К сожалению, не помню точной версии Objects. У них там сложно с этим в Oracle :)
Причем нужная версия DLL не подходила ни с VC 4.2, ни с 5.0.
Откуда они ее взяли — неизвестно. Возможно — какая-то ранняя версия.
А шестого VC тогда еще не было.
Похоже ситуация с версией уже устаканилась. Я имею в виду — для всего, что
выпущено за последние 2-3 года.
Но что конфликт версий реально возможен — это факт. Для софта, выпуска
в районе где-то 96-97 года.
Вообще, у Oracle с MS была постоянная борьба за виндовозного клиента.
С каждой версией винды, VB или Office — M$ чего-там подшаманит — и
у оракловского клиента глюки.
То есть перед установкой нужно всегда внимательно читать доку — на чем его тестировали :).
Заметим, что M$ вовсю рвется на рынок вторичного софта.
А это значит, что под всякими "благовидными" предлогами будет и дальше
постоянно ставить палки в колеса конкурентам.
В том числе и разработчикам на VC.
...А отсюда наливаем, когда рецепт написан совсем неразборчиво...
Re: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте Бадян, Вы писали:
Б>Или не парить себе (и Вам) мозги и писать на VCL (забить на старый-добрый VisualC++), перейти на Delpi/C++Builder? А мегатонные приложения паковать каким-нить екзепаком? Б>Дык, сомневаюсь я, что 500 килобайтовую приблуду можна запаковать в 20К
А ведь есть KOL...? Если не в кусе — это замена VCL. Позволяет полномасшатбное приложение сделать весом в 20к....
Б>Тагды посоветуйте хороший паковальщик.
Паковальщики — это страшный BAD. Крис Касперски очень хорошо это расписал.
Re[2]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте DeusNoxious, Вы писали:
DN>А ведь есть KOL...? Если не в кусе — это замена VCL. Позволяет полномасшатбное приложение сделать весом в 20к....
Недавно узнал об этом KOL, заинтересовался, скачал примерчик — просмотрщик bmp-ек. 15кб exe. Протащился Взял WTL, сваял тоже самое, получилось 15 кб exe Только потом оказалось, что тот exe-шник пакованный был
Б>>Тагды посоветуйте хороший паковальщик. DN>Паковальщики — это страшный BAD. Крис Касперски очень хорошо это расписал.
А где можно почитать? А то я и так знаю, что это плохо, а конкретных аргументов/тестов нет.
Как все запущенно...
Re[3]: Есть ли смысл в библ. компонентов на чистом API?
Здравствуйте OLEGus1, Вы писали:
D>>А посмотри сколько будет весить сама mfcXX.dll — около 1Mb.
OLEG>В таких случаях советую прилинковывать bcgjkmpetvst dll. получаются программы < 100 k
Очень интересно, а это за такая "bcgjkmpetvst dll"???
Это шутка, или Вы не читали предыдущих сообщений?
ICQ#: 198114726
В MFC-приложении — только функциональность и вызовы функций из mfcXX.dll, а проге на winapi или wtl — ВСЁ.
На сайте фирмы, где я работаю, лежит среди прочего пара десятков MFC-программ c динамической линковкой MFC и нужная версия MFC42.dll. Клиент, у которого не та версия mfc42.dll 1 раз качает ее, а дальше только маленькие (относительно WTL и WINAPI) собственно программы. Тоже при обновлениях.
