Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Orifiel, Вы писали:

O>>Что касается WinForms, то их использование предполагает программирование на VB.NET/C#,
O>>которые хороши для прикладников, но не для системщиков.

VD>Во, как. Дискоссию о Синкулярити читал?
VD>Ну, да ладно. Ответь на несколько вопросов.
VD>Какой смысл ты вкладываешь в термин "системщик" и "системное программирование"?

В термин системное программирование применительно к Винде вкладываю такой смысл:
— программирование драйверов устройств и драйверов файловых систем;
— программирование системных сервисов;
— программирование утилит, реализующих доступ к драйверам посредством таких WinAPI,
как ReadFile, WriteFile и DeviceIoControl;
— работа с системой безопасности Винды на уровне чистого WinAPI (SetFileSecurity,
LsaAddAcountRights, AdjustTokenPrivileges и т.д.);
— работа с CryptoAPI и SmartCardAPI на чистом API;
— использование различных низкоуровневых библиотек (ASPI SDK, PGP SDK, OW32)
для работы с железом, системой, атакже подсистемами безопасности и криптозащиты.

VD>Считаеш ли ты сам себя системщиком?
VD>Что мешает создавть программы с использованием WinForms на Delphi или C++?

Большое количество P-Invoke существоенно снижает быстродействие, к тому же
хваленный .NET Framework есть ни что иное, как COM-сервер (см. 4-е издание книги
Соломона и Русиновича) и так или иначе обращается к низкоуровневому API.

VD>Какие системные вещи созданы на Дельфи или Билдере с применением VCL?

Системщики избегают данных платформ исключительно из стереотипных соображений.
Известно, что Delphi и С++ Builder поддерживают Platform SDK в полном объеме.
Более того, ассемблер от Борланд на порядок круче мелкософтного.
Единственным препятствием, буть может, является отсутствие опций тонкой настройки
компилятора и компоновщика, но в BCB 2006, насколько мне известно, эту проблему решили.

O>>Чем хороша VCL, это тем, что
O>>я могу визуально проектировать GUI и одновременно вызывать любую WinAPI без переходников,
O>>включая Native WinNT API.

VD>А в чем, по-твоему, заключается трудность с вызовом любых WinAPI-функций из управляемых языков?

Частые переходы managed/unmanaged негативно сказываются на быстродействии и приводят
к путанице в чтении такого кода.

Здравствуйте, Orifiel, Вы писали:

O>Известно, что Delphi и С++ Builder поддерживают Platform SDK в полном объеме.


А почему тогда на форумах разработчики на Delphi постоянно спрашивают где взять описания какой-нибудь структуры или константы?

Здравствуйте, Orifiel, Вы писали:

O>Известно, что Delphi и С++ Builder поддерживают Platform SDK в полном объеме.

и где лежит текущий PSDK (win 2003 sp1) для delphi?

VladD2 wrote:

> C>Поверьте, я пытался сделать тоже самое на ATL/WTL. Через месяц бросил —
> C>нужно было писать оооочень много всего.
> Я все это делал на ATL. Может встраеваемый догумент и проще сделать на
> МФЦ, но при шаге в право в лево начинашь жалеть, что с ним связался.

Да, есть такая проблема. Хотя MFC достаточно гибкая — обычно можно
переписать проблемные функции в MFC

> C>MFC это бы не помешало, но ей можно простить в силу преклонного
> возраста
> Жлабэйсик по страше будет, но что-то у него таких проблем нет.

Ну как бы и встраиваемые документы на нем не делают Вообще, MFC
следовало бы назвать MEF (Microsoft Editors Framework) — так как она
ориентированая на создание разных редакторов. Это у нее получается очень
неплохо, а вот все остальное....

> C>Ага, и как в этом простом мире сделать так, чтобы в документ Word'а
> C>можно было вставить мой объект?
> Бросить контрол на форму. Например, прекрасно работает контрол
> банального IE.

Нет, вы не поняли. Чтобы _мое_ приложение работало внутри документа
Word'а. Наоборот каждый дурак умеет

> C> Вообще убил бы MS, за 6 лет так и не
> C>удосужилсь сделать замену для OLE2, хотя сами используют его на полную
> C>катушку.
> Ну, в управляемых средах ничего и делать не нужно. Есть сборки, есть
> контролы, есть дизайнеры. В общем, все есть. Осталось только чтобы все
> прилоежения стали управляемыми и предоставляли своей функционал в виде
> контрола.

