cómo descargar la dll - 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 hay UnloadLibrary() en WinAPI, hay FreeLibrary().
Tienes razón :-). Mi MSDN no cargó por alguna razón :-).
.
El SO descarga cualquier dll sólo cuando el valor del contador de carga es cero.
En este caso la única aplicación que carga el dllku es metatrader.
En este caso, la única aplicación que carga el dllku es Metatrader.
utilizando una biblioteca externa a través de #import.
Cuando descargo el idnikator, el terminal sigue reteniendo la dll. ¿cómo me deshago de ella?
Escribe una dll sin errores. Normalmente las dlls se descargan solas, a no ser que haya alguna contingencia.
Aparte de cualquier método "hacker", esto es lo único posible.
Escribe la dll sin errores. Por lo general, el dll se descargará por sí mismo a menos que haya alguna contingencia.
Bueno, mi querido amigo.
Tengo la última Dll y he decidido seriamente demostrar que estás equivocado :-).
Descubrí que después de salir del script, así como después de salir del indicador
(cerrando la ventana o borrando el indicador), la Dll se descarga...
En cuanto a la "alfabetización"... DllMain siempre devuelve estúpidamente TRUE.
Pero recuerdo que hace un año tuve que salir de Metatrader para sustituir la Dll.
SO = WinXP SP3, MT = 225
Ustedes son raros o algo así. Sólo he tenido problemas de este tipo, que no se descargaron, unas pocas veces, y siempre se debió a errores en el código. Esta es la primera. El segundo. Permítame recordarle que Microsoft inventó este mecanismo de carga/descarga implícita específicamente para simplificar el manejo de Dll.
De dónde sacan estos extraños problemas, me niego a entenderlo.
Sí, y eso, yo personalmente no uso DllMain, directamente.
Ustedes son raros o algo así. Sólo he tenido problemas de este tipo con algo que no se ha descargado un par de veces, y siempre fue debido a errores en el código.
De dónde sacan estos extraños problemas, me niego a entenderlo.
Y yo personalmente no uso DllMain directamente.
Esta es una cita de MSDN:
"Cuando el sistema llama a la función DllMain con cualquier valor que no sea DLL_PROCESS_ATTACH, el valor de retorno se ignora".
Es decir, cuando descargas una Dll-in, al sistema le da absolutamente igual lo que pienses de ti como programador allí.
No se puede escribir correctamente o de forma incorrecta: si no se está en ella, simplemente se sale. Si es posible.
.
Pero ya que te crees un profesional, probablemente puedas aconsejar a los principiantes en lugar de retocar...
No veo que escribas nada importante: elimina la vinculación dinámica del proyecto,
dependencias de los paquetes en tiempo de ejecución, manejar cuidadosamente los Dlls enlazados-no es probable que se usen allí, por supuesto.
se utilizan allí, por supuesto, y posiblemente trabajan con el subsistema COM, donde una sola llamada como OleInitialize puede recoger
docenas de Dlls del sistema. Como todas estas dependencias se cargan a la vez... es fácil con la puesta en marcha,
pero con desinicialización - por ejemplo, si tanto Dll como Metatrader enganchan las mismas bibliotecas del sistema -.
podría haber problemas - quién sabe lo que hay en el fondo del SO...
.
Somos usuarios de la API que enganchan todas las funciones Dll a través de .h / .lib y la carga de bibliotecas,
lo más probable es que ocurra en la inicialización de la aplicación, no hay *nada* que podamos hacer.
O bien cargaríamos todas las librerías por nuestra cuenta y enlazaríamos todas las funciones dinámicamente a mano.
Por otro lado, todo debería estar bien en las matemáticas desnudas - o en algunas funciones de la API.
Windows almacena en caché cualquier DLL. Es un caché muy fuerte.
Debido a lo anterior, resulta ser bastante cercano a la realidad. Es decir, si el dll-ine engancha las dependencias -
Entonces el sistema operativo no puede descargarla sin cargar la aplicación que cargó esta DLL.
Esta es una cita de MSDN:
"Cuando el sistema llama a la función DllMain con cualquier valor que no sea DLL_PROCESS_ATTACH, el valor de retorno se ignora".
Es decir, cuando descargas una Dll-in, al sistema le da absolutamente igual lo que pienses de ti como programador allí.
No se puede escribir ni bien ni mal: si no estás en ella, simplemente sale. Si es posible.
Una vez más, para los especialmente dotados - si la dll está escrita sin errores - todo debería funcionar como debería. No existe ningún mecanismo especial para descargar las bibliotecas que se cargan mediante enlace tardío. ¿Está claro? MQL4 no proporciona ningún servicio relacionado con la carga/descarga explícita de Dll a través de Load\FreeLibrary. Del mismo modo, no hay acceso a Terminar.
Pero ya que te consideras un profesional, probablemente puedas aconsejar a los principiantes en lugar de retocar...
No veo que escribas nada importante: elimina la vinculación dinámica del proyecto,
dependencias de los paquetes en tiempo de ejecución, manejar cuidadosamente los Dlls enlazados-no es probable que se usen allí, por supuesto.
se utilizan allí, por supuesto, y posiblemente trabajan con el subsistema COM, donde una sola llamada como OleInitialize puede recoger
docenas de Dlls del sistema. Como todas estas dependencias se cargan a la vez... es fácil con la puesta en marcha,
pero con desinicialización - por ejemplo, si tanto Dll como Metatrader enganchan las mismas bibliotecas del sistema -.
podría haber problemas: quién sabe lo que hay en el fondo del sistema operativo.
Lea a Richter, se lo recomiendo encarecidamente. Queda claro que no hay magia en el trabajo con dlls, y las bibliotecas siempre se descargan tan pronto como ya no son necesarias para el espacio de direcciones del proceso actual. Esta necesidad la determina el contador. Si el contador no se pone a cero hasta el momento de la descarga del programa MQL significa que en algún lugar hubo un error, y un error bruto.
Así que, de hecho, somos usuarios de la API que enganchan todas las funciones Dll - generalmente a través de .h / .lib y la carga de las bibliotecas,
lo más probable es que ocurra en la inicialización de la aplicación, no hay *nada* que podamos hacer.
O bien cargaríamos todas las bibliotecas nosotros mismos y enlazaríamos todas las funciones dinámicamente a mano.
Por otro lado, todo debería estar bien en las matemáticas desnudas - o en algunas funciones de la API.
Debido a lo anterior, resulta ser bastante cercano a la realidad. Es decir, si el dll-ine engancha las dependencias -
entonces el sistema operativo no puede descargarlo más sin descargar la aplicación que cargó esta Dll.
Los desarrolladores de MT4 hicieron muy bien en no poner el mecanismo Load\FreeLibrary en manos de los usuarios. Muy bien. Todo depende del nivel de cultura de programación de los comerciantes.
Y, por último, lea las propias recomendaciones de Microsoft - allí se dice en blanco y negro que aunque es posible hacer dependencias complejas de dlls entre sí - todo esto tiene sus limitaciones.
Windows almacenará en caché cualquier DLL. Tiene mucho caché.
Yo no llamaría al mecanismo de asignación de una dll a un espacio de direcciones de proceso un mecanismo de caché. Es un proceso completamente independiente.
Yo no llamaría al mecanismo de mapeo de dlls a un espacio de direcciones de proceso un mecanismo de caché. Es un proceso completamente independiente.
Eres una especie de bicho raro. Incluso hay un directorio dllcache en el directorio Windows\system32, todos los sysadmins del mundo descargan todas las dlls usando regsvr32, y tú estás contando fábulas a la gente aquí. ¿Con quién cuentas? Aquí no hay idiotas.