Разработчики предпочитают новой Windows Vista старую добрую XP

бред... можно создавать кроссплатформенные приложения, которые и на телефоне будут работать, и при этом будут писаться на яве, С++ или питоне
если написать обычное приложение под висту - то будет охвачен маленький рынок и потом выйдет вин7 и приложение прийдётся сильно допиливать или вообще переписывать. под ХП - устареет через полтора года и прийдётся создавать несколько версий под разные ОС и притом вручную, под вин7 сейчас пока вообще писать нельзя, а когда она будет популярна - неизвестно. Под МАК - маленький рынок и на Россию китай и.т.д. рассчитывать нельзя. приложение, написанное используя Qt 4.4 будет родным, для любой ОС от солярис и линукс до винХП и WinCE и MAC

Мне вообще не очень понятно , что значит приложение для WinXP или Vista ... Сам программист и имхо большинство программ пишется так чтобы работало и на ХП и на Виста и в идеале даже на вин98 .. а тот кто пишет только для Хп или только для висты недопрограммист какой-то )))

Loki1368, тут возможны два варианта. Первый - корявые программы, написанные так, что им требуются админские права даже когда они им реально не нужны (например, потому что им позарез нужно зачем-то сохранять настройки в каталог программы а не в профиль юзера) и тому подобные несовместимости, которые в висте просто грубо обрезаются более жесткой политикой безопасности. Второй - программы написаны с использованием новых возможностей API висты (коих ОЧЕНЬ много и они действительно ОЧЕНЬ полезные, о чем к сожалению никто не знает не смотря на тонны инфы в инете, и оченивают ось в основном субъективно по интерфейсу), которые, естественно, не будут доступны на ХР. Тоже самое касается и разницы между другими версиями ОС, вроде XP vs 2000.

Loki1368, да, sich прав, я бы ещё добавил, что в данном контексте, возможно, также имелось ввиду наличие/отсутствие тестирования под определёнными ОС - например, девелопер сидит в ХР и пишет прогу, проверяя её работоспособность исключительно в ХР (ну, ленивый девелопер попался). на самом деле давно пора втирать всем (особенно начинающим) программистам, что с самого начала надо стараться привыкать писать кроссплатформенные приложения. причём чем более кроссплатформенные, тем лучше =) вне зависимости от целей и назначений этих самых приложений - т.е. пытаться заносить это именно в привычку.

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

всякие явы это для ленивых.

что до этого исследования - то явно видно, что чистой воды фейк.

прикладное по, наиболее распространённое по, не может быть ориентированным под xp, висту или какую-нибудь другую версию windows. окошко с кнопочкой, при нажатии которой будет выдаваться сообщение hello world! будет работать одинаково под любой версией windows (ну по крайней мере 5.0+). будь оно написано на нативном c++, борландовских vcl'ях или .net...

прикладное по, наиболее распространённое по, не может быть ориентированным под xp, висту или какую-нибудь другую версию windows

Прикладное ПО, которое хранит все данные в Program Files - ориентировано на ХР, потому что в висте такое кривое приложение будет глючить.
Прикладное ПО, использующее DirectX 10 - ориентировано на висту, потому что в XP нет никакого DirectX 10.

вот ещё ни одна кросс платформа не может похвастаться удобным, качественным, красивым и лёгким в строении интерфейсом

Практически любая .NET-программа.

всякие явы это для ленивых

А для не-ленивых - всякие C с прямой работой с памятью, чтобы месяц отлавливать баг, который при использовании нормального высокоуровневого языка просто не возник бы.
Конечно, не-ленивые занимаются не делом (написанием своей программы), а изобретением велосипеда.
Самые не-ленивые, наверное, даже никакие Qt/Gtk не используют, а сами окошки рисуют. Совсем не-ленивые рисуют их прямо в памяти видеокарты, а не через X.
Знаете, я лучше буду пользоваться приложением, написанным на .NET и красиво выглядящим или на Java и не совсем красиво выглядящим, чем на C (или ассемблере) и нерабочим.

