Acces direct mémoire - C++ - Programmation
Marsh Posté le 21-11-2002 à 17:19:03
Sous quel OS tu veux le faire ?
Je sais que sous Windoz par exemple, tu ne peux accéder directement à la mémoire que dans un driver
Marsh Posté le 21-11-2002 à 17:55:55
non ?!? Bleuarff au cpp ?!?
dsl g pas de reponse à ta question
Marsh Posté le 21-11-2002 à 18:00:35
tlam a écrit a écrit : Sous quel OS tu veux le faire ? Je sais que sous Windoz par exemple, tu ne peux accéder directement à la mémoire que dans un driver |
Bah non, quand tu fais des malloc, t'accède bien directement à la mémoire !
Marsh Posté le 21-11-2002 à 18:02:49
El_Gringo a écrit a écrit : Bah non, quand tu fais des malloc, t'accède bien directement à la mémoire ! |
Tu crois ca toi...
Marsh Posté le 21-11-2002 à 18:03:57
BENB a écrit a écrit : Tu crois ca toi... |
Ben accès direct à certaines zones mémoire réservées, en tout cas, non ?
Marsh Posté le 21-11-2002 à 18:08:18
je suis sous windows.
un malloc permet de voir l'etat de la memoire (dsl, newbie inside) ?
Ce que je veux en fait, c récuperer les octets de la memoire video afin de pouvoir recuperer ce qui est ecrit. En gros je veux me servir de la memoire video comme un tableau en lecture.
Marsh Posté le 21-11-2002 à 20:48:34
Acceder à la memoire sous windows comme tu le ferais sous Dos c pas possible parceque windows tourne en mode protéger donc le mode d'acces de type segment:offset n'a rien à voire avec le dos
Quoiqu'il en soit si tu veut acceder à la mémoire video sous windows comme tu le faisait sous dos. Bah t'utillise l'emulation du mode 13h ou du mode X sous DirectX. L'autre moyen c de passer par des fonction tiers programmer en Assembleur (pas le inline hein! un vraix assembleur
fait des fonction ASM qui ont cette gueulle:
Code :
|
Marsh Posté le 21-11-2002 à 21:36:16
El_Gringo a écrit a écrit : Bah non, quand tu fais des malloc, t'accède bien directement à la mémoire ! |
Tu accèdes à la mémoire de ton processus uniquement.
Chaque processus à son propre adressage, qui ne correspond pas à l'emplacement physique dans la RAM.
En effet, la zone mémoire pointée par le résultat du malloc peut être enlevée de la mémoire pour être mise dans le swap, restaurée mais pas forcément au même endroit.
Pour ton programme, c'est toujours la même adresse, mais son emplacement dans la RAM peut varier.
Marsh Posté le 21-11-2002 à 22:10:31
sombresonge> merci bien, mais c pour des projets en école d'info, pas le droit d'utiliser autre chose que du c dans un projet de c. Mais merci, ça va surement me servir ailleurs.
Marsh Posté le 22-11-2002 à 10:06:42
El_Gringo a écrit a écrit : Ben accès direct à certaines zones mémoire réservées, en tout cas, non ? |
Ben le malloc est un appel systeme, donc a priori tu n'accede pas directement à la memoire. Ensuite l'adresse que tu obtiens est virtuelle, tu ne sais pas ou elle se trouve reelement dans la RAM, car quand le systeme gere sa memoire il peut deplacer les processus (pour les mettre dans le swap par exemple, mais pas uniquement) tu es donc loin d'acceder directement à la memoire...
Marsh Posté le 24-11-2002 à 02:50:57
S'il n'y a pas d'OS protecteur, on peut faire ça:
Code :
|
Mais l'accès direct au matériel est une chose dangereuse.
Marsh Posté le 24-11-2002 à 04:17:39
Citation : Est-ce qu'en c (pas c++) il existe qqchose ressemblant au tableau prédefini Mem en pascal ? A savoir, un tableau qui permet d'acceder directement à la mémoire, pour entre autre modifier directement l'affichage à travers la mémoire vidéo ? |
Ta question n'a de sens que sous DOS (mode réel) car :
- en mode protege, comme on te l'a dit, tu n'a pas acces a la memoire physique mais a la mémoire virtuelle. Il existe néanmoins des dll qui permettent d'ecrire a un endroit particulier en memoire physique (voir winio ici : http://www.internals.com)
- tu ne sais tout simplement pas où se trouve la mémoire video. Celle-ci est gérée par le driver et son adresse est spécifique à chaque carte graphique.
Attention à ne pas confondre un programme DOS 16 bits exécuté depuis Windows et un programme Windows 32 bits.
Le premier travaille en mode réel et va appeler les routines du BIOS VGA pour sélectionner un mode graphique et va directement manipuler la mémoire video.
Le second va faire appel a une librairie genre DirectX pour activer un mode et obtenir un pointeur sur un buffer video qu'il va directement manipuler comme un tableau.
Il y a fort a parier que tu sois dans le premier cas, auquel cas on déclare généralement un pointeur vers la mémoire vidéo de cette manière :
Code :
|
Marsh Posté le 25-11-2002 à 11:16:04
merci bien de cette explication
vu que je fait des app console win32 c pas possible...Sauf à passer par l'asm si j'ai bien compris ? Si il est possible de compiler un prog asm en .lib afin de l'integrer au projet.
Menfin je connais rien à l'asm, alors je vois pas comment je pourrait coder un truc comme ça..Pour info en pascal je fais ça:
Code :
|
Marsh Posté le 25-11-2002 à 11:51:54
Passer par l'asm ne changera rien.
Utilise la dll dont j'ai donné le lien.
Mais meme avec CA NE MARCHERA PAS, parce que en mode protege, a l'adresse B0000, il n'y a RIEN.
Tout ce que tu vas arriver a faire c'est planter le systeme en ecrivant n'importe ou.
B0000 n'est pas l'adresse video sous Windows.
2 solution :
- tu continue avec ton B0000 et dans ce cas tu créé un programme DOS 16 bits avc un compilateur DOS 16 bits genre bc++
- tu utilises DirectX, tu passes en mode Text, et tu ecris comme tu veux dans le buffer que DirectX te donne
Marsh Posté le 25-11-2002 à 12:03:27
Bleuarff a écrit a écrit : vu que je fait des app console win32 c pas possible...Sauf à passer par l'asm si j'ai bien compris ? |
note qu'en Pascal ça ne serait pas possible non plus si tu fais un prog win32 je pense...
Marsh Posté le 25-11-2002 à 12:09:37
Oui d'aileur c'est vrai ca, ton code PASCAL là c'est du code 16 bits.
Marsh Posté le 25-11-2002 à 12:11:17
D'ailleurs sous Delphi (du Pascal mais sous Windows) "Mem" n'existe pas...
Marsh Posté le 25-11-2002 à 12:12:35
merci bien, j'abandonne donc. (directx c pour du c++, ça marche dans un .c ?)
Marsh Posté le 25-11-2002 à 12:13:09
antp a écrit a écrit : D'ailleurs sous Delphi (du Pascal mais sous Windows) "Mem" n'existe pas... |
Juste pour info : Delphi, c un langage ou en environnement de programmation du coup ?
Marsh Posté le 25-11-2002 à 12:13:19
Bleuarff a écrit a écrit : merci bien, j'abandonne donc. (directx c pour du c++, ça marche dans un .c ?) |
à priori DirectX c'est pour ce que tu veux (ça marche aussi en Delphi )
Marsh Posté le 25-11-2002 à 12:16:54
El_Gringo a écrit a écrit : Juste pour info : Delphi, c un langage ou en environnement de programmation du coup ? |
c'est assez délicat
Delphi = EDI+RAD utilisant une version un peu modifiée du Pascal comme langage.
Donc c'est du Pascal Objet, mais j'ai lu je sais plus où que Borland aimerait bien appeler le langage "Delphi".
J'imagine que c'est pour pouvoir continuer à le faire évoluer plus librement...
Marsh Posté le 25-11-2002 à 12:18:34
...Et kylix (ss linux), c encore un autre "langage" ?
Finalement, c'est carrément fermé comme techno. Un seul environnement pour un langage. ça me rappel un certain "Visual Basic"
Marsh Posté le 25-11-2002 à 12:21:37
Kylix = Delphi + C++Builder sous Linux
Bah oui le langage est moins répandu, mais je vois pas en quoi ça rend la technologie "fermée"
un soft fait avec VC++ et les MFC est pas nécessairement plus ouvert, à part que le MSC++ utilisé ressemble fort à du C++
Mais y a quand même au moins un compilo libre qui supporte le langage de Delphi :
http://www.freepascal.org/
Marsh Posté le 25-11-2002 à 12:25:05
Y'aurait peut etre une autre solution.
Tu te créé ton buffer à toi, tu écris comme tu veux dedans, et a chaque fois que tu le modifies, tu fais un SetConsoleCursorPosition au debut et un WriteConsole de ton buffer.
Cela dit c'est crados, car si tu modifies juste 1 caractere, tu copies quand meme tout (a moins que tu commences a optimiser, mais dans ce cas autant faire des WriteConsole sans passer par un buffer, ou encore plus simple des writeln ...)
Donc niveau proprete et performance c'est pas top, mais si tu debutes ce ser aplus simple que DirectX.
Tu te créé une fonction d'init qui créé et te renvoit le buffer, et une fonction genre Refresh que tu appeles apres chaque ecriture dans ton buffer.
Mais bon, autant pas se prendre la tete et rester en 16 bits.
Marsh Posté le 25-11-2002 à 12:26:14
antp a écrit a écrit : Kylix = Delphi + C++Builder sous Linux Bah oui le langage est moins répandu, mais je vois pas en quoi ça rend la technologie "fermée" un soft fait avec VC++ et les MFC est pas nécessairement plus ouvert, à part que le MSC++ utilisé ressemble fort à du C++ Mais y a quand même au moins un compilo libre qui supporte le langage de Delphi : http://www.freepascal.org/ |
ha, ok. En fait kylix, c'est Borland aussi !?
Pour VC++, t de mauvaise fois. Si on veut faire du C/C++ standard avec, c'est possible. Après, 'faut avouer que c tentant d'utiliser les librairies fournies par MS...
Et dernier point... Un compilo libre... c déja ça !
Marsh Posté le 25-11-2002 à 12:27:54
El_Gringo a écrit a écrit : ha, ok. En fait kylix, c'est Borland aussi !? |
ouaip, enfin là on part hors-sujet
El_Gringo a écrit a écrit : Pour VC++, t de mauvaise fois. Si on veut faire du C/C++ standard avec, c'est possible. Après, 'faut avouer que c tentant d'utiliser les librairies fournies par MS... |
J'ai pas dit le contraire, je voulais dire que si on utilise toutes les possibilités de VC++ ça n'a plus tellement à voir avec le standard, ne fût-ce que pour les librairies utilisées
C'est un peu pareil avec Delphi.
Marsh Posté le 25-11-2002 à 12:30:02
antp a écrit a écrit : ouaip, enfin là on part hors-sujet J'ai pas dit le contraire, je voulais dire que si on utilise toutes les possibilités de VC++ ça n'a plus tellement à voir avec le standard, ne fût-ce que pour les librairies utilisées C'est un peu pareil avec Delphi. |
Ok, bon, sur ce, arrêtons cet hors sujet. Désolé pour mon intrusion ds ce topic, et merci ...
Marsh Posté le 25-11-2002 à 12:57:11
el_gringo> ya pas de mal
helloworld> rester en 16 bit je peux pas: c pour un projet à l'ecole, où il faut utiliser obligatoirement VC++/win32 console app mais merci du tuyau
Marsh Posté le 25-11-2002 à 19:54:10
ben alors la lib standard.
printf est là pour ca !
Marsh Posté le 26-11-2002 à 23:53:21
HelloWorld a écrit a écrit : ben alors la lib standard. printf est là pour ca ! |
tu a lu le topic ? c pas ecrire qui m'interesse mais lire
Marsh Posté le 27-11-2002 à 01:33:56
malloc sert a allouer la memoire, mais suivant les os, le systeme ne verifie meme pas tjs que la memoire alloué (reservé) existe physikmeent sur la machine. et elle renvoi un adressage non absolu pour permettre au prog d'y acceder
Marsh Posté le 21-11-2002 à 15:46:26
Est-ce qu'en c (pas c++) il existe qqchose ressemblant au tableau prédefini Mem en pascal ? A savoir, un tableau qui permet d'acceder directement à la mémoire, pour entre autre modifier directement l'affichage à travers la mémoire vidéo ?
---------------
©2008 Bleuarff Corp.