Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Microsoft's.NET MicroFramework
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2
Evgeny_CD
Цитата(TED17 @ Jul 24 2006, 22:12) *
Если MicroFramework пойдет по пути CompactFramework, то - сливай воду- все остальное скоро станет экзотикой и будет отторгаться производителями как несовместимое и неудобное при коллективной разработке. Пробовал работать под CompactFW(для WinCE) - нет проблем - нормальный компилятор и отладка на хорошем симуляторе. А с дровами и портами уM$ никогда поблем не было. Так что скоро все основные производители embedded объявят о локализации на свои чипы и платы - а там посмотрим - много ли останется любителей экзотики. M$ можно не любить, как монополиста, но не учитывать его как серьезного игрока - большая ошибка.
Написание дров под свою периферию для такой системы - это целое искусство, вероятно.

Простой пример - 926 ядро ARM пихают в девайсы уже года три как, а массового увлечения embedded JAVA я как-то не наблюдаю (может, разве что в сотиках), особенно для промавтоматики. Или просто Embedded JAVA рано выстрелила? А за счет жезели ускорение должно быть нехилое...

Я, откровенно говоря, SUN не понимаю. Они что, решили присоединиться к DEC в аналах истории? blink.gif

Ведь вот от этой штуки исходники должны лежать на кажом углу!
http://sunspotworld.com/products/

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

В конце концов, для мелкосерийных, но достаточно сложных вещей стоимость разработки важнее стоимости железа - а применение .NET похоже, способно сильно упростить разработку "верхнего уровня". Ибо в диапазоне "до 30$" сейчас умещаются PPC процы-контроллеры с производительностью 700+ DMIPS (MPC5200 от FreeScale). И обвязки им надо всего ничего - FLASH да SDRAM, которые при небольших объемах встанут не более чем в 4$.

Вот и представим себе, что появится "платочка" на MPC5200 за 100$, с готовыми дровами для весьма и весьма умной периферии этого камня, и все удобство .NET Studio к нашим услугам...

Понятно, что от M$ порт micro-.NET под PPC не появится (нет же PPC в списке целевых архитектур WinCE), так что придется натурально хачить DotGNU.
Evgeny_CD
Цитата(ArtemK @ Jul 24 2006, 15:01) *
Цитата
Вроде есть еще один - Solo, но я не нашел.
Возможно, имеется в виду Mono
Да, это оно!
TED17
Цитата(beer_warrior @ Jul 24 2006, 22:42) *
Цитата
ак что скоро все основные производители embedded объявят о локализации на свои чипы и платы - а там посмотрим - много ли останется любителей экзотики.

И на скоки платформ они сделают порт? Или единым фронтом ARM/WinCE закроют все дыры?

У M$, как известно, "гретьи" производители железа сами пишут дрова, минипорты и пр., а M$ их только сертифицирует. Немного времени на раскачку и желающих попасть в мощный поток будет предостаточно. ARM/WinCE/CF является лишь примером удачности такого подхода. Вот и идет продолжение.
Thistle
Мне кажется некоторым участникам дискуссии стоит погуглить по словам Оберон, Никлаус Вирт, Zonnon....удачи.
SpiritDance
Цитата(Thistle @ Jul 25 2006, 21:15) *
Мне кажется некоторым участникам дискуссии стоит погуглить по словам Оберон, Никлаус Вирт, Zonnon....удачи.

А также модула-2 laugh.gif Как же припоминаем... "Вы прострелете себе голову..."
Извините за оффтопик не удержался.

Еще чуть-чуть оффтопика по поводу языков и sun. Вот что назревает
http://research.sun.com/projects/plrg/
Evgeny_CD
Цитата(Thistle @ Jul 25 2006, 21:15) *
Мне кажется некоторым участникам дискуссии стоит погуглить по словам Оберон, Никлаус Вирт, Zonnon....удачи.
И что я, как один из участников дискуссии, должен узреть в Zonnon?
http://www.software.unn.ac.ru/zonnon/files...ody-toprint.pdf


Нетривиально - бо'льшая часть ресурсов по Zonnone имеют российское происхождение
http://www.zonnon.ethz.ch/language/books.html

Кто знает, что это такое - может просветит в кратце?


Если из Zonenon есть компилятор в .NET - то какова же скорость выполнения кода в итоге получится?

Вообще, судя по изобилию новых языков, в основе которых лежит байт-код, развитие идет строго по спирали:

CISC -> RISC -> CISC II ->?

CLI вполне так себе CISС архитектура...

Вообще, похоже наше светлое будущее - это обычный CPU какой-нибудь + FPGA, которую каждый использует в меру своей испорченности. В принципе понятно - чтобы базовый набор объектов, в который компилируется решение задачи, оптимально соотвествовал специфике решаемой задачи.

http://research.microsoft.com/workshops/SS...#681,2,Hardware - на сахаре подсказали...
TED17
Цитата(Evgeny_CD @ Jul 26 2006, 02:48) *
Вообще, похоже наше светлое будущее - это обычный CPU какой-нибудь + FPGA, которую каждый использует в меру своей испорченности. В принципе понятно - чтобы базовый набор объектов, в который компилируется решение задачи, оптимально соотвествовал специфике решаемой задачи.

http://research.microsoft.com/workshops/SS...#681,2,Hardware - на сахаре подсказали...

Наше светлое будущее - как и у всех- превращение программирования embedded из искусства для посвященных в массовую рутинную работу кодеров, а в дальнейшем и просто конечных пользователей.
И связка линии .NET ( Framework - CmpactFramework - MicroFramework) с полной обвязкой и есть логичное движение к единообразию процесса.
Evgeny_CD
Я так понимаю ситуацию со всеми этими новомодными языками

Есть три слоя embedded системы

* дрова; ASM оптимизированные части
* RTOS, C приложения
* интерпретатор/компилятор байткода

И за счет этого можно проводить многопараметрическую оптимизацию разработки:

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

Разработчик сам определяет, что писать на С, ASM, а что на C#.

Собственно, нет темы для спора. Никто и никогда не буде писать на Zonnon ОСь, дрова, ISR и т.д. А вот сложные управляющие алгоритмы - очень дажа запросто. А зыку, описание которого занимает 30 страниц, можно обучать продвинутых заказчиков - и пусть они сами себе пишут алгоритмы верхнего уровня. Собственно, такая идея давно известна в промавтоматике - с IEC языками. Там кустмеры (продвинутые) сами ишут программы, при этом мыслят категориями целевой задачи, а не категориями указатель, массив и пр. И ничего - все работает!

Собстенно, прелесть ЯВУ-2 в том, чтобы дать кустомеру весь набор необходимых ему сущностей, и дать очень простой механизм работы с эими сущностями.

Вопрос по .NET. Вот написал я приложение на пысюке. Скомпилил в CLI. Запускаю на embedded системе. Либы (простые - prinf) для этого приложения линкуются также в CLI, или они должны быть реализованы отдельно на моей целевой платформе?
bialix
Цитата(Evgeny_CD @ Jul 23 2006, 15:46) *
Цитата(beg @ Jul 23 2006, 15:06) *
Согласен, ибо наблюдаю такие траблы у людей, возящихся с OC2000, QNX, Linux, которых в WIN и в помине нет. Отвратный интерфейс, документация, не поддерживается более - менее новое железо (PCI-Express, USB2, IEEE 1394, Gigabit Ethernet).
Не забудьте, что часть (большая) этих стандартов была разработана специально, чтобы "согнать" народ, который "прижукался" в 98 и 2000 виндах (ну а линухоидов "шугануть" - это вообще святое! чтобы они не забыли почувствовать себя людьми второго сорта - вот у Васи мышка с синим светиком в заднице рабоает, ибо он крутой, ему родители пЫсюк с ХРенью купили, а Петя, который полгода корпел над книжками и таки научился ставить линух, не может завести такую мышку - дров нету и не будет, ибо мышка не для пиплов второго сорта. Вывод: девочки, дружите с Васей - у него все в жизни будет правильно. А Петя - тот по жизни будет "очки драить", и в сводобное время линуховать в свое удовольствие). Ибо при создании этих стандартов изначально все, кому положено, договорились - не будет дров под старые оси.

Что касается технической ценности, то она есть только в PCI-Express да Gigabit Ethernet.


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