Второй - программы написаны с использованием новых возможностей API висты (коих ОЧЕНЬ много

Не так уж их и много, этих изменений: [url]http://msdn.microsoft.com/en-us/library/aa383874(VS.85).aspx,[/url] и большая часть их них - действительно новый функционал (вроде транзакций в NTFS), если разработчик его использует, то он уж наверняка знает, что это будет работать только в висте.
Да, и ещё - если разработчик их использует, то они действительно нужны (иначе он бы от них отказался в пользу совместимости с XP), а это уже - очень специфичное ПО.

Просто уже любой вменяемый пользователь, не говоря о разработчиках понимает, что виста - тупиковая и крайне неудачная ветвь эволюции операционных систем. Даже до микрософта это дошло. И зачем разработчик будет тратить свое время и силы на написание программ для системы, которая через год-два исчезнет со сцены как страшный сон?
Господа, признайтесь сами себе, что вы столько лет затаив дыхание ожидали шедевра, а дождались г.. на палочке, а теперь чтобы не выглядеть дураками рассказываете всем и каждому, какая виста замечательная и офигительная. Раскройте глазки, снимите шоры. Блин, детский сад какой-то, ей богу.

Absx32, это полный бред, ничто никуда не исчезнет, система прибавляет в функциональности и возможностях, как для пользователя, так и для разработчика. ХР в свое время тоже многое привнесла, и что, куда-то она делась? все ее возможности сохранились и перешли в висту, и все просто писают кипятком от ХР, хотя 5 лет назад плевались, как счас от висты.
Я лично затаив дыхание ожидал не шедевра, а существенно усовершенствованную ось, и я получил то, чего ожидал. Виста действительно надежная, безопасная и функциональная ось, хотя и есть куда дальше ее улучшать.
Как итог, хочу выразить мнение, что тут не все понимают что такое программирование и куда в этом деле "тратятся силы и время"

penartur, +1
согласен с sich, то, какой бы охаиваемой виста не была, но то что появилось нового в ней на уровне API всё равно уже никуда не денется. Тем более я не понимаю, ЗАЧЕМ сейчас что-то писать на сях, когда есть фреймфорк. Особенно с появлением linq'a и других нововведений 3.5 версии эта платформа становится неимоверно удобной. Я стал писать на ней еще с бета версий продакш проекты, которые сейчас уже неплохо прошли испытания (я работаю в угольной промышленности). Кроссплатформенность огромная. Учитывая моно для линукса, даже не надо делать отдельные дистрибутивы.
Согласен, геймдевелоперство, и др низкоуровневый железный функционал не берём, там без вопросов, но и то, даже там логичнее использовать смешанные языки, так как шарп неплохо взаимодействует с сями.
И только не надо опять про производительность... не новую же superPI пишем чаще всего...

Согласен, геймдевелоперство, и др низкоуровневый железный функционал не берём

Точнее,
1) Драйвера для железа
2) Софт, который очень требователен к процессору.
Первое - потому что там по-другому, насколько я понимаю, просто никак; второе - потому что там даже 10% потеря производительности будет очень чувствительной

Ну и, конечно, было бы очень глупо говорить "о, круто, какая удобная вещь - .NET, давайте-ка сейчас вместо того, чтобы улучшать свой софт, потратим пару лет и перепишем его на .NET". Поэтому, в большинстве случаев, новые версии уже существующего софта будут выходить на тех же языках, на которых они были исходно (за исключением тех редких случаев, когда на .NET-языки можно переходить постепенно).
А новый софт - да, имеет смысл писать только на .NET/Java

Особенно с появлением linq'a и других нововведений 3.5 версии эта платформа становится неимоверно удобной... Кроссплатформенность огромная. Учитывая моно для линукса

Моно же не полностью имплементит даже 2.0, о каких нововведениях 3.5 может идти речь? ;)

Есть еще такие кадры, которые не переходят на Висту из принципа.
А вообще изменения в Висте для прогеров огромные, только не всегда используются, да и не всегда они нужны.

.NET не под windows не бывает

