Здравствуйте, netch80, Вы писали:
N>Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами. N>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
Однако, в отношении GNU make у тебя налицо двойные стандарты
Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки. Внимание, вопрос: зачем тратиться ради ламеров?
Здравствуйте, midcyber, Вы писали:
N>>Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами. N>>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
M>Однако, в отношении GNU make у тебя налицо двойные стандарты ;)
M>
M>Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки. Внимание, вопрос: зачем тратиться ради ламеров?
Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. make (не говори GNU make, потому что их несколько версий от разных производителей) в случае необходимости переделки означает чуть ли не глобальную реформу в отрасли, потому что тот или иной makefile сопровождает любую юниксовую тулзу. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы:)
В случае же перехода 32->64 мы и так имеем грандиозную реформу всего кода. На момент подготовки этого перехода (я не говорю про сейчас, я говорю про 2002-2005 годы) крайне мало кода программ под Windows было готово для перекомпиляции под 64 бита и успешной работы под ней. Поэтому всё равно реформа требовалась. Почему бы в неё не включить и исправление по замене хардкоженных стандартных путей на получаемые из адекватного источника?
Здравствуйте, Torie, Вы писали:
N>>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
T>Хуже всего, что "совместимость" от всех этих костылей с путями и перенаправлениями весьма липовая. Я портировал кое-что на 64 бита, и убрать захардкоденные пути для %SYSTEM% (даже если они есть) — это была наименьшая из всех проблем. T>Решив высосанную из пальца проблему, M$ породил геморрой, который придется тянуть еще не одно десятилетие.
Ясно. Тогда тем более непонятно, почему соображения в пользу такой "совместимости" перевесили остальное...
Здравствуйте, Torie, Вы писали:
T>Здравствуйте, netch80, Вы писали:
N>>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
T>Хуже всего, что "совместимость" от всех этих костылей с путями и перенаправлениями весьма липовая. Я портировал кое-что на 64 бита, и убрать захардкоденные пути для %SYSTEM% (даже если они есть) — это была наименьшая из всех проблем. T>Решив высосанную из пальца проблему, M$ породил геморрой, который придется тянуть еще не одно десятилетие.
Этот весь геморой нужен для того чтобы 32-тные программы работали на 64-битной винде. Причем тут портирование и десятилетие?
Здравствуйте, Константин Б., Вы писали:
КБ>Этот весь геморой нужен для того чтобы 32-тные программы работали на 64-битной винде. Причем тут портирование и десятилетие?
Я писал про пихание 64-битных библиотек в system32. Ну и каким образом оно должно помочь работать 32-битным программам? Сам вдумайся в то, что ты написал.
Здравствуйте, netch80, Вы писали:
N>Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы
Вот в моем представлении — это такие же "костыли, вызванные уже несуществующими историческими причинами"
Здравствуйте, McSeem2, Вы писали:
MS>Однако, вынужден заметить, что и в Микрософте все плохо.
Да ты шо?
MS>Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля.
А что, в самом vcproj текстовый guid в текстовом редакторе поменять не судьба?
MS>Самое страшное, что за эти 15 минут успеваешь пережить весь ментальный геморрой со времен большого взрыва! По количеству WTF там 15 минут за 10 миллиардов лет надо считать. Вообще, самое страшное наказание программисту в аду — это вечно настраивать проекты в вижуал-студии.
Извини, но согласиться не могу. Всё там просто и понятно. По крайней мере всё что мне понадобилось ковырять в vcproj ручками я проделывал быстро и без единого WTF.
Здравствуйте, Константин Б., Вы писали:
КБ>Этот весь геморой нужен для того чтобы 32-тные программы работали на 64-битной винде. Причем тут портирование и десятилетие?
Я у себя на 2008R2 вырубил нахрен как виртуализацию реестра так и файловые перенаправления + ограничение в правах для х86 процессов. И только тогда у меня нормально начали работать х86 проги а из Far x86 стало возможно запускать любые проги с полными правами. Far х64 пользоваться невозможно, т.к. под него нет нужных плагинов.
Так что нафиг эти извраты не нужны. У меня без них куда больше софта работает чем с ними.
Здравствуйте, Torie, Вы писали:
C>>Зато позволяют нормально делать циклические ссылки, так как зависимости разрешаются в рантайме загрузчиком. T>Это типа должно быть преимуществом? А по моему, за такие фокусы надо бить лопатой по хлебалу.
Вообще говоря, да. Иногда крайне удобно.
Здравствуйте, Константин Б., Вы писали:
C>>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине. КБ>А 32-битную библиотеку можно загрузить в 64-битный процесс?
Нельзя, конечно.
Был проект, позволявший это делать с ограничениями, но обычно проще выделить 32-битную часть в отдельный процесс.
N>Как сказал Хайнлайн (наверняка упростив какого-то психолога), мы смеёмся, чтобы заглушить душевную боль. Не бывает смешных вещей, в которых кто-нибудь не страдает и нельзя представить себя на его месте. N>Я уже много лет плотно не работаю с Windows, поэтому сам всё это не переживаю. Наверно, поэтому не смеялся. Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами. N>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
На самом деле даже ничего ломать не требовалось — сделали бы system64 для 64хбитных приложений, а system32 оставили с 32хитными длл. С реестром тоже можно было обойтись без этих волшебных перестановок — при помощи симлинок и изменения численного значения HKEY_LOCAL_MACHINE.
Совместимость с уже написанными 32хбитными приложениями осталась бы. А перед тем как портировать приложения на нативные 64 бита всего ничего — пришлось бы поискать захардкоженные в исходном тексте строки system32 И поменять их на system64 или на спец апи типа GetSystemDirectory.
А микрософт решила ввести совершенно новый уровень сложности в ядро винды вместо этого.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Константин Б., Вы писали:
T>>Хуже всего, что "совместимость" от всех этих костылей с путями и перенаправлениями весьма липовая. Я портировал кое-что на 64 бита, и убрать захардкоденные пути для %SYSTEM% (даже если они есть) — это была наименьшая из всех проблем. T>>Решив высосанную из пальца проблему, M$ породил геморрой, который придется тянуть еще не одно десятилетие.
КБ>Этот весь геморой нужен для того чтобы 32-тные программы работали на 64-битной винде. Причем тут портирование и десятилетие? :xz:
Объясни, plz. Вот криво написанная 32-битная программа ищет что-то в %WINDOWS%/system32. DLL'ку там положила, например. Вот 64-битная система, и она же — 32-битная программа — там ничего не находит, потому что то же содержимое лежит в %WINDOWS%/хренЗнаетГде/WOW64. Каким образом этот весь геморрой помогает программе работать в 64-битной системе?;)) (Нет, я читал про всякие тайные подмены путей на ходу. Не надо рассказывать их ещё раз, просто объясни, чем альтернативный вариант с отсутствием таких странных прыжков был бы заведомо хуже.)
Здравствуйте, midcyber, Вы писали:
N>>Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы:)
M>Вот в моем представлении — это такие же "костыли, вызванные уже несуществующими историческими причинами"
Тогда объясни эти исторические причины.:)
В конце концов, в отличие от виндовых путей, тебя никто не обязывает использовать именно make традиционного вида. Есть десятки альтернатив, от просто изменённого синтаксиса до принципиально другого подхода. Но тебя потянуло именно на традиционный make, и ты, не попробовав альтернатив, плюёшься на всех как на него. Зачем?
Здравствуйте, Cyberax, Вы писали:
C>Нафиг он нужен, когда есть CMake, scons или тот же waf?
Все унылое г-но, к сожалению. От того у буста свой Jam, а у ACE свой MPC. CMake неплохо лечит недостатки make, но появился слишком поздно. Собсно, он уже родился устаревшим, поэтому несерьезно его сегодня советовать. Уж лучше Ant/NAnt.
IID>>Прекомпилённые заголовки, которые непойми как работают. Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник). Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win). Это только малая часть. Уж ешьте такое сами. C>Зато позволяют нормально делать циклические ссылки, так как зависимости разрешаются в рантайме загрузчиком.
Циклически можно с помощью стабов собирать и под виндами. Вообще, гоните вы оба, ибо есть флаг --no-undefined. И да, динамические библиотеки в линухах — это вовсе не DLL в виндах, другой принцип загрузки. И да, загрузчик легко и статическую библиотеку в процесс при загрузке прилинковать может, в этом плане и в упомянутом насчет ресолвинга ссылок просто в линухах есть некая консистентность м/у статическими и динамическими либами.
C>>>(без всяких магических перенаправлений). IID>>Перенаправления нужны вовсе не для возможности запуска C>А для чего? Оно нужно из-за того, что куча приложений уже зашили слово "system32" намертво.
Их проблемы, надо было брать значения из реестра, как в доке и сказано.
C>В Линуксе оно нативно вообще может работать.
А вот это как раз из-за недоделанных динамических библиотек в линухах. Имею ввиду, что каждый процесс полностью изолирован от других, и не умеет шарить/маппить память загруженных динамических библиотек. Смешно, но сей недостаток оказался бенефитом для такой гетерогенной среды.
C>Вот я про то и говорю. Чтоб этими 8Гб воспользоваться в 32 бит — нужен enterprise-сервер за кучу денег.
А ими и так, и так нельзя воспользоваться. Никакой 32-битный процесс более 4 гиг не увидит, поэтому на однопользовательской машине с десктопной осью оно и нафиг не облокотилось. Понятно, что юнихи изначально являются серверно-ориентированными осями, где может крутиться несколько "больших" приложений, но и стоят серьезные юнихи подороже виндов-то. Да и в "бесплатном" линухе недалеко все ушло, ибо кто на RedHat сидит (единственная адекватная серверная сборка), по итогам платит не меньше чем за виндовые решения.
Здравствуйте, McSeem2, Вы писали:
MS>Однако, вынужден заметить, что и в Микрософте все плохо. Все гораздо хуже, чем в гмэйке. Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля. Иначе, если просто переименовывать, то нельзя будет сделать из набора проектов sln из за одинаковых гуидов. У студии от такого наступает полный когнитивный диссонанс вплоть до абсолютной недееспособности.
Не понял, почему надо 15 мин на то, чтобы в первых строчках vcproj-файла просто поменять GUID и спокойно добавить его в проект?
Здравствуйте, vdimas, Вы писали:
C>>Нафиг он нужен, когда есть CMake, scons или тот же waf? V>Все унылое г-но, к сожалению. От того у буста свой Jam, а у ACE свой MPC. CMake неплохо лечит недостатки make, но появился слишком поздно. Собсно, он уже родился устаревшим, поэтому несерьезно его сегодня советовать. Уж лучше Ant/NAnt.
LOL! Ты хоть SCons поблизости видел? Ant по сравнению с ним — унылая поделка, заведи тему в КСВ, если хочешь. Подробно объясню почему.
C>>>>(без всяких магических перенаправлений). IID>>>Перенаправления нужны вовсе не для возможности запуска C>>А для чего? Оно нужно из-за того, что куча приложений уже зашили слово "system32" намертво. V>Их проблемы, надо было брать значения из реестра, как в доке и сказано.
Ну так вот и получилось, что system32 содержит 64-битные DLL-ки. А ещё перенаправление Program Files в домашний каталог в Висте — вообще супер.
C>>В Линуксе оно нативно вообще может работать. V>А вот это как раз из-за недоделанных динамических библиотек в линухах. Имею ввиду, что каждый процесс полностью изолирован от других, и не умеет шарить/маппить память загруженных динамических библиотек. Смешно, но сей недостаток оказался бенефитом для такой гетерогенной среды.
Мимо. Я говорю про возможность запуска 64-битных процессов в 32-битной системе. Это делается с помощью специального shim-слоя, переключающего процессор из long mode в protected mode при системных вызовах и переключениях контекста. Причём тут изолированность?
C>>Вот я про то и говорю. Чтоб этими 8Гб воспользоваться в 32 бит — нужен enterprise-сервер за кучу денег. V>А ими и так, и так нельзя воспользоваться. Никакой 32-битный процесс более 4 гиг не увидит, поэтому на однопользовательской машине с десктопной осью оно и нафиг не облокотилось.
А и не надо. У меня сейчас работает 20 приложений на машине, ни одному вообще больше 2Гб не нужно, а все вместе они за 6Гб запросто уходят. Ну и файловый кэш, конечно же, весьма помогает.
Здравствуйте, McSeem2, Вы писали:
MS>А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля.
GUID проекта записан в одном месте .vcproj-файла. Если уж приспичило скопировать .vcproj, то GUID заменяется секунд за 40 в том же FAR. C .sln-ами сложнее, ну так их и компоновать из студии просто — просто добавляешь новые проекты, никакого колдовства.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, MikePetrichenko, Вы писали:
MP>Здравствуйте, Torie, Вы писали:
T>>Послушайте, в этом правда нет ничего сложного.
T>>Все программы находятся там же, в %ProgramFiles%, кроме случаев, когда вам требуется 32-битная версия, которая находится в %ProgramFiles(x86)%, за исключением ситуаций, когда дело касается 32-битной машины, и в этом случае они по-прежнему в %ProgramFiles%.
MP>Не понятный плач какого-то придурка.
Да ладно. Сделано, возможно, и лучшим способом из расчета на максимальную обратную совместимость, но если собрать все факты в один пучок, получается смешно. Будьте оптимистом
V>А ими и так, и так нельзя воспользоваться. Никакой 32-битный процесс более 4 гиг не увидит, поэтому на однопользовательской машине с десктопной осью оно и нафиг не облокотилось.
