Borland C++ v3.1

Bonjour,

Je fais tourner un programme écrit en C++ et compilé avec une version 3.1 de Borland C++ sur mon PC Windows8 au travers d'une VirtualBox .
Tout fonctionne parfaitement sauf un détail : le programme dans son déroulement va écrire directement dans la zone mémoire de l'écran pour y inscrire un texte.
La fonction consiste à écrire au bon endroit dans cette zone un octet attribut dont les 3 ou 4 premiers bits représente la couleur du caractère et les 3 ou 4 derniers règlent la couleur de fond.
Pour faire clignoter le texte, il suffit normalement de mettre le bit msb à 1 et le tour est joué. Mais pour moi ça ne marche pas.
Le clignotement fonctionne bien sur la machine d'origine qui tourne sous Windows 3.11 mais pas sur la VM qui a pourtant repris l'intégralité du disque d'origine.
Pouvez-vous m'aider à trouver une solution, svp ?
Bruno.

Citation:

---

Je fais tourner un programme écrit en C++ et compilé avec une version 3.1 de Borland C++ sur mon PC Windows8 au travers d'une VirtualBox .

---

Whouaou, là, c'est retour vers le futur en mode Égypte Antique de l'informatique. :weird:

Citation:

---

le programme dans son déroulement va écrire directement dans la zone mémoire de l'écran pour y inscrire un texte.

---

On est d'accord pour dire que ce genre de truc, c'est même pas du Windows3.1, mais du DOS de 1980 bien cra-cra ? :aie:

Citation:

---

d'origine qui tourne sous Windows 3.11 mais pas sur la VM qui a pourtant repris l'intégralité du disque d'origine.

---

Oui, ok, mais là, vous n'utilisez absolument pas ni DOS, ni Windows, ni aucun machin qui est dans le disque d'origine. :weird:

Vous utilisez directement des "fonctions" du bios/hardware qui ne sont clairement pas portable, même à l'époque de Ramsès II.

Pour que cela marche, il faudrait que VirtualBox émule un hardware avec un bios datant des années 80/90, ça va être chaud bouillant votre machine.

Je ne connais plus Borland C++ depuis les pyramides de Gizeh mais je pense qu'il y a des compilateurs Borland capable de faire une migration sans trop de dégâts, si le code initial n'est pas trop pourri.

Franchement, un redéveloppement avec des outils modernes peuvent être une solution très envisageable, non ?

Normalement, le code métier est séparé du code de l'IHM, et vous n'auriez qu'à refaire l'IHM avec les outils et guidelines modernes.

Le problème, c'est que tu ne peux pas avoir à la fois:

• le clignotement
• 4 bits de couleur du texte
• 4 bits de couleurs d'arrière-plan

Fais-toi un programme de test (affiche une grille de 16*16 où tu testes toutes les valeurs), je parie que sur la nouvelle plate-forme le clignotement a été remplacé par 4 bits dans les deux couleurs.

Et d'après mes souvenirs, ça date au moins du DOS livré avec Windows 98, donc aucune chance de le récupérer.

Salut,

Une petite question totalement idiote : es tu au courant que la version 3.1 de borland C++ date de ... 1992 :question:

Pour te donner une vague comparaison, la première standardisation du langage date de 1998, c'est à dire que cette version du compilateur date -- pour continuer avec les comparaisons -- littéralement de la préhistoire du C++.

Vouloir utiliser la version 3.1 de borland C++ revient, à peu de choses près, à devoir faire trois cents km tous les jours pour aller travailler et à vouloir les parcourir avec... une ford T. Et je ne te parle même pas du problème qu'il peut y avoir à vouloir utiliser la version 3.1(1) de windows, qui est à peu près aussi antédéluvienne que ta version de borland ;)

Ceci étant dit, et pour tenter d'apporter un semblant de réponse à ta question : le problème vient surement du fait que tu utilises une machine virtuelle.

Il faut en effet comprendre qu'un système d'exploitation se divise en deux parties : le "noyau" (le kernel) qui s'occupe de gérer l'ensemble des ressources disponible et qui s'exécute (pour faire simple) avec un ensemble de droits particulièrement élevé et la partie "utilisateur" qui ne dispose que de droits "beaucoup plus restreints", mais qui peut régulièrement faire appel au noyau (au travers de ce que l'on appelle des appels système ) pour accéder à certaines ressources dont le noyau s'occupe.

