|
|
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 ... 159 160 [161] 162 163 ... 205
4001
« en: Martes 8 de Agosto de 2006, 07:48 »
Jajajaja 
¿No descansas nunca? Uff, ultimamente ni estaba entrando ya que me mude de pais 
4002
« en: Martes 8 de Agosto de 2006, 07:45 »
C# no tiene nada de Vb, si no, hubiera sido una porquería. Tiene cosas de Java, Delphi y C++ (como se menciona por allí en otro post).
A mi modo de ver por su arquitectura C# es la evolucion LOGICA de VB. Se basa en el mismo principio de DLLs que hacen el verdadero trabajo.
4003
« en: Lunes 7 de Agosto de 2006, 19:25 »
4004
« en: Domingo 6 de Agosto de 2006, 16:55 »
4005
« en: Viernes 4 de Agosto de 2006, 19:13 »
4006
« en: Viernes 4 de Agosto de 2006, 07:53 »
o reo que los datos son muy acertados.
Java + que C++ si es logico , C++ esta en decadencia en especial desde la entrada de java.
y asm, no asm no es tan usado como tu dices, aunque de que lo usan lo usan , pero n o es representativo al menos comercialmente, por eso no hay buenos ides ni debuggers de asm, o al menos no tan buenos como los que hay para C# y java o C++ No me parece que C++ este en decadencia ni mucho menos, estamos cerca de un nuevo standard, y hay millones y millones de programadores que lo usamos diariamente para nuestros desarrollos profesionales. En muchos campos Java NO es una alternativa a C++, esto es CUALQUIER cosa de medianamente bajo nivel. Otra cosa diferente es que en algunos campos Java haya suplantado a C++, pero reitero que no me parece que este en decadencia ni de lejos. Los VERDADEROS debuggers estan pensados para asm, tanto las herramientas de Windows (WinDbg, kd) o el SoftIce y hasta el OllyDbg por citar uno de modo Usuario. En cuanto a IDEs no conozco ninguno comercial y no creo que tuviera mucho exito, la mayoria de los que programamos en assembly (que somos menos que otros lenguajes pero no menos importantes) nos podemos conformar con el notepad y para los que estamos mas modernizados el Visual Studio nos funciona perfectamente para cualquier lenguaje 
4007
« en: Jueves 3 de Agosto de 2006, 18:44 »
No es que me apasione la idea de un cambio tan radical pero en vista del apoyo que ha tenido lo haremos. En cualquier caso los cambios tendrán que esperar hasta septiembre porque hacerlos requiere su tiempo y mañana mismo me voy de vacaciones. También quiero estudiar más a fondo todas las propuestas que habéis hecho.
Lo que no será necesario es detener el sistema para hacer los cambios. Creo que lo mejor será hacerlos un fin de semana para "molestar" lo menos posible a los usuarios pero no veo problema en hacer los cambios "en caliente".
Un saludo. Felices vacaciones!! 
4008
« en: Jueves 3 de Agosto de 2006, 07:56 »
Cuando se piden cosas tan especificas suenan a trabajo escolar ajeno ...
4009
« en: Miércoles 2 de Agosto de 2006, 20:13 »
Jaja. ¿Porqué?
Yo buscando E-Books leí que decía Assembler y Assembly, ¿o será que "Assembler" es de nacos?.  Assembler es el programa que ensambla y assembly es el lenguaje propiamente dicho (en castellano no existe esta distincion).
4010
« en: Miércoles 2 de Agosto de 2006, 07:59 »
Mientras no pongan assember (ensamblador o assembly) me parece todo bien 
4011
« en: Martes 1 de Agosto de 2006, 19:01 »
La idea esta muy buena, tambien se podra incluir enlaces para la revista de Blag. Admás me parece que seria bueno tener articulos escritos por nosotros y no solo copy, paste de otros sitios.
 Algunos nuestros ya hay 