Нет. Придется все равно делать Compound Documents, протоколы
согласования менюшек/тулбаров и размеров окон, трансляцию акселераторов
и т.п.

В общем получится то, что сейчас есть, но managed. Это было бы удобнее,
но в МС не хотят переделывать то, что и так работает.

> C>Это ответ на рекламу VCL из прошлого века
> Ну, все же VCL хоть компонентный фрэйворк. Хотя конечно явно
> устаревший. Ну, да сам Борланд давно понял откуда ветер дует. Это
> просто его поклонники долго раскачиваются.

Ага.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Odi$$ey, Вы писали:


OE>и где лежит текущий PSDK (win 2003 sp1) для delphi?
здесь

Здравствуйте, Orifiel, Вы писали:

VD>>Какой смысл ты вкладываешь в термин "системщик" и "системное программирование"?

O>В термин системное программирование применительно к Винде вкладываю такой смысл:
O>- программирование драйверов устройств и драйверов файловых систем;

Тут я с тобой соглашусь. Действительно создание драйвера явно задача для системного программиста.
И это единственная из перечисленных задачь которую пока что нельзя решить на управляемом языке вроде Шарпа. Почему "пока что"? Да на горизонте уже маячит Синкулярити гди и это уже возможно.

Ну, а все это:
O>- программирование системных сервисов;
O>- программирование утилит, реализующих доступ к драйверам посредством таких WinAPI,
O>как ReadFile, WriteFile и DeviceIoControl;
O>- работа с системой безопасности Винды на уровне чистого WinAPI (SetFileSecurity,
O>LsaAddAcountRights, AdjustTokenPrivileges и т.д.);
O>- работа с CryptoAPI и SmartCardAPI на чистом API;
O>- использование различных низкоуровневых библиотек (ASPI SDK, PGP SDK, OW32)
O>для работы с железом, системой, атакже подсистемами безопасности и криптозащиты.

Без проблем реализуется даже на Жлабэйсике, не то что на C#-е. Так что получается, что если рассматритвать "системное программирование" с твоей точки зрения, то 99% случаев его применения прекрасно проходят на управляетмых языках.

Кстати... А почему ты все время подчеркивашь "на чистом API"? Что же если я решаю одну и ту же задачу вроде шифрования открытым ключем с использованием алгоритма Х, то получаю в случае использования "голого API" системное ПО, а воспользовавшись классом написанным на C# сразу получаю прикладное решение?

Я не даром задал тебе этот вопрос. Дело в том, что ты как и многие другие, не верно воспринимашь этот термин. Термин "систеный" в случае применения его к ПО, его разработке, программистам и т.е. означет "не прикладной". То есть любая задача/программа/пработа результатами которой не пользуется конечный потребитель (юзер) является системной. Так написание контрола уже можно считать системной задачей. В общем-то термин "системный" можно трактовать широко, например, "системное ОП" можно воспринимать как "ПО для нужд ОС", но это уже детали. В любом случае твое восприятие явно неверное.

Задачи которые ты перечислил выше, за исключением создания драйверов все как одни могут быть прикладными. Тот же сервис может оказаться срвисом генерирующим отчеты для системы автоматизация предриятия (вещи сугубо прикладной). Ну, и естественно любая "низкоуровневая" библиотека тоже может использоваться в пркладных нуждах.

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

VD>>Считаеш ли ты сам себя системщиком?

На этот вопрос ты, кстати, не ответил.

VD>>Что мешает создавть программы с использованием WinForms на Delphi или C++?

O>Большое количество P-Invoke существоенно снижает быстродействие,

Ты проверял? Или повторяшь заученную догму? Я вот проверял. И могу тебе сказать, что в 99% случаев замедление ты не заметишь и в микроскоп. Дело в том, что большинство Функций АПИ которые нужно вызвать являются сами по себе очень не быстрыми. Например, по сравнению с временим шифрования время затрачиваемое на маршалинг параметров прочто ничтожно. Ну, а функции вроде IntersectRect и OffsetRect легко реализуются в управляемом коде и как правило уже имеют аналоги. Так что аргумент про P-Invoke сильно надуман.

O> к тому же
O>хваленный .NET Framework есть ни что иное, как COM-сервер (см. 4-е издание книги
O>Соломона и Русиновича) и так или иначе обращается к низкоуровневому API.