On parle régulièrement de user mode pour désigner le mode dans lequel s'exécutent les programmes destinés à l'utilisateur (et qui n'ont qu'un ensemble de droit réduits par rapport aux ressources de l'ordinateur) et de kernel mode pour désigner le mode dans lequel le noyau du système d'exploitation s'exécute.

Le fait est que tout ce qui a trait à la console ou à l'environnement graphique sous windows s'exécute en user mode, ce qui implique que toute application est systématiquement dépendantes des appels systèmes auxquels elle a accès au travers du noyau. A ce titre, une machine virtuelle est une application qui s'exécute en user mode, mais qui a pour objectif de fournir un environnement kernel "aussi étendu que possible", bien que limité à certaines ressources ou positions de ressources.

Et, ce qui pose sans doute problème dans ton cas présent, c'est que le noyau n'a pas fait qu'évoluer entre windows 3.1 et windows 8 : il a carrément été entièrement revisité. Cela implique que certains appels systèmes qui étaient disponibles sous windows 3.1 ne le sont plus forcément sous windows 8. Va savoir s'ils ont "simplement" été renommés ou s'ils ont carrément été supprimés, là n'est pas vraiment la question, mais, toujours est-il que ta machine virtuelle reste particulièrement dépendante du noyau de l'hote sur lequel elle est installée, car elle ne fait que transmettre les appels systèmes lancés au niveau de la machine virtuelle au noyau de l'hote (je simplifie très fort, bien sur ;) )

Or, le fait de faire clignoter du texte (au passage, c'est action qui n'a absolument rien de standard, et qui devrait donc être évitée à moins de recourir à une bibliothèque tierce) fait très certainement appel à des appels systèmes qui étaient disponibles sous windows 3.1 mais... qui ne le sont plus sous windows 8.

Je crains donc qu'il n'y ait pas grand chose que l'on puisse faire au niveau de la machine virtuelle, en dehors du fait de prendre note que "non, décidément, le texte ne clignotera pas" :P

D'ailleurs en y pensant, le fait de réinterpréter un des bits de couleur pour dire "clignoter le texte à la place" devait relever d'un handler d'interruption...

Ok, merci pour vos réponses.
Pour Bacelar, l'utilisation de la version de base du programme avec Windows 3.11 et Borland 3.1 s'explique par le choix que j'avais de porter l'ensemble sous VM en quelques heures ou bien de me retaper la compilation de plusieurs milliers de lignes de codes avec les aléas que cela comporte.
Comme je l'ai écris, le programme fonctionne à la perfection depuis plusieurs années sous cette méthode et le seul détail (mais qui s'avère gênant) et ce clignotement qui a disparu.
Pour répondre à Médinoc, j'ai fait le test dont tu parles mais aucune combinaison ne permet de clignoter et le code est bien sur deux fois 4 bits.
Merci Koala01 pour tes explications, je craignais une réponse de ce genre du fait que ça marche sur une machine "de l'époque" et pas sur le VM.
Je vais chercher une autre méthode moins "bios" pour attirer l'attention des opérateurs...
Bruno.

Citation:

---

Envoyé par bruno.bel

Ok, merci pour vos réponses.
Pour Bacelar, l'utilisation de la version de base du programme avec Windows 3.11 et Borland 3.1 s'explique par le choix que j'avais de porter l'ensemble sous VM en quelques heures ou bien de me retaper la compilation de plusieurs milliers de lignes de codes avec les aléas que cela comporte.

---

Ben, la récup, c'est pas forcément mal, mais, à un moment donné, il devient parfois intéressant de... faire évoluer un tout petit peu les choses.

Je ne sais pas ce que fait ton projet, mais, à moins d'avoir encore un (antique) 3x86 à ta disposition, l'utilisation d'une machine virtuelle "juste pour pouvoir continuer à utiliser cette application" me parait déjà bien plus overkill que d'avoir à adapter... quelques milliers de lignes de code.

