mira si el compilador que usas te deja especificar el subsystem y le pones gui, si no te deja igual te detecta al modificar al flag pq esta mal el cheksum.

es raro que en hd media te diga de buscar el cdrom, a mi me dice que buscara una imagen valida en el dispositivo (la iso). de todos modos en algun pc me a pasado que estando la imagen no la encuentra, entonces lo hago de esta forma:

el pendrive booteable por un lado, otro pendrive con la iso arrancas y ya la encuentra. pero esto en el caso que te diga que no encuentra una imagen en el dispositivo. como te digo a mi del cdrom ni me sale ¿seguro que estas haciendo bien los pasos?

para que tanta discusion sobre el espejo? si cada uno vemos las cosas a nuestra manera. nadie ve todo exactamente igual que otra persona.... nos engaña nuestro propio ojo.

y dale.


pero repetimos, el cliente te llama a ti y una leve ojeada a la documentacion:


No he dicho que uses send logicamente, tienes que copiar los datos al buffer y devolver el numero de bytes, tal como si llegasen desde el socket (esto no lo sabe el cliente).


perdona, el que no esta entendiendo eres tu.


eso no es ni por asomo como te digo, si fuese como te digo eso volveria al cliente aun sin que llegasen datos y es eso lo que tienes que controlar tu.


No hay que ejecutar nada, lee la definicion de la funcion otra vez.


hijo mio, es precisamente lo que te estoy explicando. para que lo entiendas, pilla el codigo de la msdn y compilalo tal cual y observa que espera hasta que el servidor responde. ahora bien aplicale lo que te digo y veras que no espera y que deja la espera retornando WSAETIMEDOUT una vez obtienes el timeout si quieres puedes hacer creer al cliente que le a llegado informacion..... y repito copias los datos al buffer y le devuelves el numero de bytes copiados.

Cuando hay timeout quiere decir que el servidor no envio nada, por eso logicamente no pierdes datos. siendo esto asi, tu eres el encargado de decirle al cliente cuando se a cerrado la conexion. para mas datos http://msdn.microsoft.com/en-us/library/ms740668%28v=VS.85%29.aspx


Despues te queda otra que es hacer que el cliente pase por tu aplicacion para conectarse (a modo proxy local) de esta forma tienes mas facil enviarle cuando quieras datos al cliente ya que para el tu eres el servidor.

Hookeas socket = Guardas el manejador.

setsockopt activas SO_RCVTIMEO = Ya no queda "enganchado" y te llamara todo el rato. esta funcion tiene que estar escrita perfectamente para evitar fallos de conexion.

hookeas recv = copias al buffer los datos y retornas el numero de caracteres copiados.

Y no me digas que no funciona pq lo he probado aproposito. esto haciendolo simple, para mas detalles te lees la documentacion.


de primeras tu no ejecutas nada, es el programa el que llama a la funcion y no tiene que leer nada, es la funcion la que copia los datos en el buffer.


El codigo es precisamente de la MSDN. a mi me sorprende que como no sabiendo usar punteros a funciones seas capaz de hacer un hook.

No sabes ni que estas diciendo,me rindo contigo.

En la misma msdn tienes este codigo:


recv en tu caso llama a tu dll, solo tienes que copiar los datos al buffer y hacer return sin llamar a la funcion original.

yo tampoco te he faltado el respeto.


aun piensas que no puedes hacer llegar lo que tu quieras al exe? yo creo que si.


tu mismo te contestas.


pues te conteste lo mas logico, si la funcion esta en el cliente lo mas logico es un puntero a funcion. esto implica, localizar la funcion, parametros que acepta y poco mas, esta es la forma correcta de hacer lo que pides. pero si te empeñas en hacerlo desde el socket, poder se puede.