Спокойно, всё будет
Сначала дойду до 8.3.16 x86, потом и за x64 возьмусь. Хотя, если честно, при разработке в Конфигураторе особых плюшек от x64 нет, можно и 32х-битным пользоваться. Вон, Microsoft Visual Studio вполне себе до сих пор 32х-битная, и ничего.
Тут подтверждают этот факт - https://developercommunity.visualstudio ... d-x86.html
А тут объясняют, почему - https://blogs.msdn.microsoft.com/ricom/ ... rsion-yet/
Да и в режиме предприятия, если честно, x64 актуально скорее для сервера, а клиентам и 4GB должно за глаза хватать. Но это уже к теме не относится.
А вот не соглашусь. На больших конфигурациях (УХ, ERP, ERP.УХ) 32-битный конфигуратор постоянно валится с нехваткой памяти на глобальном поиске и сравнении-объединении.
orefkov писал(а):Процитирую себя же с инфостарта:
Спокойно, всё будет
Сначала дойду до 8.3.16 x86, потом и за x64 возьмусь. Хотя, если честно, при разработке в Конфигураторе особых плюшек от x64 нет, можно и 32х-битным пользоваться. Вон, Microsoft Visual Studio вполне себе до сих пор 32х-битная, и ничего.
Тут подтверждают этот факт - https://developercommunity.visualstudio ... d-x86.html
А тут объясняют, почему - https://blogs.msdn.microsoft.com/ricom/ ... rsion-yet/
Да и в режиме предприятия, если честно, x64 актуально скорее для сервера, а клиентам и 4GB должно за глаза хватать. Но это уже к теме не относится.
Повторю предыдущего товарища. Таки не хватает даже бухе памяти при глобальном поиске/сравнении. Про ERP вообще молчу. Там вообще мрак. Вот удалишь форму с названием ФормаДокумента, и форма поиска валит забивая всю (2Гб) память. А конфигуратор валится именно при достижении этого порога.
Нет нужды поддерживать обе версии (х86/х64) когда у 99% давным давно винда х64. Вам же работы больше.
orefkov писал(а):Процитирую себя же с инфостарта:
Нет нужды поддерживать обе версии (х86/х64) когда у 99% давным давно винда х64. Вам же работы больше.
Ребят давайте проявим терпение, отличие х86 и х64 лишь в способе работы с памятью и ее адресами, в целом Александр сейчас имеет в виду то, что он хочет озаботиться непосредственно доработкой проекта до работы с соответствующими релизами, это и есть самое сложное, поверьте довести работу снегопата до x64 при наличии этого не составит особого труда в отличии от того как перешагнуть 8.3.12 например...
Я говорю, что нет нужды поддерживать х86 и уж тем более ставить её в приоритет, когда подавляющее большинство работает в х64. Это дополнительные расходы времени. Ненужной рутины, которая подавляет психику. И я конечно могу ошибаться, но чую что функции в этих платформах будут иметь разные адреса.
Const1C писал(а):я конечно могу ошибаться, но чую что функции в этих платформах будут иметь разные адреса.
Мысль логичная... На счет целесообразности в данном контексте согласен, лучше конечно в приоритете поддержку x64 организовать... А потом уже x32 по желанию.
так же не понятна причина начать разработку со старых версий конфигуратора. 8.3.9 - 8.3.11 это уже очень старые платформы. Даже моя 8.3.12 значительно устарела (и планирую здесь остаться надолго).
Может Вам, Александр, стоит внедрить в продукт шпионский модуль, что бы собирать статистику использования платформ? Дабы не тратить время на мало-популярные релизы? Или по связям из 1С, брать эту статистику у них.
PS. От идеи перехода на EDT, кстати, пришлось отказаться. Пришёл, к пониманию, что это инструмент абсолютно ущербный в самом своём основании. И он никогда не будет готов для продакшена. Это как с TurboConf. Сама архитектура проектов не даёт им развернутся до пригодного состояния.
Const1C писал(а):И я конечно могу ошибаться, но чую что функции в этих платформах будут иметь разные адреса.
Напрямую адреса функций в снегопате не используются, всегда используется или номер в таблице виртуальных методов объекта, или поиск в dll по имени экспортной функции.
В одном и том же релизе, скомпилированном под x86 и x64 - они одинаковые.
Различаться будут смещения некоторых данных, но это проблема поправимая.