QBasic (et GwBasic au passage) permettaient effectivement un accès direct et facile au matériel, par contre ce n'est juste pas possible dans un contexte multi-taches.
Imagine deux secondes différentes applications essayant chacune de configurer l'écran différemment (screen 0 et screen 12) qu'est-ce qui est censé se passer ?
Maintenant il reste deux solutions:
1. travailler bare-metal, c'est à dire sans OS en étant seul à utiliser le matériel. par contre il va falloir se coltiner la gestion dudit matériel qui s'est bien complexifié. Pour rappel un 8086 c'est (environ) 29000 transistors quand un processeur moderne contient en plus d'un milliard. Et ne parlons pas de la carte graphique.
utiliser un framework du type libSDL qui va se charger de demander "poliment" à l'OS de lui réserver une part de l'écran voire l'écran entier. Dans le cas de libSDL on aura également accès aux accélérations matérielles (blitting par exemple).
[^] # Re: On parle d’un temps ...
Posté par flavien75 . En réponse au message Juste afficher un point à l’écran. Évalué à 1.
QBasic (et GwBasic au passage) permettaient effectivement un accès direct et facile au matériel, par contre ce n'est juste pas possible dans un contexte multi-taches.
Imagine deux secondes différentes applications essayant chacune de configurer l'écran différemment (screen 0 et screen 12) qu'est-ce qui est censé se passer ?
Maintenant il reste deux solutions:
1. travailler bare-metal, c'est à dire sans OS en étant seul à utiliser le matériel. par contre il va falloir se coltiner la gestion dudit matériel qui s'est bien complexifié. Pour rappel un 8086 c'est (environ) 29000 transistors quand un processeur moderne contient en plus d'un milliard. Et ne parlons pas de la carte graphique.
Bref deux salles, deux ambiances
Les vrais naviguent en -42