Когда читашь книги таких авторов как Русиновичь нужно уметь правильно воспринимать сказанное. Нужно понимать, что это люди пришущие о глубинных вопросах ОС и т.п. Воспринимать их слова буквально просто бессмысленно. Думаю, если ты прочтешь их слова внимательно, то поймшь, что речь там идето о том, что ядро CLR запускается как КОМ-сервер и управляется через КОМ-интерфейсы. Вот только какое это имеет отношение к самому ЦЛР? Он то является Объеязыковой Средой Исполения и внутри себя чихать хотел на КОМ. Да и КОМ-ма там ровно IUnclown. Погляди Ротор. Он перенесен на Free BSB, Mak OS и т.п. В них КОМ-мом и не пахнет и тем неменее все что нужно от кома там реализовано десятком строк кода.

К тому же есть реализации CLI не имеющие вообще никакого отношения к КОМ-у — это Моно и ГНУ-Дотнет.

VD>>Какие системные вещи созданы на Дельфи или Билдере с применением VCL?

O>Системщики избегают данных платформ исключительно из стереотипных соображений.

А не кажется ли тебе, что в днном случае все твои слова о дотнете есть точно такой же стериотип?

O>Известно, что Delphi и С++ Builder поддерживают Platform SDK в полном объеме.

Что значит поддерживаются? Можно вызвать функцию? Есть конверторы заголовочных файлов которые никогда не ошибаются? Есть полноценный пакет с документацией и оддержкой?

O>Более того, ассемблер от Борланд на порядок круче мелкософтного.

Что то ты путашь. Насколько я знаю, народ сильно мучается от того, что встроенный в Дельфи ассемблер не поддерживает SSE/SSE2-инструкции. А вот в VC вроде как они очень даже поддерживаются. Вот только использование ассемблера в переносимых ОС даже в драйверах нельзя называть разумным решением. К тому еж никто не мешает использовать врешний ассемблер.

O>Единственным препятствием, буть может, является отсутствие опций тонкой настройки
O>компилятора и компоновщика, но в BCB 2006, насколько мне известно, эту проблему решили.

Клавное препятствие заключается в том, что для любой серьезной задачи вроде разработки драйверов требуеется добротный фрэймворк, примеры кода и море документации. Вот как раз их то нет и никогда не будет ни для Дельфи, ни даже для Билдера. Ну, а работая на уровне PSDK проще применять тот же VC, так как они друг под друга заточены.

VD>>А в чем, по-твоему, заключается трудность с вызовом любых WinAPI-функций из управляемых языков?

O>Частые переходы managed/unmanaged негативно сказываются на быстродействии и приводят
O>к путанице в чтении такого кода.

Ну, про первое я уже сказал. Это миф. А что до путанницы, то все как раз с точностью до наоборот. При импорте функций через PInvoke можно описать функцию намного более удобным образом устранив такие нелепости как приведения типов. К тому же прямое использование АПИ-функций в ООЯ является откровенным ламероством. Грамотные программисты даже программируя на С++ стараются создать высокоуровневые обертки защищающие их пользователей от ошибок (как то неверные приведения типов) и упрощающие работу с ними. Так что читается такой код намного лучше. Вот тебе простой пример Перебор файлов с использованием FindFirstFile/FindNextFile и

Автор: VladD2
Дата: 27.09.05

. Попробуй попользоваться этим хэлпером и сравни с ручным использованием FindFirstFile/FindNextFile.

Здравствуйте, VladD2, Вы писали:

VD>Что то ты путашь. Насколько я знаю, народ сильно мучается от того, что встроенный в Дельфи ассемблер не >поддерживает SSE/SSE2-инструкции. А вот в VC вроде как они очень даже поддерживаются.

Это заблуждение.
Delphi6 inline assembler —
Supports all instructions found in the Intel Pentium III, Intel MMX extensions, Streaming SIMD Extensions (SSE), and the AMD Athlon (including 3D Now!)
в Delphi 2005 добавленно —
Supports for Intel Pentium IV SSE3 and SSE2 Instructions Op Codes and Data Types

Здравствуйте, Sinclair, Вы писали:

S>Ок, я был неправ. Мне казалось, что в подавлении перерисовки ListView без использования WM_SETREDRAW делать нечего. И, насколько я помню, этот мессадж работал не для всех контролов, так что приходилось делать LockWindowUpdate. И он тоже глючил в разных ситуациях. Но это все было лет шесть назад, поэтому я мог забыть подробности или просто глючить тогда по неопытности.

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

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

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, anton_t, Вы писали:

CC>>>В сравнении с VS6 VS2003 периодически еле ползает. P4 640 + 1G DDR2. Только не говорите что мало...

