|
|
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 - rfog
Páginas: 1 2 [3] 4 5 ... 7
51
« en: Miércoles 2 de Febrero de 2011, 12:49 »
Primero: no escribas en mayúsculas que es como si estuvieras gritando.
Segundo: pon aquí el código de creación y apertura de ese cuadro no modal a ver qué estás haciendo mal.
52
« en: Martes 25 de Enero de 2011, 15:35 »
Aún asi, insisto en el punto más importante a mi parecer:
De todas formas no tiene sentido alguno desarrollar nada para 16 bits en la actualidad. Ciertísimo. De todos modos... conozco una empresa de Europa del Este que todavía monta máquinas industriales con un x86 en modo real de 16 bits con MS-DOS (bueno, una variante OEM modificada por ellos mismos)... Lo único es que las placas las fabrican y montan ellos. Son una variante entre un PC-XT y un PC104 industrial...
53
« en: Martes 25 de Enero de 2011, 09:21 »
El hardware moderno ejecuta perfectamente un sistema de 16 bits, así que MS-DOS funcionaría perfectamente en cualquier PC (siempre ke encuentres cómo instalarlo). Es la lacra de retrocompatibilidad a la que nos tiene acostumbrados Intel (y últimamente por culpa de AMD). Y de todas formas una máquina virtual no es más que una representación abstracta del hardware de ahora. Así que si funciona en una MV, funciona en una máquina real.
De todas formas no tiene sentido alguno desarrollar nada para 16 bits en la actualidad. anda mira, alguien que opina lo contrario, pues entonces habrá que intentarlo.
Por cierto no pensaba instalar msdos sino cargarlo directamente desde el cdrom, como he hecho ya varias veces, la única duda es si voy a poder acceder al sistema de interrupciones y en general si voy a poder hacer funcionar una aplicación de 16 bits. Está claro que es cuestión de probarlo y comprobar a ver, pero antes de intentarlo prefiero preguntar a ver si va a ser posible o no.
A ver, si te carga en un ordenador moderno (yo sigo dudándolo -en la mayoría de los modelos de placa base modernos dice bien claro que "esta placa no soporta MS-DOS ni Windows 9x"), es un MS-DOS real con todas las cosas reales y tendrás acceso a todo. De todos modos ya veo que lo que tu quieres cargar no es un MS-DOS puro, porque hasta donde yo sé, MS-DOS no puede cargar desde CD/DVD porque una vez ejecutando su núcleo no sabrá cómo leer de él antes de cargar el driver del CDROM, y para cargar el driver primero necesita leer del CD dicho driver y no podrá porque no sabe cómo leer...   De todos modos, en una máquina virtual, al menos Virtual PC y vmWare, MS-DOS sí que funciona con *casi* todo lo que le eches. Vamos, que la Int10, la 21 y las demás, las tendrás seguro.
54
« en: Domingo 23 de Enero de 2011, 16:52 »
Para ejecutar un MS-DOS en real, la BIOS de tu ordenador tiene que ser de 16 bits, y las BIOS de los ordenadores son desde hace mucho tiempo de 32 Bits, y ni siquiera tienen las rutinas de la Int10, ni tampoco las posiciones de memoria "mágicas" en el primero mega real que usa el DOS.
De todos modos, prueba a ver.
55
« en: Domingo 23 de Enero de 2011, 15:52 »
Claro, te mantienes en un estándar abierto pero usas cuadros de diálgo de windows, o peor aún, C++/CLI como está usando Burns... Con lo que usar el estándar POSIX tiene toda la razón del mundo.
Si en un programa .NET (no sólo C++/CLI) usas algo nativo, como las funciones del runtime de C que propones, eso significa varios cambios de contexto entre la máquina virtual .NET y el código nativo, en contra de usar la propia biblioteca de .NET, que hará el cambio de contexto cuando sea necesario...
Vamos, que haciendo un programa en C++/CLI tiene mucho sentido respetar los estándares...
56
« en: Domingo 23 de Enero de 2011, 14:45 »
Pues hombre, QT no es muy difícil de aprender, y encima es multiplataforma y está de moda, con lo que hayas creado con visual c++ podrás llevarlo a mac y linux sin mucho esfuerzo (si no pillas uno de los bugs que están en esas dos plataformas y no en la de windows)...
Si lo haces con Win32 o MFC, te veo medio año aprendiendo antes...
Visual C++ es un entorno y compilador para windows agnóstico en cuanto a qué framework usar, trae su propio framework, MFC, pero digamos que es difícil, muy difícil. Y win32 no es difícil pero sí enormemente laborioso...
Así que lo mejor es que leas sobre lo que te he comentado y elijas.
Incluso podrías elegir C++Builder y su VCL.
57
« en: Domingo 23 de Enero de 2011, 13:19 »
La primera respuesta que tienes que encontrar es qué Framework vas a usar: Win32, MFC, QT, wxWidgets...
58
« en: Domingo 23 de Enero de 2011, 12:56 »
bueno, a ver. Yo pensaba ejecutarlo en msdos, pero según tú no hay hardware que sea capaz de ejecutarlo, si es así, desde luego desisto en mi intento. Es decir, no hay posibilidad de cargar el msdos en una máquina moderna? (Pentium core2duo). Recuerdo haberlo cargado desde un cdrom hace ya algún tiempo pero no se si sería el propio msdos. El programa no tiene ningún uso, es simplemente para trabajar con las interrupciones de msdos y probar algunas cosas.
Por lo demás probaré el open watcom.
un saludo. Creo que no. Y menos todavía interrupciones y accesos directos a bios... Puedes hacerlo en una máquina virtual, instalarte un Virtual PC o un vmware o cualquier otro que soporte DOS y probar desde ahí, pero son entornos completamente simulados y no sé hasta qué punto terminarán permitiendo interrupciones y esas cosas... Y por otro lado, a fecha de hoy, aprender todo eso es perder el tiempo... TU mismo.
59
« en: Sábado 22 de Enero de 2011, 23:19 »
¿Y qué puñetas tienes que hacer para MS-DOS de 16 bits? No creo que haya en el mercado ningún hardware que sea capaz de ejecutar eso. Desde hace por lo menos cinco años ninguna placa trae BIOS de 16 bits, por lo que ni siquiera podrás ejecutar un mísero Windows 3.1 o Windows 95... De todos modos tienes el Open Watcom, que trae IDE incorporado y todo: http://www.openwatcom.org/index.php/Main_PagePero no esperes poder ejecutar nada en modo msdos real desde windows xp... Y no, el DevC++ creo que tampoco te valdría.
60
« en: Sábado 22 de Enero de 2011, 19:58 »
Mi forma es estándar, la que propones tú no lo es. Y tu forma abrirá una consola, incializará el sistema de consola, lanzará la aplicación, cerrará el sistema de consola, perdiendo la relación padre/hijo que se puede tener con la forma descrita, con lo que todos los handles heredados y demás se perderán.
61
« en: Sábado 22 de Enero de 2011, 19:49 »
No.
Las aplicaciones de consola son de 32 ó 64 bits, nativas de win32/win64 con la capa .NET encima. La consola de windows no es más que una emulación de un terminal, y de hecho la versión de 64 bits no permite ejecutar código de 16 bits. La de 32 creo que sí, pero con extraordinarias limitaciones.
Además, el .NET no está disponible para 16 bits.
63
« en: Martes 28 de Septiembre de 2010, 09:40 »
Te está diciendo que has inicalizado la estructura (o el array de estructuras) con demasiados elementos. Mira a ver cual sobra.
64
« en: Domingo 26 de Septiembre de 2010, 23:22 »
Declaras el método terreno::terreno pero no lo implementas en ningún lado...
65
« en: Domingo 26 de Septiembre de 2010, 10:53 »
Quita el "FAR" de la declaración del array. Eso es de la época de los 16 bits. Aparte de ser un anacronismo creo que ya no está definido en los compiladores modernos. Lo del warning se debe a que sprintf() está "obsoleta" por MS ya que es uno de los caminos por los cuales se pueden producir fallos de seguridad mediante desbordamiento de bufer. El equivalente moderno es sprintf_s(), pero tiene más parámetros. http://msdn.microsoft.com/en-us/library ... kh(v=VS.80).aspx Ahí te explica que puedes o bien poner las funciones _s o bien poner #define _CRT_SECURE_NO_WARNINGS antes de las inclusiones de los ficheros cabecera estándar. Yo te recomiendo que sustituyas las funciones normales por las seguras a no ser que necesites que tu código compile para linux o mac...
66
« en: Sábado 25 de Septiembre de 2010, 13:29 »
Si no hubieras tocado nada de la configuración, tendrías dos carpetas, una llamada Debug y otra Release, con el ejecutable de cada versión. Ahora que has tocado eso cualquiera sabe dónde la has liado.
Por otro lado, no puedes distribuir un ejecutable en modo Debug, ni las DLL asociadas a ello, no de forma legal.
El problema que te da de ordinales faltantes se debe a que estás mezclando versiones de DLLs. Espero que las que has ido colocando en el ordenador de destino las metieras en la misma carpeta que el programa, porque si lo has hecho en C:WindowsSystem32, Windows se habrá "adueñado" de ellas y las habrá colocado en la caché SxS, con lo que ahora tendrás un sistema inestable y que cuando algún programa use esa versión de DLL de MFC, fallará, sea el programa que sea (no solo los tuyos)...
67
« en: Jueves 23 de Septiembre de 2010, 10:53 »
Y WriteFile luego para guardar el sector modificado, pero antes tienes que retroceder a la misma posición en la que leiste el sector.
68
« en: Lunes 20 de Septiembre de 2010, 21:54 »
Usa CreateFile() con una ruta UNC completa (en la documentación de la MSDN de CreateFile, en la parte de discos físicos y volúmenes está qué es eso: http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx Eso sí, necesitas los permisos adecuados para hacerlo.
69
« en: Lunes 20 de Septiembre de 2010, 21:52 »
Lo primero es que no puedes activar el compilador de C con C++/CLI (la opción /clr), en modo mixto tienes que usar C++.
Lo otro es que te faltan las rutas a los ficheros.
Si te dice que no puede encontrar "print.h" es porque ese fichero no está en ningún sitio en donde busca el compilador, incluida la carpeta en donde está el fichero que hace la llamada de la inclusión.
70
« en: Martes 7 de Septiembre de 2010, 10:42 »
¿MFC, Win32, Windows Forms?
71
« en: Lunes 6 de Septiembre de 2010, 16:35 »
Usa la función strstr() de C, que te devuelve un puntero a la posición de la segunda cadena respecto a la primera. Luego restas los punteros y tienes la posición.
72
« en: Lunes 6 de Septiembre de 2010, 16:33 »
Ya te he respondido por qué en el otro hilo.
73
« en: Lunes 6 de Septiembre de 2010, 16:32 »
C# no es C++.
En el editor de propiedades tienes una propiedad que se llama ShowInTaskbar (o de nombre parecido, escribo de cabeza). Ponla a false y listo.
El atajo de teclado para minimizar es Alt-Espacio y luego n, pero si capturas el evento de keypress (creo que se llama así) puedes coger la combinación que quieras y mandar minimizar la propia ventana.
74
« en: Lunes 6 de Septiembre de 2010, 16:30 »
Eso no te funciona porque estás usando una variable local para cambiar el color. O bien declara una instancia de la clase como global o bien obtén de alguna manera su puntero y trabaja sobre él.
Páginas: 1 2 [3] 4 5 ... 7
|
|
|
Mostrar Mensajes
