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

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

A>·>У программиста (возможно у другого) проблема будет только лишь собрать дистрибутив под соответствующую платформу, даже возможно с bundled VM, ну чтобы пользователю не надо было, как обычно, трахаться с установкой правильной версии .net-фреймворка, а затем развлекаться с Microsoft .NET Framework Repair® Tool™.
A>·>Но это сборка дистрибутива, а не компиляция шарп-кода. Каждому шагу процесса соответствующие вопросы, а не текучие абстракции.
A>Программу с правильно установленным флажком достаточно просто скачать и запустить. Щёлкнуть два раза мышкой по .exe, и он весело запустится. Если программисту хочется потрахаться, он всегда найдёт где.
Неправда. Надо ещё откуда-то .net framework взять. Притом правильной версии и битности. И чтобы он поставился нормально. И чтобы не поломался случайно.

A>>>При таком отношении к пользователю не удивительно, что Ява на десктопах начинается и заканчивается на Майнкрафте.
A>·>Обилие шарп-софта на десктопе я наблюдаю только в корпоративной среде, где всё и так ставят админы.
A>Админ тоже человек и терпеть не может программы, которые хотят странного. Когда есть выбор, предпочитает ту, которая минимально парит ему мозг. Если бы программисты знали, что админы о них думают (иногда вслух)...
Обычно java-based программы ставятся распаковкой архива. Куда уж проще...
А наличие Microsoft .NET Framework Repair® Tool™ ни на что не намекает?

A>>>А я знаю, есть или нет? Я пользователь. Ты ж программист, давай, я тебе в субботу позвоню, а ты мне по телефону всё починишь? В понедельник утром уже сдавать отчёт, а ничего не работает. Что конкретно не работает? Ничего не работает.
A>·>Такому пользователю даёшь .zip или setup.exe, который распаковывает всё что надо, включая нативные либы и jvm, и можно запускать приложение.
A>Просто выставить x86 недостойно или другой работы мало? Или раз в Яве этого нет, то ненужно?
Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба. Решение о таргет-платформе должно приниматься во время деплоймента, а не во время компиляции.

A>>>1. Либо она под x64 в принципе неработоспособна, потому что, например, в свою очередь зависит от x86-only нативной библиотеки. Тогда делаешь свою программу тоже x86-only, другого варианта всё равно нет.
A>·>А если попалась библиотека x86+x64, но не ARM и Itanium? Что делать?
A>Во-первых, так не бывает.
Почему не бывает? Программ которые пишут под x86/x64 — полно, а вот ARM/Itanium — экзотика.

A>Во-вторых, в этом пункте рассмотрена ситуация, когда ограничение выставлено осознанно разработчиком библиотеки ― ему виднее, где она работоспособна, а где нет. Если считаешь, что знаешь это лучше разработчика, переходишь к пункту 2.
Вот разработчик видит: "эта нужная мне либа имеет .dll-ки под Intel-ы 32 и 64. Но ARM не умеет". Как разработчик поставит флажок?

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

O>·>Ну запускай своё приложение на x32 vm. В чём проблема-то?
O>Этот флажок и есть подсказка запускать приложение на x32 VM, коей в грубом приближении и является wow64 подсистема
Это понятно. Непонятно почему этот флажок требуется на этапе компиляции проекта, а не его дистрибуции.

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

O>·>Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок?
O>Потому что CIL сборка использует в качестве контейнера PE формат. У этого контейнера есть опция — запускать в 32 битах или 64 битах. Используя циркуль, буханку хлеба и hiew можно этот флажок поменять в уже собранном ехе-шнике, но зачем?
Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...

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

·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...
И получилось отлично: .NET процессы видны в таск менеджере со своими нормальными именами безовсяких приседаний, GetModuleHandle(NULL) и прочий API работает. В добавок AnyCPU никто не отменял, чего по три круга ходить-то.

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