_>>Ну проц явно слабоват.
CC>Чутка очепятался. Не 640 а 630
CC>Впрочем P4 630 = P4 3Gz, 2Mb cache, EMT64, 800 MHz FSB
CC>Или ты шмайлик забыл поставить?

что-то не то с компом, у меня VC++ 7.1 + визуал асист на атлоне 1.7 с 512 мозгов бегает вообще без тормозов.

Здравствуйте, Cyberax, Вы писали:

С>Нет, вы не поняли. Чтобы _мое_ приложение работало внутри документа
C>Word'а. Наоборот каждый дурак умеет
Это очень легко делается при помощи шарпа. На Днях разработчика показывали как.

XilenteZ wrote:

> С>Нет, вы не поняли. Чтобы _мое_ приложение работало внутри документа
> C>Word'а. Наоборот каждый дурак умеет
> Это очень легко делается при помощи шарпа. На Днях разработчика
> показывали как.

Я не говорю про макросы через VSA, а про настоящее встраивание в
документ (aka Embedding). Пока что такое невозможно.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Cyberax, Вы писали:

C>>Swing — это вообще мой любимый GUI, архитектура там самая лучшая из
C>>всех, что я видел. Только вот Sun его как-то совсем не развивает, он
C>>фактически остался на уровне 2002 года. Вместо того, чтобы выкинуть
C>>#%&^$( AWT и переписать Swing _нормально_, они до сих пор занимаются
C>>эмуляцией Windows GUI.

VD>Согасен, что архитектурно Свинг неплох, но реализован хреновенько.

C>>WinForms мне не очень нравятся архитектурно — там нет полноценного MVC.
C>>Хотя layout'ы уже добавили

VD>Не скажи. Просто в WinForms много оберток над Вынь-контролами. Родные компоненты в нем очень даже неплохо спроектированы. Ну, и опять же реализация очень неплохая.

VD>ЗЫ

VD>В любом, случаи это куда лучше чем МФЦ, ВТЛ и ГДИ вместе взятые.

"Шашечки или ехать?"

Здравствуйте, vlad_gri, Вы писали:

_>Это заблуждение.
_>Delphi6 inline assembler -
_>Supports all instructions found in the Intel Pentium III, Intel MMX extensions, Streaming SIMD Extensions (SSE), and the AMD Athlon (including 3D Now!)
_>в Delphi 2005 добавленно -
_>Supports for Intel Pentium IV SSE3 and SSE2 Instructions Op Codes and Data Types

Рад за ний. Видимо это была информация о версиях до 2005. В прочем проблем с ассемблером в VC я тоже особо не замечал, как в прочем и не замечал тех ктого на сегодня это интересует.

Здравствуйте, c-smile, Вы писали:

VD>>В любом, случаи это куда лучше чем МФЦ, ВТЛ и ГДИ вместе взятые.

CS>"Шашечки или ехать?"

Ехать. Потому говорю.

ЗЫ

Не оверквоть, так плиз.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, vlad_gri, Вы писали:

_>>Это заблуждение.
_>>Delphi6 inline assembler -
_>>Supports all instructions found in the Intel Pentium III, Intel MMX extensions, Streaming SIMD Extensions (SSE), and the AMD Athlon (including 3D Now!)
_>>в Delphi 2005 добавленно -
_>>Supports for Intel Pentium IV SSE3 and SSE2 Instructions Op Codes and Data Types

VD>Рад за ний. Видимо это была информация о версиях до 2005.
> В прочем проблем с ассемблером в VC я тоже особо не замечал, как в прочем и не замечал тех ктого на сегодня это >интересует.
Это было до delphi6. (до 1991 г.) К чему бы это? Почему не раньше?
в D2005 добавили только SSE3.

Здравствуйте, cencio, Вы писали:

C>что-то не то с компом, у меня VC++ 7.1 + визуал асист на атлоне 1.7 с 512 мозгов бегает вообще без тормозов.
Думаю что скорее не с самим компом а с набором софта который там понаставлен...
Впрочем если в VC7 создать проектик из 5-10 файлов то тормозов тоже не наблюдается
А вот на текущем проекте непонятные тормозюки на ровном месте быват, быват...
Впрочем до того как проект перекинули на 7-ю сюху он был под 6-й. Так он грузился долго но работал потом без тормозов.
А тут грузится умеренно но в процессе работы может задуматься.
особенно часто выезжающие окошки сами обратно заезжать не спешат. т.е. когда такому окошку (solution explorer например) надо заехать обратно появляются тормоза у IDE