Посмотрим на это с другой стороны. Я -- производитель компьютерного железа. Не ПО! Мой бизнес -- суть продажа железяк. Как на него вляет ПО? Очень просто: под каждую ОС я, как производитель, должен написать драйвер. Т.е. держать штат драйверописателей. Хотя они не приносят прямую прибыль. Прямую прибыль приносят продажи железяк, которые покупают пользователи. Если я делаю мышки, которые прродаю по низкой цене, то я должен продать их как можно большему количеству людей, чтобы поиметь суперприбыль. Значит надо минимизировать побочные издержки. Значит нафиг мне иметь 300 программеров, которые будут писать драйвера на 300 операционнок, если пользователей операционки одного типа более 80%. И именно они главные мои покупатели? Да забью я на всякие альтернативные и старые ОС, потому что мне экономически это не выгодно. Фсё.

Я прочитал внимательно всю эту дискуссию. И мое мнение: имхо, даже эмбеддед отрась слишком многослойна, чтобы так однозначно делать выводы, кто победит МС или нет. Слишком много применений, и плясать надо не от тиражей в месяц, а от ожидаемого срока разработки/срока эксплуатации/общего тиража системы за ожидаемый срок продаж. И здесь искать какую прибыль обеспечит та или иная технология.

Нафик нужен НЕТ в милионной партии контроллеров унитазных бачков, которые должны быть дешевле песка? Нельзя делать однозначных выводов, как бы этого ни хотелось. Не получится. И пока остаются ниши, где можно прожить без навязываемых решений, остаются возможности заработать деньги. Деньги нужно искать господа.
Evgeny_CD
Цитата(bialix @ Jul 26 2006, 17:21) *
Посмотрим на это с другой стороны. Я -- производитель компьютерного железа. Не ПО! Мой бизнес -- суть продажа железяк. Как на него вляет ПО? Очень просто: под каждую ОС я, как производитель, должен написать драйвер. Т.е. держать штат драйверописателей. Хотя они не приносят прямую прибыль. Прямую прибыль приносят продажи железяк, которые покупают пользователи. Если я делаю мышки, которые прродаю по низкой цене, то я должен продать их как можно большему количеству людей, чтобы поиметь суперприбыль. Значит надо минимизировать побочные издержки. Значит нафиг мне иметь 300 программеров, которые будут писать драйвера на 300 операционнок, если пользователей операционки одного типа более 80%. И именно они главные мои покупатели? Да забью я на всякие альтернативные и старые ОС, потому что мне экономически это не выгодно. Фсё.
Нет, вы будете поддерживать мелкомягких еще и потому, что у Вас появится легальная возможо "подкидывать" Ваших кустомеров. Новая ОСь - новое поколение "мышей" от Вас. А старое - ну оно уже устарело, зачем далать дрова для старья.
Цитата(bialix @ Jul 26 2006, 17:21) *
Нафик нужен НЕТ в милионной партии контроллеров унитазных бачков, которые должны быть дешевле песка? Нельзя делать однозначных выводов, как бы этого ни хотелось. Не получится. И пока остаются ниши, где можно прожить без навязываемых решений, остаются возможности заработать деньги. Деньги нужно искать господа.
Если сливной бачек .NET будет сам по интеренету сообщать о количестве оставшейся бумаги и чистоте своих внутренностей, и, самое главное, будет совместим с M$ Office Pack (условное название; разумеется M$ позаботится о том, чтобы куль хацкер с AT91SAM7S не смог сделать такое же решение, - протокол общения будет столь сложен, что куль хацкер быстро устанет) - не сомневайтесь, его будут раскупать просто пачкам.
TED17
Цитата(Evgeny_CD @ Jul 26 2006, 15:03) *
Вопрос по .NET. Вот написал я приложение на пысюке. Скомпилил в CLI. Запускаю на embedded системе. Либы (простые - prinf) для этого приложения линкуются также в CLI, или они должны быть реализованы отдельно на моей целевой платформе?

Рановато пока об этом, - еще только анонс MicroFramework вышел. Пока у M$ идет туман в терминах, но
всеже .NET - это платформа разработки, а Framework.NET - это пока исполняющий встраиваемый в стартовую ОС Runtime модуль. Конечным результатом разработки являются СОМ-подобные метаданные в М$ формате MSIL. Они и пишутся в девайс после установки Frameworkа. В поцессе работы, встроенный в Framework Just-In-Time — компилятор, выполняет преобразование MSIL в машинный код по мере обращения к соответствующим процедурам (т. е. неиспользуемые фрагменты программы вовсе не компилируются). Вот по поводу этого JIT- микрокомпилятора, похоже, M$ сейчас и договаривается с Motorola, TI, FreeScale ..., -все остальное у них отработано. Скоро все узнаем.