.NET не под windows не бывает

<- Хахахахахаха!!!! Ржунимагу, а земля плоская

penartur, ну да, моно конечно тока 2.0, но по-моему уже всё таки полностью )) А так дело времени... Надеюсь и до имплементации линка скоро доберутся... удобная штука, хоть и тормозная местами ))
Достаточно посмотреть какими темпами МС внедряет силверлайт... в том числе и в линукс...

К сожалению да, старый софт никто переписывать не будет на шарпе... Даже у самой МС не получилось, вспоминая лонгхорн ))))))
А учитывая, что большинство прог, которые тока можно придумать, уже написано... то процесс будет медленным.
Но как тут уже недавно отмечали... Политика МС по постепенному отводу разработчиков от использования WinAPI напрямую сохранится и в будущем тока скорее всего усилится. Рано или поздно софт устареет совсем безнадёжно и проще будет переписать.

@penartur
это конечно интересно, но прикладного по на dx10 очень мало. то есть почти нет. сама по себе папка program files не несёт какой-либо проблемы.
.net же не совсем таки уж и кроссплатформа. моно - третье сторонний проект сильно ограниченный в возможностях. кстати если принимать во внимание 3-сторонние разработки, то WinAPI тоже кроссплатформа благодоря wine )))) но дело не в этом.

по нативностью всё же подразумевается не низкоуровневые средства разработки, а системный api.

моно - третье сторонний проект сильно ограниченный в возможностях

Не совсем тертьесторонний - .Net хоть и разработан Майкрософтом, является открытым стандартом, специально созданным чтобы было возможно реализовать дотнет на разных платформах силами других разработчиков. Так что моно хоть и не дотягиевает по качеству до майкрософтовой реализации, по сути является таким же "первосторонним" как майкрософтовый. А вот wine - как раз яркий пример именно третьесторонней разработки, сделанной не по стандартам, а просто содранный "как есть" (что, конечно, не приуменьшает его полезности). Кстати, недавно мона на 100 процентов покрыла винформы и, кажется, все основные библиотеки 2.0.

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

сама по себе папка program files не несёт какой-либо проблемы

Несёт.
Если чьё-то приложение что-то пишет в папку program files - то вы получаете странные глюки, если запускаете программу в обоих режимах - и стандартом, и "run as administrator".

Кстати, недавно мона на 100 процентов покрыла винформы и, кажется, все основные библиотеки 2.0.

Да? Здорово, буду знать.

моно - третье сторонний проект сильно ограниченный в возможностях. кстати если принимать во внимание 3-сторонние разработки, то WinAPI тоже кроссплатформа благодоря wine )))) но дело не в этом

Вы не видите разницы между:
1) Открытым задокументированным стандартом всех возможностей, всего функционала платформы .NET - садись и реализуй для любой платформы, и
2) Закрытой платформой, которая совершенно неизвестно, как работает, и как должна работать - когда, по сути, приходится заниматься обратной разборкой, чтобы понять, что там внутри и что оно должно делать?
Если не видите - то посмотрите на сроки разработки, может быть, это вам о чём-нибудь скажет.
Моно - меньше четырёх лет, полная реализация (если тут не врут) .NET Framework 1.0, 1.1, 2.0; приложения, написанные для этих версий .NET Framework и не использующие посторонние библиотеки, должны запускаться на моно без каких-либо модификаций, с полной функциональностью и без проблем.
Wine - почти пятнадцать лет, неполная и кривая реализация WinAPI, некоторые приложения запускаются и почти нормально работают, некоторые запускаются и глючат, некоторые не запускаются вообще.

Даже у самой МС не получилось, вспоминая лонгхорн

Лонгхорн переписывали на .NET?

Рано или поздно софт устареет совсем безнадёжно и проще будет переписать.