Si, encore, tu nous avais parlé de quelques centaines (ou milliers) de fichiers composés chacun de plusieurs centaines (milliers) de lignes de code, j'aurais sans doute compris ton souhait d'éviter d'avoir traverser cinq normes pour le mettre "au gout du jour". Mais, pour "quelques milliers de lignes de code", honnêtement, je crois sincèrement que je prendrais quand même le risque.

Et je le crois d'autant plus sincèrement (bien que, comme je l'ai dit, je ne connais absolument rien du projet en question) que j'ai la quasi certitude que le projet en question est très certainement développé selon les "normes de l'époque", et que tu t'es amusé à gérer la mémoire à la main à peu près partout.

Si bien que je serais sans doute près à parier ma chemise sur le fait qu'une "modernisation" du code pourrait :

• réduire le nombre de lignes de près d'un quart (grâce à l'utilisation de classes comme std::string ou std::vector en lieu et place de tes chaines de caractères / tableaux dynamiques gérés à la main)
• t'éviter sans doute quelques "bug silencieux" qui auraient pu survenir sans que tu ne t'en rendes forcément compte
• (pourquoi pas) de rajouter "quelques fonctionnalités" au sujet desquelles tu n'as surement pas manqué -- au fil du temps -- de te dire que "tiens ce serait pas mal si..."

Maintenant, je plaide pour mon point de vue, mais, au final, il ne faut pas oublier un fait essentiel : les conseilleurs ne sont jamais les payeurs. Si bien que la décision finale n'appartient quand même jamais qu'à toi ;)

Selon mes souvenirs du DOS, le clignotement et autres cochonneries qu'on pilotait via des mapping de la mémoire vidéo n'avait rien à faire de l'OS.
On n'y allait comme de bons gros barbares pour dialoguer avec l'hardware vidéo.

Et je plussoie toutes les remarques de @koala01 sur le fait de faire une migration du code.

Plusieurs milliers de lignes, c'est vraiment pas énorme.

Citation:

---

Envoyé par bacelar

Selon mes souvenirs du DOS, le clignotement et autres cochonneries qu'on pilotait via des mapping de la mémoire vidéo n'avait rien à faire de l'OS.
On n'y allait comme de bons gros barbares pour dialoguer avec l'hardware vidéo.

---

En gros, il y avait un registre quelque part qui permettait de choisir entre clignotement et 2×4bits?

Je comprends votre position car vous devez être ou professionnels de l'informatique ou au minimum programmeurs acharnés (et compétents).
Je suis un programmeur occasionnel en fonction des besoins. Je connais plusieurs langages mais jamais assez pour être vraiment efficace, sachant que ce n'est pas mon métier de base.
Je n'ai pas conçu ce programme et comme il répond parfaitement à la tâche qui lui est dévolue, je ne veux pas prendre le risque de le refaire entièrement. Je me limite donc à quelques évolutions simples.
Il fait partie d'un système complexe et le fait d'avoir ce poste opérationnel me permet de me pencher sur ce qui l'est moins...

Citation:

---

En gros, il y avait un registre quelque part qui permettait de choisir entre clignotement et 2×4bits?

---

Dans les spécifications du VGA ( en l'an de grâce 1987, merci Google :aie:), les cartes ont un mode "Texte" qui gère l'écran caractère par caractère et non pixel par pixel.
Pour chaque "cellule" (9 pixels par 8 pixel, je crois), il y a le code asci i du caractère et tous les autres attributs, comme la couleur de fond, la couleur d'écriture, blink ou pas, etc...

Les "bidouilles" de @bruno.bel, c'est de chatouiller directement le buffer du mode Texte de la carte vidéo pour changer les attributs d'une cellule.
Pour la VM, c'est peut-être juste mettre la carte virtuelle dans un mode compatibles avec ces "bidouilles" mais là, faut se palucher un bon ton de spécifications biens poussiéreuses, avec aucune garantie de résultat.

@bruno.bel, tu as tout à fais raison, mais les compétences pour ce type de programme seront de plus en plus rares, les matériels compatibles valent ou vaudront une fortune, si tu arrives à les trouver ailleurs que dans un vide-grenier.

C'est une voix sans issue. Il faut que vous budgétisiez un "IT refresh" avant qu'une carte mère ne lâche.