4012
« en: Martes 1 de Agosto de 2006, 19:01 »
En pocas palabras el problema es que la funcion tiene que usar la convencion de llamada de Windows (stdcall) al ser de tipo callback y dentro de una clase una funcion miembro usa la convencion de C/C++, podes probar a usar una funcion estatica. INT_PTR CALLBACK DialogProc( HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam );
4014
« en: Lunes 31 de Julio de 2006, 21:24 »
4015
« en: Lunes 31 de Julio de 2006, 19:14 »
ahora quveo, anoche saque unos minutos para revsiar y segun entendi:
El modo kernel esta separado de modo usuario y la primera 'interfaz' que enlaza estos dos modos esta en NTDLL.dll, que segun se puede ver es como la primera 'capa' de la WINAPI sobre la cual se montan las subsecuentes librerias de la API de Windows. Basicamente si, NTDLL esta en modo Usuario y provee el codigo que hace el paso a modo Kernel (codigo totalmente dependiente del hardware, int 0x2E en los viejos micros, sysenter/syscall en los nuevos). Por encima se situan muchas DLLs como Kernel32, Advapi32, User32 y muchas mas, esto lo podemos ver con el muy util programa Dependency Walker: http://www.dependencywalker.com/Todas esas tienen dependencias estaticas con NTDLL.dll; como nota curiosa pueden comprobar como tanto las librerias de VB y .NET (o la MFC, o la VCL) dependen de la API de Windows de mas alto nivel creando una abstraccion mas.
4016
« en: Lunes 31 de Julio de 2006, 08:35 »
Y si haces un "modulo" que corra en modo de usuario, tal como lo hace un demonio, seria valido?
Seria pocible?
Si el modulo corre en un VM o es un ejecutable creado con un archive toolkit? Un demonio es en la jerga de Windows un servicio y no es mas que un proceso de modo Usuario. VM != Kernel Mode. ¿Archive toolkit? Ni se que es eso pero tiene que ser un binario valido ...
4017
« en: Lunes 31 de Julio de 2006, 08:33 »
4018
« en: Domingo 30 de Julio de 2006, 21:56 »
Digan si estoy mal, pero en cualquier lenguaje que tenga API al kernel es pocible o que pueda hacer modulos en C/C++ para usar como API directo o indirecto de lenguaje tal como se puede en Python, Ruby, Perl, Java...
 En Windows NT un modulo de modo Kernel no puede tener dependencias mas que con otros modulos de modo Kernel y el propio Kernel por lo tanto lenguajes interpretados quedan excluidos absolutamente. No solo deben ser capaces de llamar al Kernel sino tambien de estar cargados en memoria y para eso no solo hay que carecer de las dependencias de las que hice mencion sino tambien hay que generar un ejecutable PE con subsystem 1:NATIVE (no 2: GUI, ni 3:CONSOLE). En la vida real solo se usa el DDK practicamente, pero tambien se puede hacer con assembly, Pascal y otros (SIEMPRE QUE GENEREN UN PE VALIDO) y enlazando el ejecutable para que dependa solo del Kernel (u otros modulos de modo Kernel) y sea de tipo NATIVE.
