dll y el mercado. - página 2
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
No.
Estamos fundamentalmente en contra de la proliferación de DLL y de la creación de amenazas masivas para los comerciantes. Por el contrario, ahora estamos trabajando para frenar el caos que algunas empresas están llevando a cabo tranquilamente.
No hay DLL "inseguras". Prácticamente cualquier DLL (incluyendo las DLL del sistema, casi todas ellas infamemente inseguras) puede ser utilizada para realizar un ataque de stack-skipping seguido de una toma de control. Todo lo que se necesita es la ilusión de seguridad en forma de DLL de confianza, y la seguridad caerá inmediatamente al fondo del barril. Los buenos desarrolladores exigirán que los usuarios incompetentes incluyan sus creaciones en las listas permitidas. No les importan las recomendaciones de nadie ni la seguridad de los comerciantes, porque lo único que les importa es el dinero.
En ningún caso haremos un agujero en un sistema crítico, como las soluciones de Microsoft.
Si hay diálogo, se puede encontrar una salida.
Por ejemplo, crear una base de necesidades (qué dlls les gustaría utilizar a los programadores) e implementar esta funcionalidad como estándar MQL5.
Si hay diálogo, se puede encontrar una salida.
Por ejemplo, crear una base de necesidades (que los programadores de dlls quieran utilizar), e implementar esta funcionalidad como un estándar MQL5.
Entonces, no has leído mi post y no has pensado en ello.
Al fin y al cabo, no escribo mucho y doy muchos menos argumentos de los que conozco. Un conjunto ingenuo de funciones es fácil de calcular, especialmente sus consecuencias.
¿Así que sugieres lo contrario: vender librerías ex5 en el mercado y poner dummies + dlls en el código base?
Si hay un diálogo, se podría encontrar una salida.
Por ejemplo, crear una base de necesidades (que los programadores de dlls quieran utilizar), e implementar esta funcionalidad como un estándar MQL5.
Así que no has leído mi post y no has pensado en ello.
Al fin y al cabo, escribo poco y doy muchos menos argumentos de los que conozco. Un conjunto ingenuo de funciones es fácil de calcular, especialmente sus consecuencias.
Extraña situación, si insisto me meteré en trolas, si no me quedaré sin información que no podré conseguir en otro sitio que no sea el tuyo.
Pero no entremos en abstracciones, el hombre necesita Filemapping, pues no quiere golpear un disco duro con archivos temporales para compartir información, ¿qué hay de malo en ello?
Yo propongo asignar a una persona que se ocupe sólo de lo que debe aplicarse y lo que no, y tú dices que "un conjunto de funciones es fácil de calcular, sobre todo sus consecuencias". Si la petición de una función no encaja, responda a la persona, no lo haremos así y así, cuál es el problema.
Evidentemente, no responderá usted, sino el responsable de la misma. Pero se moverá.
Es muy sencillo: es fácil hacer colaboraciones financieras a través de MQ si se deja todo al azar
Urain:
La persona necesita Filemapping, no quiere machacar la unidad con archivos temporales para el intercambio de información, ¿qué hay de malo en ello?
1. La persona no quiere un mapeo de archivos, sino algo que esté bien implementado con el mapeo.
2. No hay nada malo en ello, pero no en la revista.
3. Ya he descrito la forma legal de aplicación.
Hay hasta tres alternativas, para que una persona rompa los principios del mapeo?
Los canales con nombre están disponibles en el interproceso para un intercambio de datos de aspecto agradable.
Bien, no sé si es lo que necesita, esperemos que sí.
Pero la cuestión general es diferente, SR está tan sobrecargado que un simple temporizador de microsegundos se realizó un año (en la próxima versión vamos a pedir modificaciones, por ejemplo, un control de prioridad en el reinicio de los eventos, por supuesto que lo haremos).
La cuestión está en el diálogo, no hay un diálogo transparente para que el responsable señale con el dedo el enlace (esto ya lo preguntamos), pero esto lo consideraremos.
No sé, hacer una rama en las solicitudes de implementación, para que sea posible ver hacia dónde nos movemos. Porque es imposible planificar el desarrollo si no está claro cuándo y si se realizará tal o cual cuestión.
Puedes utilizar canales con nombre para un buen intercambio de datos en el interproceso.
el problema es que el EA se inicia en modo Servidor y solo tiene clientes en pips.
no son adecuados .
por favor, añadir el modo de servidor a MQL pips. ¿está bien? o la seguridad también se verá comprometida?