P.S. По повду мышей и унитазов полностью с Вами согласен, - тенденция даже таких вещей к усложнению очевидна (не так давно не понимали зачем нужен ARM).
TED17
Небольшая видеодобавка - больба минироботов сумо ( сделаны на Мicroframework beta) - июльMEDC 2006
http://download.microsoft.com/download/6/7..._sumo_night.wmv

The Parallax Sumorobot has been modified with a StrongArm processor to accept .Net microframework. The original one is using the PIC16C57 processor from Microship.
Concorde
Внесу свою 5 копеек.
Какое-то время назад я работал в ABB, делали электрические счетчики. Основной офис (железячники) был в Штатах. Так вот, они (американцы) всем отделом полтора года бились над тем, что бы снизить себестоимость на 15 центов. ARM ? Да вы что ! Он дороже на целых 1.5 доллара. Тиражы миллионные. Думаю, про .NET они точно даже думать не будут. Воткнули CMX RTOS (имплементация - один .c файл). Потом, .NET хорош для больших машин (десктопов). Я, как бывший разработчик Win32 приложений (достаточно сложных) прыгал от счастья, видя, что в .NET появился вменяемый reflection, сборщик мусора и... и больше ничего не нужно, в общем-то. reflection хорош для абстрагирования интерфейсов. А зачем это нужно ? Исключительно для большей простоты использования и/или написания своих библиотек. Основное мясо в любой системе - это библиотеки. И все более усложняющиеся языки служат как раз решением для более эффективного написания оных. У MS есть открытая реализация .NET вкупе с компилятором CLI для x86. Называется Rotor. Они же заставили работать свой .NET под FreeBSD. Конечно, .NET будет использоваться, как используется сейчас java. Причем по буржуинским конторам видно, что основное направление использования java сейчас - это servlet'ы. Видимо, основное направление .NET будет GUI. Но не думаю, что когда-нибудь мы будем мигать светодиодами через .NET или java или еще какой-нибудь сложный язык, подразумевающий большой оверхед (проверка выхода за границы массива, сложный менеджер памяти). По крайней мере, при больших тиражах точно.
Evgeny_CD
Цитата(Concorde @ Jul 26 2006, 23:04) *
...Но не думаю, что когда-нибудь мы будем мигать светодиодами через .NET или java или еще какой-нибудь сложный язык, подразумевающий большой оверхед (проверка выхода за границы массива, сложный менеджер памяти)....
Еще как будем! Вприпрыжку будем!

Представьте, появляется плата:

* ARM9 200 Мгц
* 2М FLASH
* 32 M SDRAM
* Ethernet
* SD
* RS-232
* FPGA на шине для custom периферии
* продуманный конструктив
* удобный разъем

за <100$. + Вменяемый SDK на основе "сложных языков". С визардами, готовыми компонентами для FPGA, дровами под них и т.д.

Фантастика? Вот смотрите:

http://gumstix.com/spexboards.html
gumstix basix 200 with MMC slot 64MB SDRAM 4MB Strataflash MMC slot ---- 99$

http://www.glomationinc.com/product_9302.html ---- 95$
200MHz Cirrus Logic EP-9302 ARM core processor with math co-processor
32MB 100MHz high speed SDRAM , 4 - 16 MB FLASH
10/100 baseT Ethernet
2 USB
2 UART with RS-485 support
Real-time clock and watch-dog timer
A/D
D/A
Digital I/O
Real time clock

Это отладочные платы, у них не такие уж и большие тиражи.

Так вот, та самая чудо плата, что я обрисовал - она дополняется небольшой 2-х слойкой, специфичной для проекта - и все, custom железо готово!

И в итоге время разработки среднего контроллера сокращается до 1-2 недель. И для небольших тиражей это с лихвой компенсирует более высокую стоимость самих плат. Проекты на потоке делаются силами нескольких человек: программер на "сложных языках", разводчик плат, монтажник.

Для того, чтобы сделать такой "финт ушами", нужна серьезная контора и очень взрослые деньги в начале - потом они сторицей окупятся. M$ это вполне по плечу - ей не привыкать делать очень массовые продукты.

Так что на самом деле все гораздо серьзнее, чем кажется.
TED17
Цитата(Evgeny_CD @ Jul 27 2006, 01:43) *
Цитата(Concorde @ Jul 26 2006, 23:04) *
...Но не думаю, что когда-нибудь мы будем мигать светодиодами через .NET или java или еще какой-нибудь сложный язык, ....