4019
« en: Domingo 30 de Julio de 2006, 21:33 »
4020
« en: Domingo 30 de Julio de 2006, 21:17 »
Bien mi idea es poder asignar a las teclas especiales las vocales con tilde y la letra ñ. Las aplicaciones que vienen con el teclado no permiten hacer ese mapeo de caracteres pero se me ocurre que la única forma de hacerlo es creando mi propio driver para el teclado o bien reemplazando alguno de los componentes que hacen parte del driver del teclado, pero nunca he hecho eso y no se muy bien por donde comenzar ni tampoco se si esa es la manera correcta de hacerlo. Tambien se me ha ocurrido hacer un driver en modo usuario o un servicio que este 'escuchando' las teclas o que se yo...
si quieren abro el post nuevo y lo trabajamos alli.  Aunque me parece bien seguir una conversacion por cualquier lado en este caso me parece que lo mejor seria abrir otro tema (asi otros se podrian beneficiar del mismo, aca puede que pase totalmente inadvertido para muchos). En VC++ no le veo mucho sentido pero no veo tampoco un foro adecuado. Lo que podes hacer es un driver de tipo filtro que se situe por encima de la clase del teclado y modifique los datos que le llegan a la misma. Si realmente lo queres hacer esto te servira de muchisima ayuda: http://www.sysinternals.com/Utilities/Ctrl2Cap.htmlWARNING: No es recomendable empezar a meter codigo en modo Kernel sin primero tener muy claro como funciona el S.O., lo mas "suave" que pasara es que veamos una pantallita azul.
4021
« en: Domingo 30 de Julio de 2006, 19:55 »
4022
« en: Domingo 30 de Julio de 2006, 19:40 »
Uli, entonces estoy muerto. ¿Ya no se hacen drivers en C puro?  ¿Te parece que ahi dice eso? Se siguen haciendo drivers en C puro, muchisimos, pero C++ es mucho mas potente que C ... Lo que mas les debe dar gracia es la forma en que evolucionan los temas Eso es algo con lo que jamas estuve de acuerdo, esto es un foro de discucion y como tal me parece que un tema puede derivar en cualquier otro sin problema, no es una escuela donde tenes que hablar sobre la materia en cuestion, esto mas bien es como una conversacion cotidiana donde cualquiera puede meterse y cambiar el rumbo, por lo menos asi lo veo yo.
4023
« en: Domingo 30 de Julio de 2006, 18:05 »
4024
« en: Domingo 30 de Julio de 2006, 09:44 »
me los imagino muertos de la risa cuando ven que se agarran en este foro a pelear por que SO es mejor. jejejeje 
si por eso a mi me odian en todo internet.
http://foro.elhacker.net/index.php/topic,133389.0.html
pero bueno es la peleea de siempre nadie quiere creer lo que el otro dice, y me incluyo. http://foro.elhacker.net/index.php/topic,1....msg623815.htmlY si despues vas diciendo cosas como esta no me extraña eh La API nativa, de la cual te hable en una de nuestras primeras discuciones cuando afirmabas que el Kernel de NT era Kernel32.dll, en gran parte no es mas que una capa que se encarga de pasar de modo Usuario a modo Kernel y que esta contenida en el binario NTDLL.dll, tiene puntos de entrada Nt/Zw que son exactamente iguales (son alias a una misma direccion) y por supuesto se pueden llamar desde VB ya que es una DLL normal y corriente que por cierto esta "mappeada" en todos y cada uno de los procesos del sistema. PD. Aclaro que esto ya me lo pregunto por privado Krnl64 y se lo explique lo mejor que pude. http://foro.elhacker.net/index.php/topic,1....msg623752.htmlSe puden hacer drivers en C++ perfectamente, asi como en assembly. El WDK esta en version beta por lo que es preferible obtener el KMDF 1.1 (Kernel-Mode Driver Framework) con soporte desde Windows 2000 en adelante que es parte del WDF (Windows Driver Foundation), el nuevo modelo de desarrollo de drivers que reemplaza al WDM (Windows Driver Model). Y si digo que es preferible obtener el KMDF hay una razon: contiene el ultimo DDK (Driver Development Kit). Descarga gratuita aca (292mb): http://www.microsoft.com/whdc/driver/WDF/KMDF_pkgdwn.mspx
4025
« en: Sábado 29 de Julio de 2006, 08:12 »
Como para casi cualquier proyecto de redes se usan sockets (en Windows existe Winsock) y se debe aprender el protocolo que se quiera usar en este caso FTP, busca el RFC correspondiente.
Páginas: 1 ... 159 160 [161] 162 163 ... 205
|
|
|
Mostrar Mensajes
