Здравствуйте, Ops, Вы писали:
Ops>Ну вот пару дней назад vbox сломался, сам одной версии, extensions другой, виртуалка не пускается. Вообще, поддержка многих пакетов в лучших традициях опенсорса.
А, в этом смысле.
Ну да, изначально идея была такая: вендоры сами размещают пакеты, ленивых заменяет сообщество. Но что-то пошло каквсегда…
Здравствуйте, koandrew, Вы писали:
K>Нужна эта опция в основном для интеграции с легаси-кодом в виде COM-объектов (т.к. они бинарные, то для 32 и 64 бит нужны разные библиотеки, старые компоненты, соответственно, есть только в 32 битных билдах). У нас на работе полно такого хлама.
Это менее важная причина. Товарищ Точка выше уже описал главную причину, почему битность торчит -- заголовок PE-header'а.
Здравствуйте, alexzzzz, Вы писали:
A> Если на 64-разрядной ОС твоя программа будет автоматически запускаться как 64-разрядный процесс, как и куда она будет подгружать эту 32-разрядную библиотеку?
Топик уже истоптал всю поляну вокруг главной идеи, некоторые её даже косвенно озвучили, но пора бы уже настоящим инженерам догадаться. Выскажусь тезисно:
1. Чисто теоретически, идеальная система (какую и ДОЛЖНЫ были проектировать гиганты вроде MS) может спокойно обходиться БЕЗ БИТНОСТИ. Java тому прекрасный пример.
2. Все намёки на "загрузку 13-битных DLL в 47-битной системе" отношу к непрофессиональным — все почему-то решили, что если МИКРОСОФТ СВАЛИЛА СВОИ ПРОБЛЕМЫ НА ВАС, то так и должно быть! НЕ ДОЛЖНО. Нет вообще никакого смысла заново "изобретать VM" (после Java), если мы опять скатываемся в гуано, которое накосячила MS! Это ЕЁ ПРЯМАЯ ЗАДАЧА — обеспечивать загрузку "разнобитных DLL".
Итого, как MS должны были сделать, но не сделали ввиду узколобости руководства и посредственной квалификации разрабов:
1. Новый формат исполняемых IL-файлов. Скажем, *.mod(ule). Он НИЧЕГО не меняет в экосистеме венды, зато даёт однозначность при работе с ними. Заодно, сплавив legacy-поля и введя современные. Сейчас мы имеем БАРДАК из *.exe, *.dll, *.ocx и прочего фуфла, где невозможно сказать, что это за модуль — 16-битный DOS, 64-битный вантуз или вообще MSIL! СПАСИБО тебе, микрософт, что добавляешь геморой на пустом месте, зато с "единым запускатором" в виде PE-файла!
2. Прозрачная загрузка любых DLL. Ни бог весть какая задача, особенно на x64 системах, особенно для квалифицированного windows-системщика. То, что венда — это мельница из костылей и изоленты — это ВАША(MS) ВИНА. Задача адекватного инженера — сделать так, чтобы вообще про битность можно было забыть! Не от большого ума была придумана компиляция в x64 режим, потому что в одном приложении запросто могут быть СРАЗУ НЕСКОЛЬКО БИТНОСТЕЙ(!). Во что компилять MSIL, если он использует сторонние DLL из 13 и 25 битов? В полусумму? Вот то-то же!
Ну и пункт, с которым вообще нет смысла спорить:
3. .NET с самого первого байта ОБЯЗАН был быть портируемым. Это просто сама суть VM — обеспечивать переносимый, бинарный код. Жалкие оправдания, почему это НЕ было сделано просто смехотворны и главное, лишь подтверждают убогую квалификацию тогдашних программистов, ибо сейчас они ВСЁ РАВНО К ЭТОМУ ПРИШЛИ — к переносимому .NET Core! Нужны ли ещё доказательства того, что .NET — красивая идея с безобразной реализацией?! (впрочем, как и всегда у MS)
Здравствуйте, Sharov, Вы писали:
S>Это менее важная причина. Товарищ Точка выше уже описал главную причину, почему битность торчит -- заголовок PE-header'а.
Здравствуйте, Слава, Вы писали:
С>Вы нативый оракловый клиент когда-нибудь трогали, взаимодействовали с ним?
Кстати искренне желаю, чтобы его аффтаров до конца жизни мучал понос Ни один другой компонент не являлся источником стольких проблем, как эта поделка криворуких кодерастов
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Это менее важная причина. Товарищ Точка выше уже описал главную причину, почему битность торчит -- заголовок PE-header'а.
K>Ты путаешь причину со следствием.
Не понял, чего путаю Заголовок PE требует битность, приходится ее всюду таскать. Для чего требуется битность PE заголовку -- дела давно минувших дней и неправда. Но это, увы, факт.
Здравствуйте, Sharov, Вы писали:
S>Не понял, чего путаю Заголовок PE требует битность, приходится ее всюду таскать. Для чего требуется битность PE заголовку -- дела давно минувших дней и неправда. Но это, увы, факт.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Не понял, чего путаю Заголовок PE требует битность, приходится ее всюду таскать. Для чего требуется битность PE заголовку -- дела давно минувших дней и неправда. Но это, увы, факт.
K>У тебя точно всё хорошо с логикой?
Еще разок. Причина -- необходимая битность PE-header'а, следсвтие -- managed код под windows может зависть от битности, хотя не должен. Где я ошибся?
Можно просто сказать, а не рожи крючитьфейспалмить.
Здравствуйте, Sharov, Вы писали:
S>Еще разок. Причина -- необходимая битность PE-header'а, следсвтие -- managed код под windows может зависть от битности, хотя не должен. Где я ошибся? S>Можно просто сказать, а не рожи крючитьфейспалмить.
Причина — необходимость загрузчику знать, какая среда исполнения нужна файлу, с тем, чтобы эту самую среду ему обеспечить перед запуском. Наличие флага — это следствие данной необходимости. Managed код под windows может зависить от битности только тогда, когда он использует компоненты, зависящие от битности. При этом сам managed код не становится каким-то особенным, отличающимся от "независящего", просто у него есть ограничения на то, в каком окружении он может работать.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Еще разок. Причина -- необходимая битность PE-header'а, следсвтие -- managed код под windows может зависть от битности, хотя не должен. Где я ошибся? S>>Можно просто сказать, а не рожи крючитьфейспалмить.
K>Причина — необходимость загрузчику знать, какая среда исполнения нужна файлу, с тем, чтобы эту самую среду ему обеспечить перед запуском. Наличие флага — это следствие данной необходимости. Managed код под windows может зависить от битности только тогда, когда он использует компоненты, зависящие от битности. При этом сам managed код не становится каким-то особенным, отличающимся от "независящего", просто у него есть ограничения на то, в какой окружении он может работать.
Благодарю, так яснее. Хотя не согласен в том, что managed код совсем уж не отличается. Я точно не уверен, но думается мне, зная target битность компилятор может получше провести оптимизацию байт кода, нежели в случае AnyCpu. Но я ничего не утверждаю, просто логично было бы предположить...
Здравствуйте, Sharov, Вы писали:
S>Благодарю, так яснее. Хотя не согласен в том, что managed код совсем уж не отличается. Я точно не уверен, но думается мне, зная target битность компилятор может получше провести оптимизацию байт кода, нежели в случае AnyCpu. Но я ничего не утверждаю, просто логично было бы предположить...
Это же легко проверить.
Тут ещё есть такой момент — даже если какие-то оптимизации по типу тех, о которых ты говоришь, и производятся, результирующий код всё равно остаётся переносимым между 32 и 64 битами. Ибо флаг битности можно поменять и без перекомпиляции (см. corflags.exe), при этом сборка остаётся работоспособной (опять же, при условии, что у неё нет платформо-зависимых dependencies).
Здравствуйте, Sharov, Вы писали:
S>Благодарю, так яснее. Хотя не согласен в том, что managed код совсем уж не отличается. Я точно не уверен, но думается мне, зная target битность компилятор может получше провести оптимизацию байт кода, нежели в случае AnyCpu. Но я ничего не утверждаю, просто логично было бы предположить...
Компилятору исходного языка в IL всё равно, на какой платформе будет исполняться код, это не его дело. А JIT-компилятору на флажок тоже плевать, потому что к моменту, когда он выходит на сцену, процесс нужной битности уже создан. Так что он без всяких флажков знает, на какой платформе он работает.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Благодарю, так яснее. Хотя не согласен в том, что managed код совсем уж не отличается. Я точно не уверен, но думается мне, зная target битность компилятор может получше провести оптимизацию байт кода, нежели в случае AnyCpu. Но я ничего не утверждаю, просто логично было бы предположить...
K>Это же легко проверить. K>Тут ещё есть такой момент — даже если какие-то оптимизации по типу тех, о которых ты говоришь, и производятся, результирующий код всё равно остаётся переносимым между 32 и 64 битами. Ибо флаг битности можно поменять и без перекомпиляции (см. corflags.exe), при этом сборка остаётся работоспособной (опять же, при условии, что у неё нет платформо-зависимых dependencies).
Этот аргумент + дискуссии на SO убедили меня, что я не прав с платформенными оптимизациями.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, AlexRK, Вы писали:
ARK>>Здравствуйте, Serginio1, Вы писали:
S>>>Так самый смех заключается в том, что с NGEN и CLR не подходит пот терминалогию VM так как выполняется код под конкретную платформу.
ARK>>Это ничего не значит. "Виртуализировать некоторую платформу" можно любым способом, главное, что эта платформа (IL) в принципе есть. Остальное неважно — интерпретируется IL, компилируется или вычисляется вручную кучей китайцев в подвале. S> Ну дык под это определение подходит и C++. Он тоже кросс-платформенный и компилируется. Ничем IL от C++ не отличается. Просто он более низкоуровневый.
У вас все перемешалось, надо вам прочитать какю-нить литературу.
Вы путаете языки программирования, интерпретатор, компилятор, среду исполнения, байт код, виртуальную машину и мне кажется даже OS.
1 язык программирования надеюсь нет смысла объяснять
2 Интерпретатор — читает текст программы как есть и выполняет инструкцию (для c, c++, perl, ... есть интерпретатор)
например bash тоже интерпретатор не переводит даже в машинный код, или tcsh — этот shel тоже является
интерпретатором но "C" языка. Первые движки javascrip тоже являлись только интерпретатором. Конечно теперь у javascrip есть виртуальная машина и компилятор.
У Perl есть и интерпретатор и виртуальная машина и даже может компилить в нативные инструкции процессора (машинный код). Хотя когда запускаете perl script то идет компиляция на лету в байт код и потом виртуальная машина PERL исполняет этот код.
3 компилятор преобразует исходный текст программы в машинный код или в код виртуальный
машины (по другому абстрактной как раз этот код потом исполняется виртуальной машиной например Java, perl, Lua, .Net, ...)
как понимаешь виртуальная машина не абстрактное понятие а конкретное приложение и исполняет конкретный байт код
который сформировал соответствующий конкретный компилятор из конкретного языка программирования
4а среда исполнения может быть как непосредственно процессор (частенько в микроконтроллерах программа работает напрямцю с процессором без каких либо OS), но может средой исполнения быть и процессор в связке OS который может предложить дополнительные удобства. Например загрузку или выгрузку программы и дополнительно предложить готовые
функции по вводу и выводу и также функции по доступу к оборудованию.
4б Но средой исполнения, например для байт кода, может выступать и виртуальная машина, которая кроме исполнения
байт кода может предложить и дополнительные услуги,компиляция в нативный код, сборщик мусора, доступ к
оборудованию (например звуковой карте и т.д.)
5 байт код (абстрактный код или виртуальный код т.к. нет такой машины с электрической схемой которая могла бы выполнить этот код) как мы уже сказали может быть получен путем компиляции в байт код (прошу заметить в независимый код от процессора системы на котором будет запускаться данное приложение).
Но то что сегодня этот байт код является виртуальной сегодня то завтра может быть сделан специальный
процессор для этого кода. Так случилось с Java-ой т.к. для байт кода Java создали процессор.
6 Виртуальная машина это программа которая является прослойкой между байт кодом и процессором.
виртуальная машина берет байт код и выполняет на целевой системе "интерпретируя" этот код, но заметьте виртуальная машина при этом не становится интерпретатором. Ранее мы уже сказали что интерпретатор анализирует текст программы а не байт код, само слово "код" — и есть ключевое понятие машины и в данном случае виртуальной.
S>>>В CLR весь код компилируется при первом обращении к классу.
ARK>>После этого CLR можно отключать? ARK>>Правда после отключения мы захотели обратиться еще к одному классу и... S>Ну скомпилировали через NGEN и JIT компиляцию можно отключать (если конечно нет рефлексии к неподгруженным сборкам) S> CLR это не только JIT но и менеджер памяти и сборка мусора. Аналог CLR только оптимизированный есть и в .Net Native.
Здравствуйте, Serginio1, Вы писали:
S>Это все интересно. Ответь для себя CIL это язык или Байт код? S>NGEN это скомпилированный код или КОД для VM?
Да всё правильно tranzit расписал. Терминология не совпадает с официальной от MS, да.
С CIL вечно путаница — под ним понимают и CIL bytecode и CIL как язык, из контекста обычно понятно. Ув. tranzit, очевидно, имел в виду первое.
Ну и вместо VM обычно используется или execution engine (если речь про конкретную реализацию) или virtual execution system (если речь об абстрактном описании аля ECMA-335).
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>Это все интересно. Ответь для себя CIL это язык или Байт код? S>>NGEN это скомпилированный код или КОД для VM?
S>Да всё правильно tranzit расписал. Терминология не совпадает с официальной от MS, да. S>С CIL вечно путаница — под ним понимают и CIL bytecode и CIL как язык, из контекста обычно понятно. Ув. tranzit, очевидно, имел в виду первое.
S>Ну и вместо VM обычно используется или execution engine (если речь про конкретную реализацию) или virtual execution system (если речь об абстрактном описании аля ECMA-335).
Угу
3 компилятор преобразует исходный текст программы в машинный код или в код виртуальный
машины (по другому абстрактной как раз этот код потом исполняется виртуальной машиной например Java, perl, Lua, .Net, ...)
как понимаешь виртуальная машина не абстрактное понятие а конкретное приложение и исполняет конкретный байт код
который сформировал соответствующий конкретный компилятор из конкретного языка программирования
Как это относится к NGEN?
4б Но средой исполнения, например для байт кода, может выступать и виртуальная машина, которая кроме исполнения
байт кода может предложить и дополнительные услуги,компиляция в нативный код, сборщик мусора, доступ к
оборудованию (например звуковой карте и т.д.)
Очень часто используется дополнительная компиляция и в нативном коде для обвязки не объектных Win Api (MakeObjectInstance в Delphi)
Опять же .Net Native предлагает сборку мусора. Она тоже VM? А про оборудование я так и не понял.
6 Виртуальная машина это программа которая является прослойкой между байт кодом и процессором.
виртуальная машина берет байт код и выполняет на целевой системе "интерпретируя" этот код, но заметьте виртуальная машина при этом не становится интерпретатором. Ранее мы уже сказали что интерпретатор анализирует текст программы а не байт код, само слово "код" — и есть ключевое понятие машины и в данном случае виртуальной.
NGEN под это определение не подходит.
Я бы нпросто назвал это среда выполнения. А VM пошло именно от Java, причем когда еще не было Jit компилятора.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Как это относится к NGEN?
ngen — это не компилятор, это часть VES.
S> Очень часто используется дополнительная компиляция и в нативном коде для обвязки не объектных Win Api
??? В смысле дополнительная компиляция? Обычные PIA (Primary Interop Assemblies), опционально встраиваются в саму сборку.
S>Опять же .Net Native предлагает сборку мусора. Она тоже VM? А про оборудование я так и не понял.
Именно поэтому MS предпочитает использовать термин execution engine, а не VM.
Если говорить про CLI как про абстрактную модель, то там VM разумеется присутствует, но когда дело доходит до готовых бинарников, то вся роль "VM" сводится к набору runtime services. Конкретный их состав зависит от таргетинга.
Простая аналогия: в принципе, ничего не мешает собирать JS сразу в натив, хотя бы для js-extensions браузеров. Что, js от этого перестанет быть языком, работающим в песочнице? Если смотреть на язык как на абстракцию — разумеется нет, но если сузить тему до конкретной реализации, то сова хоть и с треском, но на глобус натянется.
Тож самое — концепция владения в rust. Снова "песочница", которая обеспечивается только силами компилятора, без участия рантайма.
Народ постоянно путает логические абстракции с готовым кодом, отсюда и неразбериха.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Как это относится к NGEN? S>ngen — это не компилятор, это часть VES.
Но код то скомпилирован и JIT компиляции может и не быть, если нет рефлексии и подгрузки сборок. S>> Очень часто используется дополнительная компиляция и в нативном коде для обвязки не объектных Win Api S>??? В смысле дополнительная компиляция? Обычные PIA (Primary Interop Assemblies), опционально встраиваются в саму сборку.
Я про нативный код. Например в Delphi есть MakeObjectInstance в Delphi которя генерирует код для использования объектов в необъектных методах Win Api.
Я про то, что и в нативе существует аналог JIT. Но они VM не являются.
S>>Опять же .Net Native предлагает сборку мусора. Она тоже VM? А про оборудование я так и не понял. S>Именно поэтому MS предпочитает использовать термин execution engine, а не VM.
И я про это. S>Если говорить про CLI как про абстрактную модель, то там VM разумеется присутствует, но когда дело доходит до готовых бинарников, то вся роль "VM" сводится к набору runtime services. Конкретный их состав зависит от таргетинга.
И при этом CLI для .Net Native это аналог ассемблера. S>Простая аналогия: в принципе, ничего не мешает собирать JS сразу в натив, хотя бы для js-extensions браузеров. Что, js от этого перестанет быть языком, работающим в песочнице? Если смотреть на язык как на абстракцию — разумеется нет, но если сузить тему до конкретной реализации, то сова хоть и с треском, но на глобус натянется.
А вот CLI в .Net Native не работает в песочнице. S>Тож самое — концепция владения в rust. Снова "песочница", которая обеспечивается только силами компилятора, без участия рантайма.
S>Народ постоянно путает логические абстракции с готовым кодом, отсюда и неразбериха.
Ну опять же можно вспомнить Оберон так активно здеь когда то обсуждавшихся. Опять же Singularity https://ru.wikipedia.org/wiki/Microsoft_Singularity
Singularity — начатый в 2003 году проект исследовательского подразделения корпорации Майкрософт по созданию высоконадёжной операционной системы, в которой микроядро, драйверы устройств и приложения написаны на управляемом коде.
Отличительной особенностью данной ОС является использование идеологии программно-изолированных процессов (Software Isolated Processes, SIP), похожих на лёгкие процессы языка Erlang, общение между которыми происходит исключительно посредством сообщений. В отличие от традиционных ОС, защита таких процессов в Singularity производится не путём организации аппаратно-защищённых адресных пространств, а путём использования типобезопасного подмножества промежуточного языка (MSIL) и его верификации перед компиляцией в родной код процессора. Каждый SIP обладает своим объектным пространством, «сборщиком мусора» и средой периода исполнения. Для таких процессов не допускается совместное использование памяти, и они не имеют возможность модифицировать свой код, что усиливает гарантии надежности работы программы в SIP.
Низкоуровневый код обработки прерываний x86 написан на языке ассемблера и C. Библиотеки времени исполнения (англ. runtime) и сборщик мусора написаны на Sing# (специально доработанном для данного проекта диалекте C#) с использованием небезопасного режима (англ. unsafe mode). Также присутствует код на C, использующийся в целях отладки. BIOS компьютера вызывается только на этапе загрузки в 16-разрядном реальном режиме работы процессора. После перехода в 32-разрядный режим, BIOS больше никогда не вызывается, вместо него используются драйверы, написанные на Sing#. При установке ядра, оп-коды CIL компилируются в инструкции x86 при помощи компилятора Bartok.
Bartok [1] — это исследовательский проект по созданию на языке C# оптимизирующего компилятора из CIL в x86.
Singularity 1.0 была завершена в 2007 году. Исследовательский пакет Singularity 1.1 Research Development Kit (RDK) был выпущен под лицензией Shared Source и допускает академическое некоммерческое использование; пакет доступен на CodePlex. 14 ноября 2008 г. был выпущен Singularity RDK 2.0. Дальнейшая разработка прекращена.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А вот CLI в .Net Native не работает в песочнице.
Ну о чём я и говорил — не надо натягивать термины, которые относятся к абстрактному описанию "как работает дотнет" на конкретную реализацию. Полный бред получается.
CLI — это спецификация. Она не может "работать / не работать". Она или соблюдается, или не соблюдается. Как именно соблюдается: силами рантайма, компилятора или расстрелом нерадивых программистов — эт уже дело десятое и к самой спецификации никакого отношения не имеет.
