2 Alex3

Давайте пример любейзнейший . А то поисковик при поиске "драйверы на C ++ 7" выдал кучу мусора и ссылку на WASM.RU, где действвительно есть статьи про написание драйверов, но про Це никогда не слыхали

.2 Chill

http://www.compexp.ru/doc/VxDWriting/part1.html

Ответить

Да, не люблю когда ламеры надо мной смеются.

Формат файлов LE.
VxD используют линейно исполняемый (LE - linear executable) формат файлов. Этот формат был разработан для OS/2 версии 2.0. Он содержит и 16-ти и 32-х разрядный код, что является необходимым для VxD. VxD берут свое начало от Windows 3.x. В то время Windows грузился из DOS, таким образом VxD могло потребоваться выполнять какую-либо инициализацию в реальном режиме, перед тем как Windows переключит систему в защищенный режим. 16-разрядная часть реального режима должна быть в том же файле, что и 32-разрядная защищенного режима, поэтому выбор формата LE выглядит вполне логичным. Драйвера Windows NT не имеют кода инициализации в реальном режиме, поэтому они вместо LE используют PE формат.
Исполняемый код и данные в LE файле хранятся в сегментах с различными атрибутами. Ниже перечислены все классы сегментов.

Ответить

И нафига весь этот треп под VxD? Они вообще под NT не используются.

В общем после этого твое утверждение "Драйвер - это 32 битная прога под ДОС" умнее не стало.

Если сомниваешься, что-то что можно сделать под C++ 6 нельзя сделать под C++ 7 не проще попробовать это, а не пудрить людям мозги?

Ответить

Имхо, имелся ввиду не C++ 7, а принципиальная возможность создания низкоуровневых приложений (типа драйвер) на основе .NET. Предполагаю, что это невозможно.

Ответить

Вот ещё адана канкретеная ссылка. Особенно интересен пункт 3.

2002 г. Начало четвертого поколения Basic — Microsoft Visual Basic .NET:

