Здравствуйте, Kolesiki, Вы писали:
K>>>Вот это-то и смешно! Откуда я знаю, в какой системе будет запущено приложение? EP>>Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать K>Какое дело байткоду какая битность у DLL??? Кто вообще сказал, что это будет виндовая библиотека?
В смысле "будет"? Она есть, и её надо использовать, и для этого нужен x32 процесс.
K>Давайте просто опишем процесс: K>1. Я пишу прогу, компиляю её в совершенно абстрактный байткод. Никаких битов, выравниваний и прочей чуши. Где будет запущено ПО — не знаю, может даже на arduino!
Целевая платформа .NET приложений обычно заранее известна.
K>2. VM, созданная специально для этой ОС, знает об окружении всё: битность, объём памяти, оборудование, способы линковки и т.п. И ей командуют "запусти этот шмот байткода".
Она не знает что лучше для конкретного приложения — x32 или x64.
K>Кто и как там вызывает 64-битный код из 5683-битного — БАЙТКОДУ ПОФИГ
Не пофиг например если идёт взаимодействие с native библиотеками
Не пофиг если хочется сэкономить память, или наоборот получить большее адресное пространство.
EP>>>> На x32/x64 разный объём доступной памяти, и разные размеры указателей K>>>Каким боком это должно касаться байткода? EP>>А оно касается? K>Судя по сеттингам студии — да.
Именно байт-кода? Или одного значения/флажка рядом с этим байт-кодом?
EP>>>> Плюс в x64 процесс нельзя загрузить x32 dll, которая может быть сторонней. K>>>Это вообще из мира венды. EP>>Это из мира реального железа, и справедливо в том числе и для Linux, и для OS X K>Реальное железо — причём тут оно?
При том что на нём в итоге и работает код, а не в сферическом вакууме, и у которого есть вполне осязаемые ограничения
K>Это не холивар, это абсолютно технический вопрос для выявления костылей .NET платформы.
Этот переключатель постоянно сбивает всех с толку.
На самом деле он никак не слияет на байткод, байт код генерится всегда.
Этот переключатель просто выставляет флаг в заголовке просто для того что бы сделать невозможным запуск вашего бинарника не не поддерживаемой системе. Почему она может быть не поддерживаемой — куча вариантов на самом деле
Здравствуйте, Kolesiki, Вы писали:
K>>>"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц) V>>Если Вам не надо — выбирайте AnyCPU. K>Выбрал. А студия, работая под 64-битной вендой, нарыгала мне 32-битную шнягу! В результате прога не смогла загрузить 64-битную DLL-ю (стороннюю).
Если это консольное приложение — снимите галку prefer 32 bit. Если не консольное — то так не бывает.
K> Так какой смысл во всей этой .NET-тряхомудии??
Смысл — он у каждого свой
K>Писал бы себе на Delphi и имел бы ровно те же грабли, но на порядок больших скоростях и точно зная, чего ожидать. (это не говоря об ожиданиях по портированию приложений под mobile!)
А что, кто-то заставляет? Пишите на Delphi, не думаю, что кто-то здесь будет против.
Кстати, там SEH, уже научились корректно поддерживать?
V>>Всё выполняется в конечном счёте на "битах, процессорах и прочей чуши". K>Ну просто открыл глаза, чо! Ну то есть создатели JVM — они дураки, думали их виртуальная машина сама из проца выросла?
А что, в жабе вы можете загрузить 32-битную dll в 64-битный процесс и наоборот?
V>> Хотите, чтобы выполнялось хорошо — приходится думать и об этом. K>Вот именно, что НЕ ХОЧУ.
Ну, каждому своё. Не хотите думать — используйте более высокоуровневые инструменты.
V>>Программе не надо работать "очень быстро", ей надо работать "приемлемо быстро", что и позволяет дотнет.
Это кому как. Мне вот часто приходится думать о том, как сделать, чтобы работало быстро.
V>>Почему я должен думать обо всех этих битах? Были бы мне нужны биты, сидел бы и сипипискал до сих пор! В ДотНЕТ люди приходят именно за этим — вылезти из 20 века и начать уже жить алгоритмами, а не "32-битными dll-ками".
У вас просто ожидания от .NET не совпали с реальностью. Может, проблема в завышенных ожиданиях?
V>>Волшебной палочки не бывает, полной изоляции от аппаратуры добиться невозможно. K>JVM.
Да ну, серьёзно и в java native тоже? Если вы скажете, что "не надо использовать вызовы нативных функций" то я скажу "так и в .NET их можно не использовать, выбирайте тогда AnyCPU с отключенной опцией prefer 32 bit"
K>>>Попутно похерив весь свой мобильный сегмент. V>>Это к данному вопросу вообще отношения не имеет K>Ещё как имеет! Имеющий нормальное зрение, да узрит: имей мы нормальный ДотНЕТ, приложения можно было бы просто копировать в телефон и запускать! (как сейчас Java и делает) Увы, микрософту сии мечты не видать как ушей — они сами сознательно шли к своему "портируемому одноплатформенному болоту".
Мобильный сегмент там похерен вообще не из-за .NET.
Здравствуйте, Sharov, Вы писали:
V>>Тgen существует давно, его просто доработали до автоматического удобного использования. Это не так чтоб очень новое. S>NGEN
да, опечатался
Здравствуйте, Lexey, Вы писали:
L>Бг.... Попробуй JNI попользовать в столь любимой тобой яве. Неожиданно окажется, что не только под виндами нативные dll'ки могут иметь разную битность.
Большая часть java-программистов в жизни ни разу JNI не коснулись. И слава богу, pure-java решения как правило лучше себя ведут.
LVV>>Фактически интерпретатора (jit-компилятора). LVV>>Я ж так понимаю, что он весь целиком лежит в исполняемом файле.
K>А вот и не угадал! Мы для того и ставим дотнетину под сотню мег, чтобы ОНА занималась всем этим джитом и оптимизациями. K>Мы, как наивные простофили, верили рассказам "джит может оптимизировать код под платформу, где исполняется", а на самом деле он даже MMX не задействовал!! Вот такая вот халтура под маркетоидным соусом. K>PS K>Про MMX могу ошибаться, но суть вы поняли — джитнутый код очень далёк от кода, который МОГ БЫ оптимально исполняться на текущем CPU.
Да это пофигу.
Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать.
То, есть там все равно есть минимальная часть двоичных кодов.
Которая в процессе работы может загружать хоть черта лысого.
Вот эта минимальная часть тоже может быть 32-битной или 64-битной.
И библиотеки загружать соответствующие, как тут уже ранее отметили.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Kolesiki, Вы писали:
K>PS K>Это не холивар, это абсолютно технический вопрос для выявления костылей .NET платформы.
в проекте есть зависимости от 32-х битных нативных DLL\OCX, переделывать которые в 64бита никто не собирается, т.к. не нужно. Как без явного указания битности использующей их сборки решить эту инженерную проблему? Поведай нам, местный юродивый
В принципе всё правильно, но сам импорт на mscoree.dll как и любой нативный стаб — по сути легаси механизм на всякий случай, а начиная с Windows XP+ загрузчик в ОС уже и сам осведомлен о native / .net executable. В противном случае, думается мне никакого бы AnyCPU не было бы.
Здравствуйте, LaptevVV, Вы писали:
LVV>Вот эта минимальная часть тоже может быть 32-битной или 64-битной. LVV>И библиотеки загружать соответствующие, как тут уже ранее отметили.
In a .NET executable, the PE code section contains a stub that invokes the CLR virtual machine startup entry, _CorExeMain or _CorDllMain in mscoree.dll
Я кстати предпочитаю когда интерпретаторы вызываются нормальным/внешним образом.
Но и решение .net процессы сделать родными — так же считаю правильным: безбожные вызовы GetModuleHandle(NULL) работают, нормальные имена процессов в task manager, да и вообще запуск безовсяких приседаний... Всё таки хорошая интеграция, с минимумом усилий.
Впрочем с .net core, насколько я понимаю об этом можно забыть.
PS: Проблема незаметная, но это до тех пор, пока third-party нативная библиотека не пытается получить базовый путь к программе, а получает какой-нибудь /usr/bin.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, vmpire, Вы писали:
K>>>"Что это за биты? Что это за "prefer"? Нам таких не надо, диско-суперстар!" (ц) V>>Если Вам не надо — выбирайте AnyCPU.
K>Выбрал. А студия, работая под 64-битной вендой, нарыгала мне 32-битную шнягу! В результате прога не смогла загрузить 64-битную DLL-ю (стороннюю).
Раз зависимости имеют привязку к архитектуре платформы, то надо выбирать конкретную архитектуру. Для этого тебе и предлагают выбор.
Здравствуйте, fddima, Вы писали:
F>PS: Проблема незаметная, но это до тех пор, пока third-party нативная библиотека не пытается получить базовый путь к программе, а получает какой-нибудь /usr/bin.
.Core сейчас для веба / UWP, там без вариантов надо использовать фирменное API для получения путей к контенту (при этом бинарники могут быть запулены куда угодно).
Оно и для текущего дотнета с ShadowCopyFiles в домене актуально, но встречается гораздо реже.
Здравствуйте, Vladek, Вы писали:
K>>Выбрал. А студия, работая под 64-битной вендой, нарыгала мне 32-битную шнягу! В результате прога не смогла загрузить 64-битную DLL-ю (стороннюю).
V>Раз зависимости имеют привязку к архитектуре платформы, то надо выбирать конкретную архитектуру. Для этого тебе и предлагают выбор.
Я и спрашиваю, а какой тогда вообще смысл в VM??? Только чтобы MS похвалилась тысячей языков? VM — это и есть АБСТРАКЦИЯ НАД ВСЕМ. Если мы сильно терям в скорости, то и получить за это мы должны полную независимость: написал код — и ВООБЩЕ НИКОГДА не париться о том, где и как он будет работать и кого вызывать. Это не моё дело, что криворукие индусы напилили в венде — сами написали — сами пусть и расхлёбывают, а не вешают СВОИ ПРОБЛЕМЫ НА НАС.
Здравствуйте, LaptevVV, Вы писали:
LVV>Только в результате трансляции с студии мы все равно имеем исполняемый файл, который загружается загрузчиком оси, и начинает работать.
Неужели это единственное решение, которое пришло вам в голову? А как же *.class файлы в джабе? Им ВНЕЗАПНО не надо быть ни исполняемым кодом, ни даже быть в PE-формате. Чудеса, да?
Здравствуйте, consign, Вы писали:
C>Здравствуйте, Kolesiki, Вы писали:
K>>Итак, вопрос капсом выше.
C>Там вся реальная разница — это флажок у экзешника "в каком режиме запускать". Байткод абсолютно одинаковый.
С позиции землеройки — да. Чуть выше на уровень и опять вопрос: зачем мне ДАЖЕ ОДИН БИТ, если моя виртуальная машина обязана исполнять абстрактный код?
Давайте, заведите опять шарманку про 32/64-битные DLL... и я опять спрошу: а если это Arduino? Linux? Эльбрус? Какое мне вообще дело, даже если там 13-битный ЦПУ??
Здравствуйте, Kolesiki, Вы писали:
Еще она вещь, это использование Интеропа. Например для .Net Core SqlClient используются нативные библиотеки для каждой оси.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Tom, Вы писали:
Tom>Этот переключатель просто выставляет флаг в заголовке просто для того что бы сделать невозможным запуск вашего бинарника не не поддерживаемой системе. Почему она может быть не поддерживаемой — куча вариантов на самом деле
Искать отмазы костылям (а на самом деле глупости и лени) — можно всегда и везде. Почему жабовским *.class'ам не нужны битности, объясните?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Kolesiki, Вы писали: K>>>>Вот это-то и смешно! Откуда я знаю, в какой системе будет запущено приложение? EP>>>Такое что в x64 системе может работать x32 код. И что лучше для твоего конкретного приложения среда может и не знать K>>Какое дело байткоду какая битность у DLL??? Кто вообще сказал, что это будет виндовая библиотека?
EP>В смысле "будет"? Она есть, и её надо использовать, и для этого нужен x32 процесс.
А какое отношение это имеет к байткоду? Ну да, есть говновенда на костылях и изоленте, где ничего не работает, если не закостылить правильные переходники между 32/64. Скажите, вы для этого учились 6 лет паттернам и алгоритмам? Чтобы выйти в реал и заниматься этим навозным копанием? Я считаю, в программинге есть куда более важные задачи и это была прямая обязанность .NET-клепателей — сделать бесшовную интеграцию VM и окружения.
EP>Целевая платформа .NET приложений обычно заранее известна.
Ерунду не пишите. Я пишу код, где он будет исполняться — полностью ЗАВИСИТ ОТ ЮЗЕРА.
K>>2. VM, созданная специально для этой ОС, знает об окружении всё: битность, объём памяти, оборудование, способы линковки и т.п. И ей командуют "запусти этот шмот байткода".
EP>Она не знает что лучше для конкретного приложения — x32 или x64.
Да потому что нет никакой разницы! У 99% приложений вообще можно "положить на битность". А если уж она так важна, зачем тогда лезть в .NET? Там, где архитектура/скорость начинает играть роль, там нет места для VM.
EP>Именно байт-кода? Или одного значения/флажка рядом с этим байт-кодом?
Не имеет значения, на выходе всё равно получишь жёстко ориентированный на битность код.
K>>Реальное железо — причём тут оно? EP>При том что на нём в итоге и работает код, а не в сферическом вакууме, и у которого есть вполне осязаемые ограничения
Опять отсылаю к значению слова "виртуальный" в понятии VM.
Ну то есть создатели JVM — они дураки, думали их виртуальная машина сама из проца выросла?
.jpg)