А теперь посмотрим на это с точки зрения компании-разработчика. У компании A есть продукт X, у компании B - конкурирующий продукт Y.
Компания A может добавлять в свой продукт какие-то новые вещи, и конкурировать с продуктом Y. А ещё она может решить, что всё безнадёжно устарело и проще X полностью переписать на .NET. Тогда, потратив какую-то пару лет, разработчики сделают .NET-версию продукта X, и компания A её выпустит. За эти два года продукт Y продвинется далеко вперёд (а функциональность X-то останется прежней, потому что никто ничего не добавлял, все только переписывали), и этот самый продукт X "на современной платформе .NET" будет просто никому не нужен.
В итоге - компания А потратила деньги на переписывание своего продукта - в пустоту, и её продукт теперь уже никто не покупает; если же этот самый продукт был единственным (или основным) источником прибыли компании A, то она - банкрот, на рынке остаётся только Y с фичами, о X на .NET уже никто не вспоминает. Естественный отбор.
Как вы думаете, что выберет компания A?

о компаниях... как я уже упоминал, я работаю в сфере угольной промышленности. Так вот у нас сейчас есть и до сих пор используется значительное количество софта, вообще разработанного по DOS, и запускающегося на ХР с грехом пополам на честном слове и с никаким уровнем юзабилити... Покупать новые продукты известных зарубежных фирм часто просто нет денег... и переписывание с нуля в данном случае нашими программистами (чем я и занимаюсь) - вобщем-то единственный выход. Может не самый правильный и дальновидный, но раз спрос есть, значит будет и предложение.

о лонгхорне... насколько мне помнится в лонгхорне было намного больше компонентов, написанных на шарпе, тот же сайдбар... части WinFS...

Так вот у нас сейчас есть и до сих пор используется значительное количество софта, вообще разработанного по DOS, и запускающегося на ХР с грехом пополам на честном слове и с никаким уровнем юзабилити...

И правильно.
Если софт работает напрямую с железом - есть FreeDOS, если нет (а так оно и есть, судя по тому, что вы сейчас с этим софтом в XP работаете) - есть DOSBox. А под XP запускать досовские приложения - извращение.

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

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

о лонгхорне... насколько мне помнится в лонгхорне было намного больше компонентов, написанных на шарпе, тот же сайдбар... части WinFS...

Ну так вы видите разницу - выбрать .NET как платформу для разработки _нового_ продукта (сайдбар и WinFS в любом случае надо было писать с нуля) или начать переводить на .NET уже существующий продукт (т.е., фактически, потратить кучу времени на написание такого же продукта, какой был, с нуля, а не на добавление новых возможностей к старому)?

согласен, досбокс гораздо стабильнее, но вопроса наглядости представления информации и удобства пользования не прибавляет... людям в возрасте объяснить как жмакать по кнопочкам проще и быстрее чаще всего.

про китайские штамповки... так ведь и у нас пишут работающие на полставки студенты, которым за это платят копейки... я не говорю о системах уровня ArcGIS или бухгалтерской 1С, а куда более мелких, но не менее нужных вспомогательных софтинах, коих тоже нужно немалое количество. Кто-то конечно покупает нормальные, а кто-то и пользуется таким вот халявным трудом. Качество неахти какое конечно, но удобнее тех же старых аналогичных поделок и работает...

о лонгхорне... ладно, да, плохой пример. В чистом виде при наличии конкуренции, безусловно, это бред, кто ж спорит. Я немного про другое... Допустим, МС хочет сделать аналог google docs да и сам office 14 вообще вроде обещает быть гораздо более онлайновым, что означает что продукт-то остаётся по своему функциональному предназанчению при переходе к следующей версии, а вот сохранить текущий исходник, изменив немного интерфейс и добавив новой функциональности не получится. Придется кое-что, а может и значительно чего переписывать, ибо сами хорошо представляете, какие изменения потребуются при адаптации программы в web-приложение.

так ведь и у нас пишут работающие на полставки студенты, которым за это платят копейки...

Сейчас студенту, пусть даже работающему на полставки, платить меньше 10000р в месяц не получится.
Если у него уйдёт два месяца на наколенную поделку - это 20000р, мало какие программные продукты столько стоят. А те, которые стоят - это действительно сложные вещи, и там, чтобы как-то к этому приблизиться, надо не одному студенту, и не на полставки, и несколько лет трудиться (например, сможет ли ваш студент за два месяца написать хоть какой-то аналог фотошопа?)