Еще как будем! Вприпрыжку будем!
Представьте, появляется плата:.......


Вот такая, например:
http://www.robmiles.com/net-micro/
(хорошая фотка)
Kopa
Цитата(Evgeny_CD @ Jul 27 2006, 00:43) *
Цитата(Concorde @ Jul 26 2006, 23:04) *
...Но не думаю, что когда-нибудь мы будем мигать светодиодами через .NET или java или еще какой-нибудь сложный язык, подразумевающий большой оверхед (проверка выхода за границы массива, сложный менеджер памяти)....

Еще как будем! Вприпрыжку будем!
...
Так что на самом деле все гораздо серьзнее, чем кажется.

Если для AVR и других слабых контроллеров уже есть прецеденты использования java для "мигания светодиодами" то ARM процесору тем более должно это подойти.smile.gif
Внутренняя спецификация Java довольно простая вещь.
Concorde
Что-то сомнения берут. Смысла не видно. Есть только один плюс - использование Visual Studio для отладки. С точки зрения быстроты разработки, уверяю, что взять что-нибудь готовое (типа того же CMX RTOS + TCP/IP + GUI + ??) - будет гораздо быстрее и надежнее.. И дороже, правда (первоначальные вложение). Использование .NET сильно зависит от схемы лицензирования. По оверхеду, боюсь, ARM 200MHz только и сможет что светодиодами мигать (неторопливо). Много было попыток. И процессоры чистые под java делали, и много что еще. В принципе, если будет решение, не привязанное к MS (просто JIT компилятор ECMA кода, т.е. байт-кода .NET) может это и будет как-то использоваться. Но проблем с первого взгляда на порядок больше, чем использование C/C++.
Мне вообще не понятно, как они, например, сделали тот же менеджер памяти. Он же страшно медленный (точнее сам очень быстрый, но конкретно подвисает когда идет сборка мусора). Одного взгляда на внутренности .NET поражают - как это еще работает (более-менее быстро). Думаю, Vista охладит пыл многих, т.к. она написана почти полностью на .NET. Требования уже впечатляют, быстродействие, тоже, боюсь "обрадует".

Кому интересно, ссылка на Rotor.
TED17
Цитата(Concorde @ Jul 27 2006, 09:15) *
Что-то сомнения берут. Смысла не видно. Есть только один плюс - использование Visual Studio для отладки. С точки зрения быстроты разработки, уверяю, что взять что-нибудь готовое (типа того же CMX RTOS + TCP/IP + GUI + ??) - будет гораздо быстрее и надежнее.. И дороже, правда (первоначальные вложение).

В том то и дело, что под Visual Studio будет сидеть не ембеддер, обладающий магическими знаниями и опытом, а обычный кодер. Роботов сумо делали студенты.
А насчет цены, так Visual Studio получется универсальный инструмент - от Vista до светодиода, а Framework бесплатен.
Concorde
Цитата(TED17 @ Jul 27 2006, 14:35) *
В том то и дело, что под Visual Studio будет сидеть не ембеддер, обладающий магическими знаниями и опытом, а обычный кодер. Роботов сумо делали студенты.
А насчет цены, так Visual Studio получется универсальный инструмент - от Vista до светодиода, а Framework бесплатен.

Ну, обычный кодер и на C может писать. А студенты - это вообще отдельная тема. Если какой-то студент что-то там сделал, это совершенно не показатель, что так можно (и нужно) делать. Потому что кроме как просто "работает" есть еще куча других факторов в коммерческом софто/железостроении. Насчет бесплатности Framework - это даже пугает. Сходу не вспомню ни одного бесплатного продукта MS, который был бы вменяемый. Лично я даже от MediaPlayer отказался, т.к. хрен настроишь все эти кодеки. Показывает вкривь и вкось (спутниковый поток).
serj_obninsk
Господа, давайте всё-таки разделять крупнотиражный продукт от специализированной разработки. В первом случае, как уже было верно подмечено, даже лишние 15 центов на изделие вносят свой вклад. Соответственно, нужны более квалифицированные разработчики. Во втором случае - упор делается на скорость разработки, а на себестоимость продукта и качество (как продукта, так и "программистов"), как правило забивают болт. Поработав некоторое время в аутсорсинговой конторе (а таковых у нас в стране наверное большинство), я успел насмотреться на тот кошмар, что там производится... Расход памяти в несколько гигабайт, торможение восьмипроцессорного сервера при паре десятков подключенных клиентов. Писано было как раз под .Net. ХАЛТУРА это, а не ТОВАР. Это то, что нужно быстро ВПАРИТЬ(другого слова не подберёшь). maniac.gif