1. Интеграция всех средств разработки Microsoft в единый набор Visual Studio .NET, который, в свою очередь, "намертво" привязывает к платофрме Microsoft .NET Framework.
2. Одна из ключевых идей архитектуры Microsoft .NET — использование единой библиотеки базовых классов для всех языков программирования. При этом библиотека становится компонентом операционной среды, а не средства разработки, как это было раньше.
3. VB опять лишается возможности создания "настоящего" машинного кода. Более того, VB может создавать только "управляемый" код (в отличие от VC++ и C#, которые могут создавать и "управляемый", и "неуправляемый" коды), работающий исключительно под управлением .NET Framework.
4. Тем не менее VB .NET существенно приближает VB-программистов к возможностям C++ в отношении широты применения языка.

Источник вроде солидный. Я бы не стал с ним спорить.

http://www.microsoft.com/Rus/Msdn/Activ/MSVB/Archive/VBInHistory/445.mspx

Т.е. наСильник какой хотят код создают, а VB-шники только "под управлением .NET Framework". Вроде же кричали что это абсолютно одинаковые языки.

Ответить

А эта фраза

"работающий исключительно под управлением .NET Framework. "

Единственный вывод из этих слов - VB.NET - интерпритатор.

Может он не один к одному интерпритатор с GW-BASIC, но всё что я говорил в предыдущих топиках подтверждается.

Просто сам интерпритатор видоизменяется для предоставления ещё большего удобства начинающим программистам.

Разве все интерпритаторы микрософт похоже друг на друга?

Сравните

GW-BASIC->QuickBasic->VB3->VB6->VB.NET

Всем предыдущим версиям присуща полная или частичная интерпритация. Не думаю что Микрософт отошёл принципов, с успехом практикуемых уже почти 20 лет. Так что компилятором VB не станет до тех пор пока его производит Микрософт. Этот вывод вполне логичен. Или есть другие логичные выводы?

Ответить

Интерпритация->Интерпретация

Вот блин что называется привычка - вторая натура. Хотя VB подходит скорее к первому варианту.

Ответить

Ответить

Ответить

> Тут это, по-моему, уже 100 раз говорили, что .NET ни в коем случае

н является интерпретатором. Это - полноценный компилятор, причем этих

конпиляторов аж 2!

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

> На машине пользователя выполняется _конкретный_ машинный код.

Вот это новость! Первый раз слышу, чтобы на какой-то машине выполнялся не конкретный машинный код Это не определение компилятора...

> Исполнительную среду .NET можно образно сравлить с исполнительной средой VB6, а сам .NET Framework - это просто набор кода, который ты вовсе не обязан использовать. Хотя, конечно, это не совсем верное сравнение.

Совсем неверное. Я и виртуальную машину VB6 использовать не обязан, надо просто не писать на VB6

> Все программисты пишут код для виртуальной машины: И программисты Java

(для виртуальной машины Джава), и программисты VB6 - для виртуальной

машины VB6, и программисты .NET - для виртуальной машины .NET, и даже

программисты ассемблера, которые пишут код для "виртуальной машины",

которая в свою очередь реализуется микрокодом самого процессора.

Только надо учитывать, что JavaVM написана Sun, VBVM и FW написаны Microsoft, а микрокод процессора зашит в него самого программистами Intel и поменять его нельзя.

> Он теоритически является системнонезависимым, т.е. теоритически сможет

выполняться в любой системе, где установлен рантайм и библиотека

классов .NET Framework. Увы, пока она достаточно хорошо реализована

только для Windows

Сильно уверен, что FW никогда не будет реализован даже для Linux.

> Управляемый код не подвержен ошибкам утечки памяти и ошибкам

исключения защиты памяти, он не может вызвать критический сбой

системы.

Это только предположение, вызванное мелкомягкой рекламой. Нам ведь никто не показывал исходники, не так ли?

> Управляемый код по умолчанию не может иметь проблем с Hell DLL.

А вот это что-то новое... Почему?

Ответить

Ответить

>и даже программисты ассемблера, которые пишут код для "виртуальной машины", которая в свою очередь реализуется микрокодом самого процессора.
 - Совершенно бредовое утверждение человека никогда не видевшего АСМ. На нём нет никакой виртуальной машины. Там все 100% подключается. Даже работа под виндой подключается.
  И уже эти слова заставляют относится ко всем остальным словам с недоверием.
 Я бы мог по твоему высказыванию развить мысль что всё в мире делается через (нет не ж...) виртуальную машину. Но по моему это совершенно тупиковое направление разговора.
 Какая может быть виртуальная машина когда ты просто переключаешь те или иные триггеры или пересылаешь те или ниые данные.
 И хвалить за столь бредовое утверждение можно только если сам разбираешся в такой же степени.
 Это касается и других компиляторов (в отличие от интерпретатора VB.NET). Я уже сказал по моему что любой интерпретатор жёстко привязан к своей среде. Разве это не видно из всех предыдущих версий МS BASIC?
 Для всех продуктов MS ты привёл примеры их виртуальных машин. А для АСМ ты просто туманно заявил "виртуальной машины"! Разве это серьёзно???

>И еще по поводу управляемого/неуправляемого кода. Я не вижу причин использовать второй, тк Managed код имеет огромный ряд преимуществ перед UnManaged
 - Конечно интерпретатор в общем имеет ряд приемуществ по сравнению с компилятором. Но его главный недостаток - он работает только в пределах своей среды и не может от него отклоняться. Ты не можешь контролировать процессы, происходящие на компьютере, а только слепо доверяться виртуальной машине. Как бы хороша она не была, но она по любому будет несовершенной. И ты не можешь внести в прогамму никаких изменений, улучшений или дополнений только потому что этого тебе не позволяет виртуальная машина.

>Управляемый код по умолчанию не может иметь проблем с Hell DLL.
 Да, потому что она находится за пределами контроля виртуальной машины. Просто она не видит её и по этому ей совершенно начхать на все внешние проблемы пока они её не трогают. И всякие "безопасные указатели" это всего лишь внутренний инструмент среды, а вовсе не реальные адреса модулей в памяти.

 Жёстакая привязка к среде виртуальной машины (не подключаемых статически или динамически модулей) способ контроля инструмента разработки программ, предназначенный для начинающих и непрофессиональных программистов. БЕЙСИК и являетсь инструментом создания программ именно для таких программистов. Те, кто уже освоил основы программирования, как правило переходят на нормальные языки. Те же кому удобен синтаксис Бейсика (или например они к нему привыкли) ищут нормальный компилятор с его синтаксисом.
 Если обучение основам программирования закончено, то зачем переходить во второй класс с учебником за первый. Он там просто не нужен будет. Получается что ты вроде всё время остаешся на второй год.

Ответить

Ответить

Ответить

> Как вы (CyRax, Sharp) можете утверждать может ли произойти утечка в

памяти или "кошмар DLL", не зная самого .NET? Чего вы вообще

добиваетесь?

Мы зато хорошо знаем, откуда растут руки у программистов Microsoft и более чем уверены, что .NET, так же, как и 95 и 98 и 2000 и Ме и ХР и 2003 не станут панацеями против всего вместе взятого и совсем не стоит убеждать людей в непогрешимости .NET только потому, что это все пообещал дядя Билли

> Я бы мог развить эту мысль, чтоб показать тебе, что управление любым

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

виртуальную машину, но не буду этого делать.

Сравнение неправомерно. Микрокод процессора не продается отдельно от компьютера, в отличии от Windows с FW. Практически уверен, что когда мелкомягкие вдоволь поорут о совершенстве и невероятной кроссплатформенности .NET и все на него перейдут, они даже не подумают реализовывать его для других платформ (ну разве что Pocket PC+Windows CE)... Прежде чем рассуждать о программной технологии или программном продукте от Microsoft, стоит подумать, как на этом можно нагреть руки. Тогда многое становится понятным. Никогда прежде мелкомягкие не руководствовались принципами человеколюбия и свободной конкуренции, не будут и впредь.

О стабильности и безопасности Managed-кода: оно гарантируется только стабильностью и безопасностью самой Винды, а она легенда в этом плане недаром.

> И еще раз - можно было, прочитав это тут уже десяток раз, запомнить:

VB .NET - это не интрепретатор, а полноценный компилятор.

Какй же он компилятор, если использует управляемый код? Подчеркнем: управляемый .NET код...

> И еще - управляемый код не распределяет для себя память, он не создает

и не удаляет указатели, не имеет доступа к регистрам процессора и

практически не может работать с оборудованием напрямую.

Наверно, мне с моей колокольни программирования прикладных научных и инженерных задач видно немного по другому, но, имхо, это совсем не есть гуд... Была бы моя воля, я бы писал программу, работающую, скажем, после загрузки компа с сидюка, т.е. однозадачную среду с полным управлением вычислительным устройством... Но раз пользователь любит многозадачность, то я бы предпочел бы иметь мультизадачную ОС с микроядром и свободным доступом к аппаратным ресурсам... Посему я все больше подумываю о переходе на какой-нибудь Linux или FreeBSD...

А что такое сильные имена?

Ответить