Я немного про другое

Если новая функциональность будет писаться на .NET, в то время как всё старое останется таким, какое оно сейчас - это одно дело. Если на .NET будет написана веб-оболочка к функционалу офиса, который по-прежнему будет на каком-нибудь VC++ - тоже.
А если для добавления этой новой функциональности придётся большую часть текущей переписывать - то никто этого делать не будет. Тогда у МС уйдёт два-три (или больше) года только на то, чтобы переписать эти необходимые вещи на .NET, и только после этого они смогут взяться за добавление нового функционала; в результате, новая версия выйдет лет через пять (если не больше), в ней, скорее всего, будет очень много ошибок (или же выход отложится ещё на год-два), а конкуренты за это время уйдут далеко вперёд, МС офис будет никому не нужен.

вобщем, пора завязывать со спорами ))
но на последок всё же замечу... еще полтора года назад моя зарплата была 1500р. причём даже не всегда каждый месяц... и я писал... достаточно много.

еще полтора года назад моя зарплата была 1500р. причём даже не всегда каждый месяц... и я писал... достаточно много.

Вы где жили, в деревне Гадюкино?
Когда я был студентом-второкурсником, я за неделю нашёл приличную работу с интересными людьми, 4 дня в неделю по 5 часов - и в первый месяц моя зарплата была 12к.

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

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

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

А, в госконторе... так бы сразу и сказали ;)
Тогда в фразе

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

вы забыли сказать, что денег нет именно у госконтор.
А обычная организация - в неё никто за такие копейки работать не пойдёт, качество они никак проконтролировать не смогут, и будет гораздо легче и дешевле купить уже готовый продукт (если он, конечно, устраивает по своим характеристикам).

Вы не видите разницы между:
1) Открытым задокументированным стандартом всех возможностей, всего функционала платформы .NET - садись и реализуй для любой платформы, и
2) Закрытой платформой, которая совершенно неизвестно, как работает, и как должна работать - когда, по сути, приходится заниматься обратной разборкой, чтобы понять, что там внутри и что оно должно делать?
Если не видите - то посмотрите на сроки разработки, может быть, это вам о чём-нибудь скажет.
Моно - меньше четырёх лет, полная реализация (если тут не врут) .NET Framework 1.0, 1.1, 2.0; приложения, написанные для этих версий .NET Framework и не использующие посторонние библиотеки, должны запускаться на моно без каких-либо модификаций, с полной функциональностью и без проблем.
Wine - почти пятнадцать лет, неполная и кривая реализация WinAPI, некоторые приложения запускаются и почти нормально работают, некоторые запускаются и глючат, некоторые не запускаются вообще.

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

кстати под линуксами mono выглядит так же убого, как и wine...

то есть ты сильно зависишь от качества трансляции. я про что говорил - про то, что писать на нативном с надёжнее (разумеется не проще), чем на кроссплатформу.

Ваши слова можно и обернуть другой стороной.
.NET определяет интерфейс, через который я могу что-то делать. Если я делаю это "что-то" напрямую - я буду зависеть от реализации этого "чего-то". Если я использую нативную функцию создания файла, а в ней баг - то мне придётся ждать исправления этой функции в системном АПИ используемой ОС; если я пользуюсь интерфейсом - то достаточно подождать workaround-а разработчиков реализации интерфейса для этой ОС (ну или, опять же, исправления функции в самой ОС).
Если выйдет новая версия ОС, и у неё что-то внутри поменяется, изменится её интерфейс - от такого никто не застрахован, а моя программа перестанет работать, и мне придётся исправлять программу, потому что исправлять ОС никто не будет, это не ошибка. Если я использую чётко определённый интерфейс .NET Framework 1.1 - то мне неважно, где именно запущена моя программа, в какой версии какой ОС, вся головная боль, связанная с работой с системой, будет головной болью разработчиков реализации интерфейса, а я смогу заняться своим делом.
А МСовский .NET Framework, насколько я понимаю, является "транслятором системного апи" в той же степени, в которой и моно. И что, писать на нативном С в винде надёжнее, чем на .NET? Разве что вы пишете версию именно для WinXP SP1, и не гарантируете её работу больше абсолютно нигде - ни в WinXP, ни в WinXP SP2, ни в других ОС. Но тогда уже становится непонятно, чем было бы хуже писать, используя .NET Framework, который для WinXP SP1.

