|
|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - Eternal Idol
Páginas: 1 ... 155 156 [157] 158 159 ... 205
3901
« en: Jueves 24 de Agosto de 2006, 18:40 »
Gracias Eternal Idol por la información
He seguido investigando mas sobre estas DLL que llevan internamente el driver que se comunica con los puertos. He encontrado el codigo fuente del Inpout32.dll en la web www.logix4u.net/inpout32.htm, pero necesito mas información detallada de las funciones indocumentadas para sacarle el maximo provecho a estas dll y optimizarlas a aplicaciones propias.
Gracias De nada. Esta parece ser otra DLL que funciona de manera bastante diferente, cada vez que queres acceder a un puerto se comunica con el driver mediante DeviceIoControl y este es el que realmente accede al hardware. Las funciones indocumentadas que hago mencion no te servirian para nada ya que no se pueden llamar desde ninguna DLL (modulo de modo Usuario) sino que tienen que ser llamadas desde el Kernel.
3902
« en: Jueves 24 de Agosto de 2006, 18:01 »
I si con la aplicacion abro el COM1, conecto un cable serie del 1 al 2. Puedo ahora mirar el dos con alguna cosilla de windows? (lo he intentado con "terminal virtual" pero no veo na..)
No he usado break points  i al final he pasado a la marrulleria de los miss. Con esto he visto que la funcion writefile retorna lo que toca. Si desde el COM1 logras enviar datos al COM2 podes usar la misma tecnica para abrir el COM2 y en vez de enviar recibir.
3903
« en: Jueves 24 de Agosto de 2006, 12:49 »
Usa otro depurador como el WinDbg o el OllyDbg por ejemplo.
3904
« en: Jueves 24 de Agosto de 2006, 12:45 »
Estoy compilando el debug, pero donde puedo mirar (VS 6) la linea de comandos que esta generando?
gracias ¿Propiedades del proyecto? La verdad es que no se, hace siglos que no uso VC++ 6.0 y no tengo ninguno a mano.
3905
« en: Jueves 24 de Agosto de 2006, 12:44 »
Tengo un programa que envia (o deberia) enviar datos a traves de uno de los puertos serie.
Qual es la mejor manera de mirar si estoy realmente enviado alguna cosa? Es decir, hay alguna manera en windows de monitorizar lo que se envia por los puertos serie (COM1, COM2)? La manera mas simple seria depurarlo, poner un breakpoint en CreateFile y ver que HANDLE obtiene y despues en WriteFile para ver si logra escribir o no. La dificultad de monitorizar un puerto COM viene dada por la exclusividad del mismo: no pueden haber dos HANDLEs abiertos en todo el S.O. para un puerto COM.
3906
« en: Jueves 24 de Agosto de 2006, 12:09 »
Tal vez estas compilando el release ... sino comproba bien la linea de comandos final, tiene que tener /Zi para que genere el PDB.
3907
« en: Jueves 24 de Agosto de 2006, 09:24 »
Por un lado opino que nosotros solo podemos sugerir ideas, hacer propuestas o como lo quieran llamar, ya en su debido caso tomara una determinacion la persona que debe hacerlo.
Concuerdo con Diodo, no se pueden meter subforos nuevos por meter, tambien es cierto que puede ser un poco asfixiante un foro totalmente de programacion pero ya esta la taberna del bit para algo. Tal vez haya que tener en cuenta dos puntos, la demanda REAL de estos subforos y la cercania con el UNICO tema de este foro que esta claro por su nombre.
Para terminar creo que no valen las comparaciones con esos foros. Forosdelweb solo tiene una clara orientacion a la programacion web y espero que no se transforme este lugar en eso ... Elhacker esta dedicado a eso ... crackers ... espero que tampoco se transforme este lugar en eso. Me parece que el nivel de conocimientos de este foro esta MUY pero MUY encima de esos otros que nombras y es por algo: ESPECIALIZACION en este caso en la programacion.
3908
« en: Miércoles 23 de Agosto de 2006, 19:48 »
¿Se podría comprimir, enviarla así y al recibirla en la otra PocketPc descomprimirla?  Por supuesto que se puede; otra cosa es que sea lo mas efectivo. Si la imagen sera mostrada en ese momento la compresion y descompresion la hara alguien si o si ya que cualquier formato grafico tendra que expresarse pixel por pixel en pantalla. Por otro lado el JPEG generalmente no sustrae bits (casi todas las imagenes que vemos son de 24 bits). http://es.wikipedia.org/wiki/Joint_Photogr...c_Experts_Group
3909
« en: Miércoles 23 de Agosto de 2006, 16:02 »
¿Da una excepcion? ¿Lo estas depurando? ¿Seguro que es en esa funcion? ¿Dentro de la funcion de Windows? ¿Justo antes? ¿Justo despues? Parece mas bien un mensaje relacionado con que pasaste los limites de algun array ... ¿Que hay en el desensamblador?
3910
« en: Miércoles 23 de Agosto de 2006, 11:36 »
Pasarlo a escala de grises te serviria si y solo si cambias la profundida del color a 256 (8 bits) asi el tamaño de la imagen se reduciria. Si lo que haces es conservar los 24/32 bits no te servira de nada. Tambien podes optar por usar alguna libreria de compresion generica tipo Zlib y de esta manera conservar la calidad de la imagen pero transmitir por red menos bytes.
3911
« en: Miércoles 23 de Agosto de 2006, 09:13 »
Yo creo que si sería interesante ese foro. Poneros en el lugar de los usuarios con poca experiencia que no conocen profundamente la estructura de los foros de solocodigos. Donde posteamos las preguntas de mono?  Yo sigo pensando que no. Tal vez estoy un poco confundido pero cuales pueden ser las preguntas de MONO, acaso no deberia ser totalmente compatible con .NET, C# o lo que fuera. Si las preguntas son sobre instalacion, ejecucion o lo que sea, me parece que con la FAQs alcanza y sobra.
3912
« en: Martes 22 de Agosto de 2006, 22:26 »
necesario los driver intermedios como el IO.dll que comentan. En realidad la IO.dll es justamente una DLL, un modulo de modo Usuario, que lleva embedido un driver (es la misma tecnica usada para los recursos de tipo version por ejemplo). Este driver se encarga, mediante un par de funciones indocumentadas, de habilitar el acceso a los puertos de I/O para un determinado proceso (aunque la mascara de los puertos que se habilitan o no es global se puede habilitar o no por proceso, lo que no se puede es dar determinados puertos a unos procesos y otros puertos a otros procesos). Me gustaria si pudiera detallar mas sobre el asunto, ya que me interesa demasiado, ya que soy investigador nato Basicamente lo que hago es establecer una rutina de callback para la creacion de procesos y en esta llamar a las funciones que habilitan los puertos, con lo cual todos los procesos que se vayan ejecutando en la maquina tendran la posibilidad de acceder. Para hacer cualquier tipo de intento con esto hay que tener el DDK, conocimientos sobre Windows NT y modulos de modo Kernel.
3913
« en: Martes 22 de Agosto de 2006, 08:17 »
No, la informacion no esta en la MSDN y no esta documentada por Microsoft en ningun lado que yo sepa. Es mas, las funciones del Kernel necesarias estan exportadas pero no definidas en el DDK, esto quiere decir que tenemos que prototiparlas nosotros mismos.
Por cierto esto no tiene nada que ver con los privilegios que pueda tener un proceso o con servicios, al menos no con lo que comunmente se conoce como privilegios, esto es algo totalmente indocumentado que no se deberia hacer nunca mientras que los privilegios estan perfectamente documentados y son utilizados sin ningun problema.
3914
« en: Martes 22 de Agosto de 2006, 08:14 »
Hace falta algo así en el foro de Asm.
Tenemos moderadores un poco flojos.  El foro de asm engloba varios ensambladores diferentes (masm, tasm, fasm, nasm, etc) bajo al menos un par de arquitecturas (x86 & x64), es mucho mas sensato en este caso que se hagan preguntas especificas.
3915
« en: Lunes 21 de Agosto de 2006, 22:41 »
Si van a haber 10 mensajes en total ... no creo que valga pena, lo que seria interesante de hacer es una guia, faq o lo que fuera necesario al respecto ya que no es un lenguaje ...
3916
« en: Lunes 21 de Agosto de 2006, 15:54 »
Podes hacerlo asi: checksum = GetCheckSum(msg);
y asi: checksum = GetCheckSum(&msg[0]);
El codigo generado es el mismo; obviamente tendras que establecer un metodo por el cual conocer el tamaño del bloque a procesar ... te recomiendo un segundo parametro a la funcion.
3917
« en: Lunes 21 de Agosto de 2006, 15:29 »
Mmm me juego a que tenes Main.cpp e Init.c; Si tu proyecto es de C++ cambiar todos los modulos a .cpp y si es de C cambialos todos a .c, otra manera de solucionarlo es declarando las funciones como extern "C", el problema esta muy claro en la linea del enlazador, esta buscando esto (simbolos de tipo C++): "void __cdecl Init(void)" ( ?Init@@YAXXZ)y en realidad solo puede encontrar (simbolos de tipo C): _Init Cambiando solo el codigo: #ifdef __cplusplus extern "C" { #endif void Init(); void InitAlarm(); void AlarmFunc(void *); #ifdef __cplusplus }; #endif
PD. No deberias utilizar <> sino "" para incluir archivos que deberian estar en el mismo directorio de compilacion y no en directorios por defecto ...
3918
« en: Lunes 21 de Agosto de 2006, 08:18 »
Como ves el ultimo mensaje del hilo tiene casi un año y la respuesta obviament es no. Termine de hacer el loader tal como describia arriba y deje por la mitad el Kernel.
3919
« en: Domingo 20 de Agosto de 2006, 17:35 »
Como bien dice JuanK las funciones exportadas por los Kernels son diferentes, tambien el formato del ejecutable es totalmente distinto.
3920
« en: Domingo 20 de Agosto de 2006, 15:42 »
Estuve investigando un poquito como habilitar el acceso a los puertos I/O, es relativamente simple de conseguir y termine con un modulo de modo Kernel que habilita el acceso a todos los procesos que se vayan ejecutando. Si se lo carga en boot todos los procesos del sistema (desde smss.exe que es el primero) podran usar in's y out's sin problemas.
En fin, no se si le interesara a alguien ...
3921
« en: Viernes 18 de Agosto de 2006, 11:26 »
3922
« en: Jueves 17 de Agosto de 2006, 16:08 »
Además, creo que con el XNA se reduce el presio de los juegos
O sea, como con el mismo código fuenta, lanzan 2 versiones PC y XBOX al mismo tiempo. No, no, no el precio es lo que le cobran a la gente como nosotros cuando va a comprar y ese seguira igual de alto. Lo que se reduce es el costo de desarrollo con lo cual gastan la mitad y cobran lo mismo  Segun entendi no solo seria el mismo codigo fuente sino el mismo binario 
3923
« en: Jueves 17 de Agosto de 2006, 15:24 »
Y que pasa con Play Station?
¿No siguen con C++? Creo qeu a Sony les da por las "~@#@$~" el XNA. Supongo que la apuesta de Microsoft es comerse el mercado de PlayStation con XBox 360 y mucho mas si los estudios solo tiene que hacer un juego y este sirve tanto para PC como para XBox ... es una ventaja ENORME a mi modo de ver.
3924
« en: Jueves 17 de Agosto de 2006, 15:23 »
Si eso creo, lo que opino es que para cualquier empresa que desarrolle para Xbox y para PC le sera muy llamativo no tener que hacer mayores esfuerzos, por no decir que casi ninguno, en hacer un juego que corra en ambas plataformas de manera transparente  Si, lo habia agregado despues ya que me parece algo por lo cual valdria la pena realmente usar el XNA, pero sera XBox 360 segun puedo leer por ahi. Sin embargo como se dice por aca, creo que si le pegue al perro con lo que dije porque de hace 3 o 4 años nadie daba aun peso por juegos hechos en C#, de hecho nadie lo creia posible, y hoy en dia ya existen juegos hechos en C# y ahora XNA le tiende la mano con lo que ha propuesto, pero es cierto solo el tiempo lo dira, porque se puede venir todo abajo pues no creo que la competencia se quede quieta. Creo que no estaba en ese tiempo por aca asi que me abstengo de opinar al respecto. En cuanto a la competencia dudo que pueda hacer mucho bajo Windows ... por lo menos me parece que la experiencia de DirectX marca una pauta.
3925
« en: Jueves 17 de Agosto de 2006, 15:14 »
3- off topic-- muchos se han burlado de mi cuando decia que el futuro de los videojuegos no era C++ sino C#.NET... La prudencia es buena consejera, seria una buena apuesta teniendo en cuenta que Microsoft esta llevando adelante ese proyecto PERO por ahora es eso, un proyecto. Tal vez dentro de dos o tres años se convierta en una realidad y sea muy utilizado pero quien sabe, puede que fracase estrepitosamente tambien. Yo creo que no dependera, como espera Microsoft, de una llegada masiva de desarrolladores amateurs al mundo del videojuego (al menos eso entendi en las noticias de la tv) sino que dependera en mucho mayor medida en la adopcion de estas herramientas por parte de los profesionales. Si los grandes estudios, los que disponen de un equipo de profesionales para cada rama (sonido, gfx, codigo, guion, etc, etc) adoptan XNA entonces el futuro sera tal como lo planteas. Ah, y agrego que me parecio interesante que soporte XP, Vista y XBox 360 pero por el otro lado te recuerdo que siguen habiendo otros S.O. en el mercado como Windows 2000 (algo tienen que hacer para que nos mudemos a XP todos) y la consola XBox todavia existe me parece.
Páginas: 1 ... 155 156 [157] 158 159 ... 205
|
|
|
Mostrar Mensajes