F>·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...
F> И получилось отлично: .NET процессы видны в таск менеджере со своими нормальными именами безовсяких приседаний, GetModuleHandle(NULL) и прочий API работает. В добавок AnyCPU никто не отменял, чего по три круга ходить-то.
Отлично для платформо-зависимого решения, к платформо-независимым языкам это не подходит. Где там ваш GetModuleHandle на non-windows платформах?

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

С>Реплика в сторону — однако же, что такое трамблёр, шрус, дром.ру, курс доллара и соединение металлопластика "под пресс" — этот пользователь таки выучил. Иногда после того, как лишился изрядного количества денег и нервов. И про яву выучит, не бином Ньютона.
Моя жена из этого только про курс доллара знает, и то, чисто умозрительно. Сам я остальные слова знаю, но в основном как тяжелое легаси, в практической области не сталкиваюсь уже лет 10, а потенциально сам могу только с шрусом столкнуться в качестве покупки, как его приделывать разбираться не собираюсь.

O>>·>Ну понятно, раз нет нативных бинарников под данную платформу — их надо либо поставить, либо запустить под 32 бита. Зачем это делать программисту во время билда CIL-сборок?
O>>Потому что CIL сборка использует в качестве контейнера PE формат. У этого контейнера есть опция — запускать в 32 битах или 64 битах. Используя циркуль, буханку хлеба и hiew можно этот флажок поменять в уже собранном ехе-шнике, но зачем?
·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...
Ну, на самом деле тот флажок в РЕ заголовке — архитектура процессора, там помимо интела 32/64 что угодно может быть, так что примотать могли и по другому, прописав туда процессор некий пусть будет CIL_MACHINE.
Но дело тут такое — х64 винда с дотнетом это на некотором уровне приближения две винды с двумя дотнетами — 32хбитная винда с 32хбитным дотнетом и 64 битная винда с 64хбитным дотнетом. И как тут выбрать на чем работать?

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

O>·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...
O>Ну, на самом деле тот флажок в РЕ заголовке — архитектура процессора, там помимо интела 32/64 что угодно может быть, так что примотать могли и по другому, прописав туда процессор некий пусть будет CIL_MACHINE.
O>Но дело тут такое — х64 винда с дотнетом это на некотором уровне приближения две винды с двумя дотнетами — 32хбитная винда с 32хбитным дотнетом и 64 битная винда с 64хбитным дотнетом. И как тут выбрать на чем работать?
Понятно. Т.е. в итоге сабж это не продуманное архитектурное решение, а необходимость как-то бороться с platform-hell в винде.
Скажем, в дистрибутив java приложения делается специальный launcher (или несколько) под конкретную платформу (app.exe/app.sh/etc), а само приложение обычно кладётся как jar рядышком.

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

