man_from_LOR
man_from_LORvertur
И тем не менее будут.И тем не менее на практике я сталкиваюсь с тем, что не то, что 20-летней давности, а даже трехлетней давности программа, если ее перестали поддерживать мейнтейнеры и ее исключили из репозитория может не встать и не скомпилироваться.
Значительную роль играет фактор того _как_именно_ была написана программа. Если там непрорубаемый говнокод, либо закостыленый порт с windows, то может быть все что угодно. Качество исполнения ПО неуклонно падает, вместе с уменьшением "порога вхождения" для написания ПО. Тем не менее, всё классическое ПО прекрасно переносимо и компилируется без проблем.
man_from_LOR
А дальше уже вопрос сколько с ней возни, чтобы заработала. С чем-то меньше, с чем-то больше, что-то вообще не лезет без больших усилий как dvswitch, впрочем dvswitch еще не самый сложный случай.
Опять же, см выше.
man_from_LOR
Что я и хотел показать. Вы говорите, что линукс постоянно используете и даже нет винды, но по вашим ответам такое впечатление возникает, что они часто теоретические. Или вы как-то под очень узкий круг задач используете, даже не знаю.
Вот именно, что не знаете.
man_from_LOR
В частности, про совместимость C++. Опцию --std= не случайно придумали.
Хотите о этом поговорить ? Идите в ветку про програмироваание, мне есть много что вам рассказать.
man_from_LOR
Не все ограничивается warning если что, некоторые вещи без этой опции будут с ошибками падать.
Жуткий
"Некоторые вещи" могут падать даже если никаких warning или error со стороны компилятора вообще не было. Это просто как 2x2.
man_from_LOR
Вообще, это обычное дело в современном линуксе, когда попытка что-то скомпилировать приводит к вываливанию компилятора с ошибкой.
Потому что свежий говонокод от юных красноглазых упоротышей. Им и vtable подправить как "два пальца...", а об последствиях никто и не думает, т.к. не чем.
man_from_LOR
К примеру, у меня браузер firefox из исходников компилируется правильно только до тех пор, пока не поставлено несколько библиотек из бекпортов, иначе компиляция валится (build-dep не забываю). chromium в этом смысле более устойчивый. В результате под компиляцию ставится отдельная виртуальная машина со своей средой, потому что шаг влево - шаг вправо и хренак **Error. И об этом в принципе известно всем, кто что-то компилирует в линуксе.
Ну chroot окружение решает большую часть задач. Те которые не решает - решает docker.
man_from_LOR
vertur
Хотите сказать что 16битное ABI от windows 2.0 осталось для Win32 или Win64 ? Я давно так не смеялся.Для Win64 нет по естественным причинам, но для Win32 осталось до сих пор.
Win16: sizeof(INT) = 2
Win32: sizeof(INT) = 4
Опс, как же так если ABI не ломали ?
Win16: ScaleWindowExt
Win32: ScaleWindowExtEx (функция ScaleWindowExt отсутсвует)
Оооооопс, как же так и даже API осталось совместимым ?
А почему бы нет, если ABI от 2.0 (и даже 1.x) в 3.x не ломали. Потом обратная совместимость была и в NT и в 95-й и т.д. и вплоть до сейчас.
Ну попробуйте запустите какое-ть win16 приложение сейчас, под Windows10 например - узнаете много интересного.
man_from_LOR
Причем еще и есть такая сторонняя программа как WineVDM специально для запуска Win16 программ в Win64, основана на wine. Работает так себе, но тем не менее.
Wine для Windows - это пять!
А UNIX-овую программу можно просто пересобрать и будет "как новенькая", нативно и без прослоек симуляторов/эмуляторов.
