Не могу сказать, что переход на 64 бита (amd64) в Linux был вовсе беспроблемным, но в целом, 64-битные дистрибутивы с внимание, нативными 64-битными программами, появились практически одновременно с выходом на рынок процессора Opteron. Далеко не все были перекомпилированы под 64 бита, но где-то к 2007 году почти все более-менее заметные OpenSource программы уже существовали в 64-битном варианте. Сейчас я вообще, глядя в репозиторий, затрудняюсь сказать есть ли там не проприетарные 32bit only. А то что есть, не так и плохо работают и из под 64-битного окружения.
С Windows же, как всегда, все не просто так. Разные Programm Files, отсутствие встроенного 64 ассемблера в VC++ и т.д и т.п.
M>С Windows же, как всегда, все не просто так. Разные Programm Files, отсутствие встроенного 64 ассемблера в VC++ и т.д и т.п.
Ассемблер в VC есть. Просто он не инлайновый.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Michael7, Вы писали:
M> Не могу сказать, что переход на 64 бита (amd64) в Linux был вовсе беспроблемным, но в целом, 64-битные дистрибутивы с внимание, нативными 64-битными программами, появились практически одновременно с выходом на рынок процессора Opteron. Далеко не все были перекомпилированы под 64 бита, но где-то к 2007 году почти все более-менее заметные OpenSource программы уже существовали в 64-битном варианте. Сейчас я вообще, глядя в репозиторий, затрудняюсь сказать есть ли там не проприетарные 32bit only. А то что есть, не так и плохо работают и из под 64-битного окружения.
M> С Windows же, как всегда, все не просто так. Разные Programm Files, отсутствие встроенного 64 ассемблера в VC++ и т.д и т.п.
Здравствуйте, hattab, Вы писали:
H>Просто 64 бита нужны далеко не всем
Это да, но вот откуда столько каких-то заноз в портировании виндовых программ я не понимаю. В Linux практически нет системно-зависимых проблем с этим, только в основном всякие нюансы, связанные с размерностью типов. И это при том, что вообще-то MS уже давно выпускала 64-битные версии. С самого начала WinNT существовала в 64-битном варианте для платформ MIPS и Alpha, как минимум.
Здравствуйте, Michael7, Вы писали:
M>Это да, но вот откуда столько каких-то заноз в портировании виндовых программ я не понимаю.
в линукс, если я не ошибаюсь, сменили размерности типов данных; а в винде прикрутили аццкий костыль — злоеб#%чую WoW — чтобы всякие интерпрайз-педенги были довольны
Здравствуйте, Michael7, Вы писали:
M> H>Просто 64 бита нужны далеко не всем
M> Это да, но вот откуда столько каких-то заноз в портировании виндовых программ я не понимаю. В Linux практически нет системно-зависимых проблем с этим, только в основном всякие нюансы, связанные с размерностью типов. И это при том, что вообще-то MS уже давно выпускала 64-битные версии. С самого начала WinNT существовала в 64-битном варианте для платформ MIPS и Alpha, как минимум.
Просто если софту не нужны 64 бита, зачем разработчику выпускать (а потом еще и поддерживать) две версии одного и того же софта Коли 32 софт битный прекрасно работает под 64 битной ОС, и при этом не теряет в функциональности, так и напрягаться особого смысла нет. А на счет заноз... А какие есть, кроме размерности типов?
Здравствуйте, nullptr_t, Вы писали:
_>в линукс, если я не ошибаюсь, сменили размерности типов данных; а в винде прикрутили аццкий костыль — злоеб#%чую WoW — чтобы всякие интерпрайз-педенги были довольны
WoW в данном случае совершенно не причём, он к портированию никакого отношения не имеет. Как раз с размерностью данных так, что по умолчанию, в Linux, скорее в gcc (умолчание можно изменить) long 64-битный, а в Windows — 32-битный. int везде 32-битный. Мелочь, но в винде немало функций, чей результат в виде указателя приводится к виду:
LONG WINAPI какая-то функция
в результате облом наступает чаще, чем просто в случае аргументов типа long, хуже того, если результат помещает в первые 4Гб все может работать довольно долгое время нормально. А заради совместимости в 64-битной винде придумали функции из API с окончанием Ex (GetFileSizeEx). И подобных костылей, трахающих мозг немало.
Здравствуйте, hattab, Вы писали:
H>Просто если софту не нужны 64 бита, зачем разработчику выпускать (а потом еще и поддерживать) две версии одного и того же софта Коли 32 софт битный прекрасно работает под 64 битной ОС, и при этом не теряет в функциональности, так и напрягаться особого смысла нет. А на счет заноз... А какие есть, кроме размерности типов?
В другом посте привел пример с приведением указателя к LONG WINAPI в ряде стандартных функций и введении для этого костыля с Ex. Все решается конечно, просто вот возникает ощущение какой-то возни на ровном месте и лишнем усложнении.
Здравствуйте, Michael7, Вы писали:
M>WoW в данном случае совершенно не причём, он к портированию никакого отношения не имеет. Как раз с размерностью данных так, что по умолчанию, в Linux, скорее в gcc (умолчание можно изменить) long 64-битный, а в Windows — 32-битный. int везде 32-битный. Мелочь, но в винде немало функций, чей результат в виде указателя приводится к виду:
M>LONG WINAPI какая-то функция
M>в результате облом наступает чаще, чем просто в случае аргументов типа long, хуже того, если результат помещает в первые 4Гб все может работать довольно долгое время нормально. А заради совместимости в 64-битной винде придумали функции из API с окончанием Ex (GetFileSizeEx). И подобных костылей, трахающих мозг немало.
Здравствуйте, Michael7, Вы писали:
M>Сейчас я вообще, глядя в репозиторий, затрудняюсь сказать есть ли там не проприетарные 32bit only. А то что есть, не так и плохо работают и из под 64-битного окружения.
если я правильно помню установку бубунты по-умолчанию, вообще не работают.
M>С Windows же, как всегда, все не просто так. Разные Programm Files
ты ещё скажи что в линухе не разные. да такие не разные, что отличаются по именам в разных дистрибутивах.
Здравствуйте, Michael7, Вы писали:
M>вот откуда столько каких-то заноз в портировании виндовых программ я не понимаю. В Linux практически нет системно-зависимых проблем с этим, только в основном всякие нюансы, связанные с размерностью типов. И это при том, что вообще-то MS уже давно выпускала 64-битные версии. С самого начала WinNT существовала в 64-битном варианте для платформ MIPS и Alpha, как минимум.
именно. линух не может похвастаться такой совместимостью (да вообще никакой не может)
а в винде, на мой взгляд, проблемы давно решены отметкой например что "используйте GetWindowLongPtr вместо GetWindowLong", добавлением GetFileSizeEx и т.п. зато всё старое работает. хотите нового? добавьте -Ex
ы?
Здравствуйте, Antikrot, Вы писали:
A>если я правильно помню установку бубунты по-умолчанию, вообще не работают.
Не работаю с бубунтой В Debian же и wine (он правда не проприетарный) нормально работает и ряд других вещей.
M>>С Windows же, как всегда, все не просто так. Разные Programm Files A>ты ещё скажи что в линухе не разные. да такие не разные, что отличаются по именам в разных дистрибутивах.
Вот не поверишь, именно в контексте портирования это вообще никаких забот не доставляет. А вот два смежных реестра в 64-битной — да. В общем, каждая из проблем, не сказать бы, что особо крупная и создающая большие сложности, но чисто субъективное ощущение, что их больше, чем в Linux.
Здравствуйте, nullptr_t, Вы писали:
_>именно. линух не может похвастаться такой совместимостью (да вообще никакой не может)
Это отдельный разговор. И это не совсем так.
_>а в винде, на мой взгляд, проблемы давно решены отметкой например что "используйте GetWindowLongPtr вместо GetWindowLong", добавлением GetFileSizeEx и т.п. зато всё старое работает. хотите нового? добавьте -Ex _>ы?
Понимаешь, одни проблемы решены, другие введены. В Linux, например, никто не добавлял 64-битных аналогов таких функций. Мне кажется, это следствие того,что менеджмент в MS все время более склонен решить сиюминутные проблемы, но порушить системную стройность.
Здравствуйте, Michael7, Вы писали:
M>Понимаешь, одни проблемы решены, другие введены. В Linux, например, никто не добавлял 64-битных аналогов таких функций. Мне кажется, это следствие того,что менеджмент в MS все время более склонен решить сиюминутные проблемы, но порушить системную стройность.
менеджмент MS все время более склонен к решению проблем enterprise, который медленный и неповоротливый, зато очень дойный (имхо)
к тому же линух сразу был 32бита, а винда тащит на горбу жуткое наследие win16
Здравствуйте, Michael7, Вы писали:
M> В другом посте привел пример с приведением указателя к LONG WINAPI в ряде стандартных функций и введении для этого костыля с Ex. Все решается конечно, просто вот возникает ощущение какой-то возни на ровном месте и лишнем усложнении.
А, ты об этом... Ну не столь оно страшным выглядит Я просто думал будет что-то не описанное в Platform SDK.
Здравствуйте, hattab, Вы писали:
H>А, ты об этом... Ну не столь оно страшным выглядит Я просто думал будет что-то не описанное в Platform SDK.
Но в итоге, взять допустим, браузеры. Firefox для Linux я уже не помню, когда был AThlon64, но еще не существовала 64-битная версия. И плагины к нему есть 64-битные под Linux. Для винды же у Firefox 64-битная версия появилась недавно, причем плагинов под нее фактически нет. Что мешает? Чего-то тормозит в разработке в итоге.
Здравствуйте, Anton Batenev, Вы писали:
AB> h> Просто 64 бита нужны далеко не всем
AB> На серверном железе я уже пару лет не наблюдаю x32, разве что у хостеров типа infobox (ну так там и "сервера" в десктопных корпусах).
Здравствуйте, Michael7, Вы писали:
M> Но в итоге, взять допустим, браузеры. Firefox для Linux я уже не помню, когда был AThlon64, но еще не существовала 64-битная версия. И плагины к нему есть 64-битные под Linux. Для винды же у Firefox 64-битная версия появилась недавно, причем плагинов под нее фактически нет. Что мешает? Чего-то тормозит в разработке в итоге.
Так может та же самая оправданность и мешает Браузеры пока в адресное пространство не упираются, а с приходом мультипроцессорной модели им это вообще не грозит. Так что стоит ли... Почему он под Линуксом 64 битный... Может сказывается то обстоятельство, что на 64 битном дистре, без 32 битных библиотек, 32 битные приложения не заработают, а библиотеки еще поставить нужно
В Debian же и wine (он правда не проприетарный) нормально работает и ряд других вещей.
