Общайтесь с разработчиками через Сервисдеск! - страница 33
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
например, дал ссылку на английском языке -- а читателю предпочтительней португальский -- он знает что есть перевод на португальский -- переключается -- а статьи нет.
Сделайте возможность использования агентов тестирования для платформ 32бит. Хотя бы возможность использования локальных агентов.
Сделайте возможность использования агентов тестирования для платформ 32бит. Хотя бы возможность использования локальных агентов.
Локальные агенты 32 битного терминала МетаТрейдер 5 работают - их никто не отключал и не собирается отключать.
32 битные агенты больше не работают в удаленном(ферма в локальной сети) режиме и MQL5 Cloud Network. Мы сейчас провели огромную работу по оптимизации использования удаленных/облачных агентов(билд выйдет завтра) и нам совершенно ясно, что время 32 битных агентов ушло.
Отказ от 32 битных агентов агентов упростил систему, поднял качественный уровень расчетной сети и избавил от ряда проблем с недостатком ресурсов. Скоро мы представим бету нового компилятора MQL5 специально для 64 битных платформ, который работает в 2-3 раза быстрее текущей реализации. 32 битные версии терминалов будут пользоваться старыми версиями скомпилированного кода (каждая программа будет содержать стандартный код для совместимости и новый оптимизированный под x64).
Локальные агенты 32 битного терминала МетаТрейдер 5 работают - их никто не отключал и не собирается отключать.
32 битные агенты больше не работают в удаленном(ферма в локальной сети) режиме и MQL5 Cloud Network. Мы сейчас провели огромную работу по оптимизации использования удаленных/облачных агентов(билд выйдет завтра) и нам совершенно ясно, что время 32 битных агентов ушло.
Отказ от 32 битных агентов агентов упростил систему, поднял качественный уровень расчетной сети и избавил от ряда проблем с недостатком ресурсов. Скоро мы представим бету нового компилятора MQL5 специально для 64 битных платформ, который работает в 2-3 раза быстрее текущей реализации. 32 битные версии терминалов будут пользоваться старыми версиями скомпилированного кода (каждая программа будет содержать стандартный код для совместимости и новый оптимизированный под x64).
Насчет агентов я имел в виду именно 32 битные агенты в удаленном (ферма в локальной сети) режиме. Это ни как не повлияет на режим MQL5 Cloud Network, где их можно отключить. Но нет так нет.
Вообще я так понимаю, придется переделывать dll, в скором времени под 64 битные платформы, грустно однако...
Вообще я так понимаю, придется переделывать dll, в скором времени под 64 битные платформы, грустно однако...
Это не грустно, а правильно.
Фактически только один Микрософт в этом мире занимается утягиванием всех в болото 32 битных версий ради продаж. Даже Windows 10 умудрились выпустить 32 битным, только чтобы установиться в слабое железо.
Тот, кто занимается развитием рынка, давно перешел на 64 бита и забыл как про страшный сон это старье с костылями. Посмотрите что делает Apple и что Microsoft. Apple даже для айфонов с февраля 2015 года запретил публикацию 32 битных программ в своем AppStore.
Это не грустно, а правильно.
Фактически только один Микрософт в этом мире занимается утягиванием всех в болото 32 битных версий ради продаж. Даже Windows 10 умудрились выпустить 32 битным, только чтобы установиться в слабое железо.
Тот, кто занимается развитием рынка, давно перешел на 64 бита и забыл как про страшный сон это старье с костылями. Посмотрите что делает Apple и что Microsoft. Apple даже для айфонов с февраля 2015 года запретил публикацию 32 битных программ в своем AppStore.
А как тогда быть с импортом функций из dll в 64 битных терминалах? Ведь соглашение _stdcall на 64 битных ПО не поддерживается в силу специфики. Придется пользователям (программистам) вбивать те же самые костыли посредством СОМ либо P/Invoke, ведь создание ПО без явного интерфейса взаимодействия это и есть костыли. Решите тогда вопрос со стандартами пожалуйста и как можно скорее. Я не против мигрирования на 64 битные технологии т.к. выигрыш будет явным в скорости обработки путем исключения WOW64, но согласитесь, что нужен принятый стандарт иначе в один момент созданные dll перестанут работать если закроется какой либо не описанный вариант взаимодействия терминала и dll.
А какие проблемы с импортом?
Все работает штатно по x64 соглашениям (они другие по отношению к 32 битам и жестко стандартизированы).
Вообще никаких проблем нет. И даже в 32 битах никаких проблем с разными cdecl/stdcall вызовами нет. За счет нашего защитного враппера MQL4/MQL5 нам все равно, какое соглашение у импортируемой функции.
А какие проблемы с импортом?
Все работает штатно по x64 соглашениям (они другие по отношению к 32 битам и жестко стандартизированы).
Вообще никаких проблем нет. И даже в 32 битах никаких проблем с разными cdecl/stdcall вызовами нет. За счет нашего защитного враппера MQL4/MQL5 нам все равно, какое соглашение у импортируемой функции.
Насчет соглашений о вызовах - в справке об этом укажите явно пожалуйста. А вот небольшая выдержка по 64 битной архитектуре:
Скорее всего ни о каком повышении производительности в МТ5 для 64 битной архитектуры и речи быть не может при использовании враппера MQL4/MQL5, т.к. враппер по сути приводит все к какому то единому виду - 32 или 64 битной архитектуре. Но тут возникает вопрос, если все приводится к 64 битной архитектуре в передаваемых параметрах, то работа кода 32 битной dll не будет работать в некоторых случаях корректно, то же самое произойдет и в случае к приведению к 32 битной архитектуры - код dll 64 битной архитектуры не сможет корректно работать из-за некоторых типов данных, да и к тому же проблемы со стеком возникнут и т.д.
Наверное имеет смысл привести в 64 битном терминале API только к стандарту 64 бит и исключить 32 битные соглашения о вызовах.
Насчет соглашений о вызовах - в справке об этом укажите явно пожалуйста. А вот небольшая выдержка по 64 битной архитектуре:
Скорее всего ни о каком повышении производительности в МТ5 для 64 битной архитектуры и речи быть не может при использовании враппера MQL4/MQL5, т.к. враппер по сути приводит все к какому то единому виду - 32 или 64 битной архитектуре. Но тут возникает вопрос, если все приводится к 64 битной архитектуре в передаваемых параметрах, то работа кода 32 битной dll не будет работать в некоторых случаях корректно, то же самое произойдет и в случае к приведению к 32 битной архитектуры - код dll 64 битной архитектуры не сможет корректно работать из-за некоторых типов данных, да и к тому же проблемы со стеком возникнут и т.д.
Наверное имеет смысл привести в 64 битном терминале API только к стандарту 64 бит и исключить 32 битные соглашения о вызовах.
64 битные терминалы не поддерживают 32 битных dll.
Не надо придумывать проблемы там, где их вообще нет.
64 битные терминалы не поддерживают 32 битных dll.
Не надо придумывать проблемы там, где их вообще нет.
Я знаю, что 64 битные программы не поддерживают 32 битные dll и не важно какая это программа - терминал либо другая. Вы ведь сами написали про враппер MQL4/MQL5. А я как пользователь лишь знакомлюсь с техническими возможностями описанными в справке и исходя из этого пишу программное обеспечение, по другому просто нельзя. В одной из веток Вы обещали выложить статью, где описываются всякие нововведения, но статьи нет. Вот и приходится все домысливать.
Вы в справку внесите пояснения о том, что импорт функций из dll в 64 битных платформах производится по правилам 64 битной архитектуры. А то по справке складывается смысл, что в МТ5 действительно используете соглашение о вызовах в 64 битной архитектуре, которых по сути быть не может.