Здравствуйте, alexzzzz, Вы писали:

EP>>>Насколько я понял из темы — влияние сабжевых ключей на байткод это лишь неверное предположение — так зачем постоянно кивать в эту сторону?
A>·>Тут скорее всего проблема в том, что эти ключи вообще существуют.
A>Ключи существуют, чтобы решать конкретную проблему, которая Яве естественно тоже есть, но решает её там конечный пользователь самостоятельно.
A>http://stackoverflow.com/questions/9757456/java-native-interface-32-bit-dll-on-64-bit-system
Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок?

A>·>Наличие JNI и DLL-ек тоже не причина. System.loadLibrary просто выбирает подходящую нативную библиотеку под текущую платформу. Байткод-то тут причём?
A>Ну вот нет у тебя нативной библиотеки подо все платформы. Автор библиотеки скомпилировал её в 1995 году только под x86, а про x64 и x128 не догадался. Исходники стёр, сам застрелился, бекапы сгорели.
Ну запусти под 32 битной vm. Делов-то. А если таки есть? Что делать с x86 CIL-сборкой, если автор застрелился?

A>Но теперь тебе кровь из носу нужно, чтобы твоя программа могла загрузить эту нативную x86-библиотеку в ОС любой разрядности. Если на 64-разрядной ОС твоя программа будет автоматически запускаться как 64-разрядный процесс, как и куда она будет подгружать эту 32-разрядную библиотеку? Никак и никуда. Нужно будет параллельно поднять вспомогательный 32-разрядный процесс, загрузить библиотеку в него и организовать какую-нибудь связь между двумя полученными процессами.
A>Зачем такой геморрой? Достаточно в своей программе выставить флажок на запуск её в 32-разрядном виде всегда, независимо от разрядности ОС.
Не надо такой гемморой. Ведь на ОС запускается не сама программа, а vm. Просто запусти эту же программу под 32-битной VM. Ведь байт-код для этого и придумывали, чтобы можно было менять VM, используя те же bytecode-бинарики.

A>·>Понятно, но x86 это не байткод виртуальной машины, а машинный код конкретного железа. Зачем микрософт запихнула детали имплементации платформы на уроветь компилятора исходников — один Бг знает.
A>Был бы в Net дополнительно линковщик, запихнули бы в него. Кто пишет на диск финальный .exe, в того и пихать.
А, понятно откуда изолента торчит — запуск CIL-кода примотано к нативному.