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

·>В яве этого бреда нет и не надо. Битность таргет-платформы JVM вообще никак не относится к тому как компилится исходный код.

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

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

Но теперь тебе кровь из носу нужно, чтобы твоя программа могла загрузить эту нативную x86-библиотеку в ОС любой разрядности. Если на 64-разрядной ОС твоя программа будет автоматически запускаться как 64-разрядный процесс, как и куда она будет подгружать эту 32-разрядную библиотеку? Никак и никуда. Нужно будет параллельно поднять вспомогательный 32-разрядный процесс, загрузить библиотеку в него и организовать какую-нибудь связь между двумя полученными процессами.

Зачем такой геморрой? Достаточно в своей программе выставить флажок на запуск её в 32-разрядном виде всегда, независимо от разрядности ОС.

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