FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Software heredado en DOS es mas rapido?
Hola amigos.
Queria desarrollar una aplicacion para una estacion de servicio Axion en Argentina. Mas precisamente los surtidores funcionan con el sistema Fusion.. Con el cual hay que comunicarse para obtener el despacho de combustible. El caso es que muchas estaciones de servicios tienen software heredados en DOS.. Como ya saben pantalla azul con letras blancas. En fin.. Se sabe que funcionan bien aunque son muy antiguos. Pero la pregunta es si un software hecho en Delphi.. Nunca seria tan rapido como uno de DOS? Me refiero a que este ultimo es de mas bajo nivel y no tiene interfaz grafica. Y cuales son los puntos a seguir para que un software en Delphi sea lo mas agil? |
#2
|
|||
|
|||
MS-DOS vs WINDOWS: ni mejor, ni peor, ni más rápido, ni más lento.
Windows te permite cosas que MSDOS son imposibles o MUY complicadas. No veo como puedes hacer una gráfica (estadística) en MSDOS, sería complicado enviar un email o generar un PDF (seguramente usarías otra aplicación más moderna y windows (con DLLS) que te hiciera el trabajo). Tampoco conozco bases de datos MSDOS con triggers o replicación. Tampoco creo que en los surtidores de gasolina, cambie mucho de 0.1seg a 0.2segundos, suponiendo que Windows fuera más lento. Yo empecé programando en MSDOS (como muchos de este foro) y siempre te recomendaría Windows. |
#3
|
||||
|
||||
Muchas apps en DOS son y/o se perciben mas rápidas porque en muchos aspectos son mejores. Ademas, tener "limitaciones" como solo una app a la vez en pantalla aumenta el enfoque del usuario. Es similar a iPhone/iPad donde muchas cosas son mas ágiles de hacer (por ejemplo, tengo un Mac con 2 monitores y a veces cojo mejor el iPhone pa hacer cosas que se son mas rápidas de hacer allí).
Si tienes acceso a esa app, puedes darte una vuelta y ver que cosas hace muy bien. Notaras que por ejemplo, las app de DOS están diseñadas para usar el teclado de forma primaria (y no el mouse!) lo que permite a los usuarios operarlo de forma rápida. Eso es porque no tienes que estar haciendo "cambio de contexto" de teclado -> mouse -> teclado para completar tareas. Asegurate que todo se pueda hacer en un solo flujo con uno o con el otro, y que combinarlo sea por gusto del usuario. Si lees acerca de lo que piensan usuarios de apps en ese estilo (como WordStar, Emacs o FoxPro) veras varios puntos interesantes. Otro aspecto que es fácil pasar por alto: Las pantallas de DOS tiene EXCELENTE contraste y usan TEXTO en vez de iconos ambiguos (que están muy de moda ahora, en vez de los iconos mas detallados de la época windows 95/OSX viejos). También por la falta de espacio solo se ve lo más relevante, pero no como ahora por moda de hacer interfaces "limpias" sino porque toca!. Ademas aunque en tipografía no tienen mucha variedad, por la resolución el texto se ve un pelin mas grande y esta hecha para ser legible aunque algo feito. Las fuentes modernas de cada OS son buenas, pero es mejor darles un pelin mas grande pa que sea mas legibles, y usar jerarquías que ayuden a ver el flujo de la información*. Por lo demás, usando hardware moderno y técnicas modernas una app nativa windows/osx DEBERIA ser mucho mas rápida, en especial al operar con metas/teras de datos. No es así por mal diseño y sobre-ingeneria recargada, no porque el hardware lo obligue. P.D: Si quieres leer mas acerca de diseño hace poco escribí algo en http://www.clubdelphi.com/foros/show...09&postcount=4
__________________
El malabarista. Última edición por mamcx fecha: 31-03-2021 a las 18:35:26. |
#4
|
||||
|
||||
En realidad no es comparable. DOS es monotarea, y además los compiladores no están pensados para los microprocesadores modernos (incluso con los últimos Pentium los programas eran a veces más lentos que con los 486 debido a la introducción de las caches internas a pesar de tener más hercios).
Por contra, para cosas sencillas (como los surtidores, por ejemplo) DOS puede ser más eficiente que Windows o Linux precisamente por ser monotarea (no se me ocurre por qué un surtidor o un cajero automático necesitaría ser multitarea, la verdad). |
#5
|
|||
|
|||
Bueno muchas gracias a todos por sus ideas. Lo que sucede que el dueño de la empresa me dice que el sistema heredado en DOS es mas rapido.. O se le hace je.
Windows trabaja sobre DOS? |
#6
|
|||
|
|||
Cita:
Puede parecer de broma pero no lo es tanto. Saludos
__________________
"La forma de empezar es dejar de hablar y empezar a hacerlo." - Walt Disney |
#7
|
||||
|
||||
Ya no. La última versión que tenía kernel DOS fue Windows Me. De ahí en adelante se usó únicamente kernel NT hasta Windows 8. [edito] Acabo de buscar en Internet (debí hacerlo antes) y según Wikipedia Windows 10 también usa NT, pero más adelante lo han mezclado con un kernel Linux (no sé cómo de legal lo hayan hecho, porque en teoría deberían haber publicado el código fuente, aunque no me consta, aunque si lo usan tal cual, sin modificar, entonces no sería necesario).
Última edición por Ñuño Martínez fecha: 02-04-2021 a las 12:51:54. |
#8
|
||||
|
||||
Como te explique, es principalmente un asunto de diseño(flujo), mas que de poder "puro".
__________________
El malabarista. |
#9
|
||||
|
||||
Cita:
En términos generales, todos los OS de ahora tiene MULTIPLES micro-vms y sistemas similares corriendo. Por ejemplo, incluso los equipos x86 tienen uno o varios subprocesos sobre ARM. Por la parte de compartir código? MS ahora tiene una muy amplia presencia en el mundo open source.
__________________
El malabarista. |
#10
|
|||
|
|||
Cita:
Bueno la mayoria de aplicaciones heredadas en DOS estan hechos en Foxpro para DOS y Clipper, ambas alla por los 80 y comienzo de los 90 era lo mejor para manejo de base de datos, configuras bien los indices y con la tecnología rushmore acelerabas el proceso de acceso a datos. -Foxpro para DOS y sus librerias esta hecho en c y por eso velocidad de ejecucion es buena y aun no manebaja el concepto de eventos como lo maneja windows que tiene ventos para coda cosa. Si sumas esos factores claro que aparenta velocidad una aplicacion DOS. -Clipper es un lenguaje compilador y ya sabemos que significa eso por nuestro querido pascal asi que no hay mucho que explicar. Por conguiente es veloz. -Ambos entornos sus instrucciones para procesar datos son directas, no hay drivers. Ahora en estos tiempos como ya te dijeron otros compañeros del club, ahora no es ni mejor ni peor mas bien las aplicaciones windows tienen mas ventajas por todas la bondades que trae la interfaz gráfica. En object pascal (delphi) obtienes las misma velocidad porque es lenguaje compilador pero para ayudar esto debes tener una base de datos configurada con los indices adecuados y veras que es casi igual que las aplicaciones DOS. Estos 3 lenguajes de programación son d ealto nivel asi que no aplica el nombre de bajo nivel, a menos que en pascal incluyas instrucciones en lenguaje ensamblador. |
#11
|
||||
|
||||
Me permito dudar que el sistema funcione en MS.DOS, sobre todo por el soporte de red y drivers. ¿No será una distribución de linux?
Si quieren que la app siga en modo texto, sin interfaz gráfica, podes desarrollar algo de alto nivel usando ncurses o similar. Y para que la aplicación sea ágil en modo gráfico, creo que el secreto que no es secreto, es desarrollarla de forma tal que prescindas totalmente del mouse/touch. O sea que el flujo de trabajo se limite exclusivamente a la entrada por teclado, como pasaba en las aplicaciones de DOS.
__________________
delphi.com.ar Dedique el tiempo suficiente para formular su pregunta si pretende que alguien dedique su tiempo en contestarla. |
#12
|
||||
|
||||
Cita:
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Cambiar TForm a formulario heredado | newtron | Varios | 3 | 11-04-2020 10:55:12 |
Ayudenme Rapido, Rapido | omarys | Varios | 6 | 04-06-2011 10:45:34 |
Siete prácticas para un óptimo y rápido desarrollo de software | poliburro | Noticias | 5 | 30-07-2008 17:48:55 |
Ocultamiento de método heredado | supermilloriver | OOP | 4 | 22-03-2007 06:20:56 |
Los eventos y un componente heredado de TGraphicControl | zuriel_zrf | OOP | 1 | 01-10-2004 01:55:32 |
|