кстати под линуксами mono выглядит так же убого, как и wine...

Что значит - "убого"? Оформление плохое? Ну так это вопрос вкуса, кому-то под линуксом вообще всё будет казаться убогим.
А что касается качества работы - думаю, тут моно далеко обогнал wine.

На счёт большей надёжности нативного кода.
Для реализации какой-либо фичи, например, какой-нибудь ListView , элементами которого являются не текстовые строки, а скажем контролы (это просто пример, суть не в этом), на WPF вам вообще ничего не нужно будет сочинят, пользуетесь готовым, на винформах - напишете например UserControl на основе скажем TableLayoutPanel ну или ещё каким, поизврящаетесь с выделением элементов и в конце концов напишете, потратите к примеру 10 часов и получите 1000 строк кода, а на нативном C... (я даже браться не буду) либо напишете свой винформс а дальше через него либо вообще ничо не напишете, короче потратите к примеру 100 часов на разработку и получите 10000 строк кода.
Т.е. имеем кроме большего времени ещё и больший объем кода. А теперь вспоминаем теорию надёжности.
Кроме того в .NET (и java) есть вещи, которые принципиально повышают надёжность кода по сравнению с native C++, тот же сборщик мусора, те же делегаты. Тот же ThreadPool. В нативном C++ всего этого нет, можно конечно самому написать это велосипед, как я когда-то тоже делал, когда уже знал .NET, но писать приходилось на ATL/WTL и вообще голом API.
А на счёт производителности .NET:
http://rsdn.ru/article/devtools/perftest.xml
http://rsdn.ru/article/devtools/perftest2.xml
http://rsdn.ru/article/devtools/perftest3.xml
Статьи конечно старые, но думаю сегодня ситуация примерно такая же.

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

я не знаком с графическими движками линуксов - не знаю какие там ограничения есть, но что в моно, что в wine многие элементы на формах прорисовываются не полностью.

Кроме того в .NET (и java) есть вещи, которые принципиально повышают надёжность кода по сравнению с native C++, тот же сборщик мусора, те же делегаты.

Сборщик мусора (и вообще, отсутствие необходимости вручную работать с памятью) - это да.
А вот делегаты... кое-где они и полезны, но когда обычный разработчик видит такую фичу, он начинает её необдуманно использовать налево и направо, в результате чего код превращается в "прыгающее спагетти" (с)
Так что, имхо, лучше бы их и не было - это плохо, когда к такому приличному языку приделывают такие фичи, что становится очень легко писать ужасный код.

дык так и получается, что ты будешь зависеть сразу от двух факторов - и апи, и .net.

Так я буду зависеть только от качества реализации .NET на конкретной платформе.
А в вашем случае - я буду зависеть от самой платформы, и мне придётся писать по версии для _каждой_ платформы, и даже, по сути, для каждой версии ОС, в которой планируется использование моего продукта.

но что в моно, что в wine многие элементы на формах прорисовываются не полностью.

Значит, в mono ещё не полностью реализовали стандартную библиотеку (или не полностью реализовали дополнительную библиотеку, которой пользовался разработчик программы с этими формами). Я не в курсе, как там у моно дела обстоят.

Но мы ж с вами не тупые разработчики, нам то делегаты нравятся :;)

В этой ситуации практически все разработчики будут тупыми.
Единственное место, где я себе могу представить, чтобы делегаты были на своём месте - это аналог аспектов.
Всё прочее - от лукавого. Анонимные функции - ладно, но не делегаты.

А эвэнты?