Другой пример - много ли вы видели КРУПНОТИРАЖНОГО софта для ПК, написанного под java или дотнет, а? Софта коробочного или shareware, не важно, главное чтобы стоял на миллионах машин по всему миру. Софта уровня AutoCAD, Photoshop, PCAD, Premiere, Acrobat, Kaspersky Antivirus, да хотя бы уровня Winamp и MediaPlayer? Много видите? Вот и я о том же. Основной объём разработок на java и dotnet - это кривулины, "лишь бы работало".

В любом случае, даже при самых неблагоприятных перспективах развития embedded-отрасли, человек, владеющий C# + C + asm будет цениться гораздо больше чем просто владеющий C#. Пишется-то оно проще на шарпе, до поры до времени. Пока вниз спускаться не придётся.
AntonKr
Во многом Вы правы, но ... Я знаю много компаний (западных) которые используют продукты написанные на java. Сейчас наблюдаю за процессом внедрения продукта в компанию, который также написан на java и стоит несколько млн $. На рынок выходит много продуктов написанных под .net. Уверен, что их будет больше после выпуска ОС с интегрированным .NET. Сейчас пишу большие проекты на c#, и поверьте, они очень ценятся в моей компании. Естественно я имею опыт написания программ на С++ и на asm, т.к. занимаюсь программированием около 20 лет. Но хочу сказать что используя C# я могу написать проект быстрее. А глюкавость зависит от отношения человека к тому, что он делает. Могу привести пример: я не имел опыта программирования под ARM или AVR (хочу попробовать), но я купил GSM module с поддержкой java, сделал схему с 1-Wire через I2C, повесил несколько датчиков и несколько исполнительных устройств через GPIO. На java (за вечер) написал несколько библиотек и в итоге получилась не плохая программа, которая автоматически загружается при запуске модуля. Через СМС или DTMF я могу управлять устройствами, а также получать информацию от датчиков при их срабатывании (соответственно по определенной логике). Через инет могу входить на свое устройство как на WEB сервер. И что? На это все у меня ушло не более 1 недели (это хобби и занимался только по вечерам). Я не говорю, что это устройство лучше того, которые создаются вами, но теперь многие смогут работать с данными устройствами, т.е. интерес сильно возрастет к ARM, что и является целью производителя.
white.wind
Цитата(serj_obninsk @ Aug 4 2006, 13:03) *
подключенных клиентов. Писано было как раз под .Net. ХАЛТУРА это, а не ТОВАР. Это то, что нужно быстро ВПАРИТЬ(другого слова не подберёшь). maniac.gif

Другой пример - много ли вы видели КРУПНОТИРАЖНОГО софта для ПК, написанного под java или дотнет, а? Софта коробочного или shareware, не важно, главное чтобы стоял на миллионах машин по всему миру. Софта уровня AutoCAD, Photoshop, PCAD, Premiere, Acrobat, Kaspersky Antivirus, да хотя бы уровня Winamp и MediaPlayer? Много видите? Вот и я о том же. Основной объём разработок на java и dotnet - это кривулины, "лишь бы работало".


Ну вот тут есть список халтурщиков на дотнете:

http://msdn.microsoft.com/netframework/partners/default.aspx

Еще есть:

Paint.NET — редактор растровой графики, Washington State University.

SharpDevelop — среда разработки, IC#Code.

PS. Я ребят спросил smile.gif , еще подбросят ссылок на халтурки.
COMA
И я халтурщик smile.gif
С# + MS SQL.

не бедствуем smile.gif
?ELF
Цитата(white.wind @ Aug 4 2006, 15:34) *
Ну вот тут есть список халтурщиков на дотнете:


Мои 5 копеек. Ещё один «халтурщик», активно использующий .NET и шарп в своих проектах. smile.gif
http://www.securpress.ru/issue/Tb/2004/tranzas.htm

P.S. Извините за поднятие архивной темы.
В период бурного обсуждения, я ещё не знал о существовании electronix.ru
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.