F>>·>Ну да, это я уже понял откуда свисает изолента. Они примотали потенциально платформонезависимый артефакт (CIL-сборку) к платформозависимому PE-формату. Ну и получилось что получилось...
F>> И получилось отлично: .NET процессы видны в таск менеджере со своими нормальными именами безовсяких приседаний, GetModuleHandle(NULL) и прочий API работает. В добавок AnyCPU никто не отменял, чего по три круга ходить-то.
·>Отлично для платформо-зависимого решения, к платформо-независимым языкам это не подходит. Где там ваш GetModuleHandle на non-windows платформах?
Язык (C#) и так платформо-независим. А .NET кроме как на виндовс и нет нигде. Остальные же кушают те же самые модули как им нравится, в mono даже есть некоторые расширения навроде dllmap.
Или полагаешь, что если платформонезависимый артефакт прикрутить к "платформонезависимому" эльфу то будет лучше? Или если прикрутить в свой формат — будет лучше? Чё-то в рамках .NET и Виндовс в частности выигрыша вообще не видно. А всякие там нативные лаунчеры вокруг дотнета и так никто не мешает делать, но нужно это очень редко.

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

A>>Программу с правильно установленным флажком достаточно просто скачать и запустить. Щёлкнуть два раза мышкой по .exe, и он весело запустится. Если программисту хочется потрахаться, он всегда найдёт где.
·>Неправда. Надо ещё откуда-то .net framework взять. Притом правильной версии и битности. И чтобы он поставился нормально. И чтобы не поломался случайно.

Инсталлятор, да, лучше приложить, хотя Net Framework часто уже есть. С правильной битностью в Net Framework проще ― инсталляторы ставят сразу оба варианта, где это практически возможно.

·>Обычно java-based программы ставятся распаковкой архива. Куда уж проще...

С дополнительным exe-шничком, который собственно и запускает программу на правильной версии Явы, если она есть. Дополнительных exe-шничков в Net тоже можно налепить, была бы необходимость.

·>А наличие Microsoft .NET Framework Repair® Tool™ ни на что не намекает?

Не-а. Ещё не видел сломанного Net Framework, кроме трёх компьютеров, на которых вирус Expiro прошёлся по всем exe-шникам. Если бы Net Framework там реально использовался, Repair Tool был бы полезен, наверное.

У меня дома долго висела Java 8 Update 73 (64-bit), которая ни работать не хотела, ни удаляться. Сейчас про неё вспомнил, пришлось грохать папку и чистить следы вручную. Java Repair Tool не нашёл.

A>>Просто выставить x86 недостойно или другой работы мало? Или раз в Яве этого нет, то ненужно?
·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба.

Тут раз двадцать уже написали, что флажок нужен/полезен только для тех случаев, когда у программы имеется жёсткая зависимость от какого-либо компонента, существующего только под одну конкретную платформу. Ну не работает твоя программа в режиме x64. Ей не нужно делать специальных ярлычков. Ставишь platform:x86 ― и теперь она знает сама как ей правильно запускаться на 64.

·>Решение о таргет-платформе должно приниматься во время деплоймента, а не во время компиляции.

Он НЕ требуется на этапе компиляции проекта. Можешь выставить потом, когда захочешь, если надо.

A>>·>А если попалась библиотека x86+x64, но не ARM и Itanium? Что делать?
A>>Во-первых, так не бывает.
·>Почему не бывает? Программ которые пишут под x86/x64 — полно, а вот ARM/Itanium — экзотика.
A>>Во-вторых, в этом пункте рассмотрена ситуация, когда ограничение выставлено осознанно разработчиком библиотеки ― ему виднее, где она работоспособна, а где нет. Если считаешь, что знаешь это лучше разработчика, переходишь к пункту 2.
·>Вот разработчик видит: "эта нужная мне либа имеет .dll-ки под Intel-ы 32 и 64. Но ARM не умеет". Как разработчик поставит флажок?

Конкретно такой комбинации не бывает, чтобы «x86+x64, но не ARM и Itanium». Там либо конкретная платформа, на которую программа заточена, либо AnyCPU.

 /platform:<string>            Limit which platforms this code can run on: x86,
                               Itanium, x64, arm, anycpu32bitpreferred, or
                               anycpu. The default is anycpu.

Но в любом другом случае: CorFlags.exe

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

A>·>Неправда. Надо ещё откуда-то .net framework взять. Притом правильной версии и битности. И чтобы он поставился нормально. И чтобы не поломался случайно.
A>Инсталлятор, да, лучше приложить, хотя Net Framework часто уже есть. С правильной битностью в Net Framework проще ― инсталляторы ставят сразу оба варианта, где это практически возможно.
А часто и нет. Или 3 версии, а надо 4ю. и т.п.

A>·>Обычно java-based программы ставятся распаковкой архива. Куда уж проще...
A>С дополнительным exe-шничком, который собственно и запускает программу на правильной версии Явы, если она есть. Дополнительных exe-шничков в Net тоже можно налепить, была бы необходимость.
Обычно есть опция скачать архив с bundled jvm, чтобы не искать "правильную версию".

A>·>А наличие Microsoft .NET Framework Repair® Tool™ ни на что не намекает?
A>Не-а. Ещё не видел сломанного Net Framework, кроме трёх компьютеров, на которых вирус Expiro прошёлся по всем exe-шникам. Если бы Net Framework там реально использовался, Repair Tool был бы полезен, наверное.
Ну наверное Микрософту делать нечего было, ну и запилили на выходных эту тулзу ради прикола.

A>У меня дома долго висела Java 8 Update 73 (64-bit), которая ни работать не хотела, ни удаляться. Сейчас про неё вспомнил, пришлось грохать папку и чистить следы вручную. Java Repair Tool не нашёл.
А какие там следы-то?

A>·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба.
A>Тут раз двадцать уже написали, что флажок нужен/полезен только для тех случаев, когда у программы имеется жёсткая зависимость от какого-либо компонента, существующего только под одну конкретную платформу. Ну не работает твоя программа в режиме x64. Ей не нужно делать специальных ярлычков. Ставишь platform:x86 ― и теперь она знает сама как ей правильно запускаться на 64.
В данном случае нет "правильного". Правильность зависит от того, как пользователь хочет её использовать.

A>·>Решение о таргет-платформе должно приниматься во время деплоймента, а не во время компиляции.
A>Он НЕ требуется на этапе компиляции проекта. Можешь выставить потом, когда захочешь, если надо.
Т.е. "/platform (C# Compiler Options)" это не опция компилятора, т.е. тулзы, которая компилирует?

A>·>Почему не бывает? Программ которые пишут под x86/x64 — полно, а вот ARM/Itanium — экзотика.
A>>>Во-вторых, в этом пункте рассмотрена ситуация, когда ограничение выставлено осознанно разработчиком библиотеки ― ему виднее, где она работоспособна, а где нет. Если считаешь, что знаешь это лучше разработчика, переходишь к пункту 2.
A>·>Вот разработчик видит: "эта нужная мне либа имеет .dll-ки под Intel-ы 32 и 64. Но ARM не умеет". Как разработчик поставит флажок?
A>Конкретно такой комбинации не бывает, чтобы «x86+x64, но не ARM и Itanium». Там либо конкретная платформа, на которую программа заточена, либо AnyCPU.
Комбинация, очевидно, бывает. Заточить программу можно под некое подмножество платформ. Просто компилятор так не умеет.

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

·>Ну наверное Микрософту делать нечего было, ну и запилили на выходных эту тулзу ради прикола.

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

A>>У меня дома долго висела Java 8 Update 73 (64-bit), которая ни работать не хотела, ни удаляться. Сейчас про неё вспомнил, пришлось грохать папку и чистить следы вручную. Java Repair Tool не нашёл.
·>А какие там следы-то?

В реестре. Из-за которых Java всё ещё висела в списке установленных программ, и из-за которых java-программа, которую я скачал для проверки, при запуске писала что-то типа «Ява вроде есть, а вроде и нет, запускаться не буду».

A>>Тут раз двадцать уже написали, что флажок нужен/полезен только для тех случаев, когда у программы имеется жёсткая зависимость от какого-либо компонента, существующего только под одну конкретную платформу. Ну не работает твоя программа в режиме x64. Ей не нужно делать специальных ярлычков. Ставишь platform:x86 ― и теперь она знает сама как ей правильно запускаться на 64.
·>В данном случае нет "правильного". Правильность зависит от того, как пользователь хочет её использовать.

В двадцать первый раз написать? Программа не работает в режиме x64. Не потому что программист ― сволочь, а потому что объективно не работает. С таким же успехом пользователь может хотеть две тонны золота в слитках.

A>>·>Решение о таргет-платформе должно приниматься во время деплоймента, а не во время компиляции.
A>>Он НЕ требуется на этапе компиляции проекта. Можешь выставить потом, когда захочешь, если надо.
·>Т.е. "/platform (C# Compiler Options)" это не опция компилятора, т.е. тулзы, которая компилирует?

Кто тебя требует её указывать во время компиляции? Никто. Хочешь принять решение позже? Принимай. Хочешь изменить уже принятое решение? Изменяй.

/out:<file>                   Specify output file name (default: base name of
                              file with main class or first file)

К опции out есть аналогичные претензии?

А что, к IL отношения не имеет, но тем не менее зачем-то является опцией компилятора. Можно не указывать, но значение по умолчанию будет всё равно. Какой идиот придумал указывать имя файла на стадии компиляции? Можно ведь задавать правильное имя файлу во время деплоимента. Собрать специальный инсталлятор, чтобы он выставлял правильное имя файла прямо на машине пользователя. А также делал два ярлычка на рабочем столе.

A>>Конкретно такой комбинации не бывает, чтобы «x86+x64, но не ARM и Itanium». Там либо конкретная платформа, на которую программа заточена, либо AnyCPU.
·>Комбинация, очевидно, бывает. Заточить программу можно под некое подмножество платформ. Просто компилятор так не умеет.

А зачем? У тебя есть волшебная нативная dll, код которой можно загрузить и в x86-процесс, и в x64-процесс и он везде будет работать?

O>>Но дело тут такое — х64 винда с дотнетом это на некотором уровне приближения две винды с двумя дотнетами — 32хбитная винда с 32хбитным дотнетом и 64 битная винда с 64хбитным дотнетом. И как тут выбрать на чем работать?
·>Понятно. Т.е. в итоге сабж это не продуманное архитектурное решение, а необходимость как-то бороться с platform-hell в винде.
·>Скажем, в дистрибутив java приложения делается специальный launcher (или несколько) под конкретную платформу (app.exe/app.sh/etc), а само приложение обычно кладётся как jar рядышком.
JRE тоже может быть несколько на системе, а может быть одна. С .нет ситуация более предсказуемая, потому разработчикам дали рычажок.

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

·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба.
И что выберет домохозяйка?

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

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

Ops>·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба.
Ops>И что выберет домохозяйка?

С IDEA — это уже не домохозяйка. А то давайте еще обсудим особенности работы домохозяйки с sbt, которому на 32битной яве стэка не хватает.

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

С>С IDEA — это уже не домохозяйка. А то давайте еще обсудим особенности работы домохозяйки с sbt, которому на 32битной яве стэка не хватает.

Попался. В том-то и дело, что IDEA для спецов, потому и выбор предлагает. А как быть с книгой кулинарных рецептов? Предложить выбор, какой битности должен быть ярлык, или может проще самому решить, заранее, избежав лишних вопросов в поддержку?

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

Ops>·>Это бессмысленно. Скажем в IDEA можно во время установки выбрать галочками какие ярлыки запуска помещать на рабочий стол — x84, x64 или оба.
Ops>И что выберет домохозяйка?
Домохозяйка может и не выбирать. Дистрибутив содержит всё что надо, включая бинарики и VM нужной битности. А не домохозяйка может выбрать что требуется.

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

·>Домохозяйка может и не выбирать.
Тогда у части домохозяек ярлыка вообще не будет, или будет неправильный — это потенциальный геморрой для поддержки. Иногда лучше не оставлять лишнего выбора.

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

O>·>Понятно. Т.е. в итоге сабж это не продуманное архитектурное решение, а необходимость как-то бороться с platform-hell в винде.
O>·>Скажем, в дистрибутив java приложения делается специальный launcher (или несколько) под конкретную платформу (app.exe/app.sh/etc), а само приложение обычно кладётся как jar рядышком.
O>JRE тоже может быть несколько на системе, а может быть одна. С .нет ситуация более предсказуемая, потому разработчикам дали рычажок.
Ещё раз повторяю. java-софт для домохозяек обычно распространяется с bundled jvm, нужной версии с нужными native и т.п. — предсказуемее некуда, распаковывешь и запускаешь. О таком в .net только мечтать с их монструозным установщиками, которые втыкаются по самые гланды в систему, обязательно требуя админских прав, и как же без ребутов...