A voir également:
- Différence entre "format" et "langa
- Telecharger format factory - Télécharger - Conversion & Codecs
- Format epub - Guide
- Différence entre tcp et udp - Guide
- Format apfs - Guide
- Hp format tool - Télécharger - Stockage
14 réponses
des données de sortie (donc texte image et son)
On parle donc bien de ça ??
Format des fichiers de donnée, comme un morceau MP3, une image JPEG, ou un document word ?
Je suppose qu'on parle de ça.
je pensais qu'un format dépendait d'un langage et que si on changeait de langage forcément on avait un autre format !! mais cela n'a pas l'air de se passer comme ca...
Rien à voir.
Un language permet de coder un programme, un format, de structurer des donnée.
A quoi ça sert de "structurer les données" ?
Hé bien il faut voir que fondamentalement, rien ne distingue un fichier d'un autre, quelque soit les données qu'il contient.
Il faut donc créer une sorte de "convention", un standard, qui permet de savoir A QUELLE INFORMATION correspond les bits en cours de lecture.
Celà n'a rien a voir avec le language : tu peux écrire un lecteur dans (quaziment) n'importe quel language.
Pour contre, si tu essaye de chargé un fichier HTML dans ton lecteur MP3, il y a fort à parier qu'il ne retrouve pas ses petits.
Parque les données contenue dans du HTML ne sont pas audio, et leur structure n'a rien à voir.
Par contre, un fichier Ogg Vorbis est également un fichier audio, compréssé, comme le mp3. Mais l'algorithme de compression est différent, et les donnée sont organisées différement.
Un lecteur PUREMENT mp3 ne pourra pas lire un fichier Ogg, car c'est un format différent, mais l'algorithme de lecture des fichiers Ogg pourra, lui, être transcrit dans différents languages.
Tu vois la nuance ?
Je saisi pas bien ce que tu veux dire avc ta dernière phrase...
Mais il est clair que certains formats sont obscurs par volonté de limiter la possibiliter de faire un programme qui peux exploiter ce format.
Tiens, pour fixer les idées, voici une spécification de format de fichier.
Il permet de stocker des images noir et blanc de 256 niveaux de gris.
Pour commencer un fichier dans ce format, on écrit la chaine de caractère :
"JEMDIMFI", (IMage FIle).
Celà permet à un programme, lors de la lecture du fichier, de vérifier que le format est bien celui-là.
Ensuite, deux entier de 4 octets chacun, codant pour la largueur puis la hauteur.
A la lecture, on sait dès le départ à combien de pixel on doit s'attendre de lire (combien de points a l'image).
Chaque pixel est un niveau de gris entre 0 (noir) et 255 (blanc)
Puis tout les pixel, écrit dans l'ordre suivant : on commence en haut à gauche. On écrit les pixel de la première ligne, de gauche à droite. Une fois la ligne terminée, on revient à gauche, ligne suivante, et on recommence jusqu'à la dernière ligne de l'image.
(C'est souveant l'ordre choisi car c'est celui dans lequel le rayon cathodique dessine(nait) l'image.)
Ettant donné qu'on sait combien de pixl on doit lire, on peux déclarer qu'il y a eu une erreur si on en a trop ou pas assez.
On parle donc bien de ça ??
Format des fichiers de donnée, comme un morceau MP3, une image JPEG, ou un document word ?
Je suppose qu'on parle de ça.
je pensais qu'un format dépendait d'un langage et que si on changeait de langage forcément on avait un autre format !! mais cela n'a pas l'air de se passer comme ca...
Rien à voir.
Un language permet de coder un programme, un format, de structurer des donnée.
A quoi ça sert de "structurer les données" ?
Hé bien il faut voir que fondamentalement, rien ne distingue un fichier d'un autre, quelque soit les données qu'il contient.
Il faut donc créer une sorte de "convention", un standard, qui permet de savoir A QUELLE INFORMATION correspond les bits en cours de lecture.
Celà n'a rien a voir avec le language : tu peux écrire un lecteur dans (quaziment) n'importe quel language.
Pour contre, si tu essaye de chargé un fichier HTML dans ton lecteur MP3, il y a fort à parier qu'il ne retrouve pas ses petits.
Parque les données contenue dans du HTML ne sont pas audio, et leur structure n'a rien à voir.
Par contre, un fichier Ogg Vorbis est également un fichier audio, compréssé, comme le mp3. Mais l'algorithme de compression est différent, et les donnée sont organisées différement.
Un lecteur PUREMENT mp3 ne pourra pas lire un fichier Ogg, car c'est un format différent, mais l'algorithme de lecture des fichiers Ogg pourra, lui, être transcrit dans différents languages.
Tu vois la nuance ?
Je saisi pas bien ce que tu veux dire avc ta dernière phrase...
Mais il est clair que certains formats sont obscurs par volonté de limiter la possibiliter de faire un programme qui peux exploiter ce format.
Tiens, pour fixer les idées, voici une spécification de format de fichier.
Il permet de stocker des images noir et blanc de 256 niveaux de gris.
Pour commencer un fichier dans ce format, on écrit la chaine de caractère :
"JEMDIMFI", (IMage FIle).
Celà permet à un programme, lors de la lecture du fichier, de vérifier que le format est bien celui-là.
Ensuite, deux entier de 4 octets chacun, codant pour la largueur puis la hauteur.
A la lecture, on sait dès le départ à combien de pixel on doit s'attendre de lire (combien de points a l'image).
Chaque pixel est un niveau de gris entre 0 (noir) et 255 (blanc)
Puis tout les pixel, écrit dans l'ordre suivant : on commence en haut à gauche. On écrit les pixel de la première ligne, de gauche à droite. Une fois la ligne terminée, on revient à gauche, ligne suivante, et on recommence jusqu'à la dernière ligne de l'image.
(C'est souveant l'ordre choisi car c'est celui dans lequel le rayon cathodique dessine(nait) l'image.)
Ettant donné qu'on sait combien de pixl on doit lire, on peux déclarer qu'il y a eu une erreur si on en a trop ou pas assez.
"Pour commencer un fichier dans ce format, on écrit la chaine de caractère :
"JEMDIMFI", (IMage FIle).
Celà permet à un programme, lors de la lecture du fichier, de vérifier que le format est bien celui-là."
cela veut donc dire qu'il y a un processeur capable de lire et d'éxécuter un format donné et donc un travail d'accord en amont entre les fabricants de puces et le concepteur du format...c'est ca ou qlq chose m'a encore échappé ??
"JEMDIMFI", (IMage FIle).
Celà permet à un programme, lors de la lecture du fichier, de vérifier que le format est bien celui-là."
cela veut donc dire qu'il y a un processeur capable de lire et d'éxécuter un format donné et donc un travail d'accord en amont entre les fabricants de puces et le concepteur du format...c'est ca ou qlq chose m'a encore échappé ??
Luffy =)
Messages postés
365
Date d'inscription
mercredi 20 avril 2005
Statut
Membre
Dernière intervention
19 mai 2006
109
24 avril 2005 à 14:32
24 avril 2005 à 14:32
Non non, pas du tout. Le proceseur ne fait qu'exécuter des instructions à un niveau très très bas. Il ne sait d'ailleurs pas du tout ce qu'est un fichier. C'est le programme en lui-meme qui distingue les différents formats de fichier. Comme l'a dit SKZ, un lecteur MP3 ne pourra lire un fichier html, car en le lisant, il ne trouvera rien ne correspondant à un fichier audio. D'ailleurs si tu t'es déjà intéressé à l'html, tu as remarqué que ces fichiers commencent toujours (ou devraient toujours commencer) par la balise "<html>". ces caractères permettent de dire au navigateur qu'il s'agit bien d'un fichier html et qu'il peut le lire.
Luffy =)
Messages postés
365
Date d'inscription
mercredi 20 avril 2005
Statut
Membre
Dernière intervention
19 mai 2006
109
>
SKZ
24 avril 2005 à 15:51
24 avril 2005 à 15:51
oh je pense que si quand même ;-)
ca y est !! capito !! hourra !!
donc le format du fichier que l'on veut lire est d'abord lu par le programme (lui-même écrit dans un langage donné, C par exemple et qui se réfère à ces dll) qui lui-même est exécuté par le µp directement (si le programme est compilé) qui envoie le résultats sur un périphérique de sortie (par l'intermédiaire du SE ?)
je crois que je brûle là !! oui ,non ??
donc le format du fichier que l'on veut lire est d'abord lu par le programme (lui-même écrit dans un langage donné, C par exemple et qui se réfère à ces dll) qui lui-même est exécuté par le µp directement (si le programme est compilé) qui envoie le résultats sur un périphérique de sortie (par l'intermédiaire du SE ?)
je crois que je brûle là !! oui ,non ??
A priori tu est dans le bon, si tu veux bien dire que :
-lui-même écrit dans un langage donné
>c'est le programme qui est écrit dans ce langage.
-qui se réfère à ces dll
>"ces dll", hum... En l'occurence les DLL sont souvent partagée entre plusieurs programmes... Mais si tu veux écrire un programme qui lit une image au format BMP et que tu dispose d'une DLL qui sait lire le format BMP, il y a de très grande chance pour que ton programme utilise la DLL en question, mais tu peux tout réécrire depuis zéro si tu le souhaite...
- lui-même est exécuté par le µp directement
>"lui-meme" étant le prog, on est OK.
par l'intermédiaire du SE ?
Très probablement. Tu peux réécrire des fonction pour manipuler directement le mode video 320x200 en 256 couleurs pour afficher ton image si tu programme en mode DOS, mais il est souvent plus pratique de passer par le SE qui controle le drivers fournit avec la carte (le driver étant un peu l'adaptateur SE/matériel).
-lui-même écrit dans un langage donné
>c'est le programme qui est écrit dans ce langage.
-qui se réfère à ces dll
>"ces dll", hum... En l'occurence les DLL sont souvent partagée entre plusieurs programmes... Mais si tu veux écrire un programme qui lit une image au format BMP et que tu dispose d'une DLL qui sait lire le format BMP, il y a de très grande chance pour que ton programme utilise la DLL en question, mais tu peux tout réécrire depuis zéro si tu le souhaite...
- lui-même est exécuté par le µp directement
>"lui-meme" étant le prog, on est OK.
par l'intermédiaire du SE ?
Très probablement. Tu peux réécrire des fonction pour manipuler directement le mode video 320x200 en 256 couleurs pour afficher ton image si tu programme en mode DOS, mais il est souvent plus pratique de passer par le SE qui controle le drivers fournit avec la carte (le driver étant un peu l'adaptateur SE/matériel).
jemd1
>
Luffy =)
Messages postés
365
Date d'inscription
mercredi 20 avril 2005
Statut
Membre
Dernière intervention
19 mai 2006
19 mai 2005 à 16:52
19 mai 2005 à 16:52
bonjour,
je voudrais revenir sur le point précédent qui ne me semble toujours pas tout à fait clair...
le format est traduit en langage machine par le compilateur ou bien est-il "décrypté" par le moteur du périphérique de sortie ??
plus j'avance plus il fait sombre
je voudrais revenir sur le point précédent qui ne me semble toujours pas tout à fait clair...
le format est traduit en langage machine par le compilateur ou bien est-il "décrypté" par le moteur du périphérique de sortie ??
plus j'avance plus il fait sombre
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Luffy =)
Messages postés
365
Date d'inscription
mercredi 20 avril 2005
Statut
Membre
Dernière intervention
19 mai 2006
109
1 mai 2005 à 21:43
1 mai 2005 à 21:43
Salut jemd !
ça faisait lgtps qu'on ne t'avait pas vu... la programmation se passe bien ? tu as commencé à coder un peu?
Alors pour ta question, en fait ce n'est pas le format à proprement dit que le programme lit, ce sont les données elles-mêmes contenues dans le fichier qui sont lues.
Après en effet, pour des raisons de "conformité" les données sont écrites dans le fichier suivant des règles bien précises qui est le format.
Mais tu peux lire et écrire dans un fichier texte sans aucune structure, mais c'est le bordel. Prends l'exemple d'un fichier ini sous windows. tu prends n'importe lequel et tu l'ouvres avec le bloc notes. Tu verras qu'il y a des "sections", qui sont entre crochets [section1], puis les clés avec leurs valeurs. ça c'est un format, pour s'y retourver plus facilement et pour accéder plus rapidement aux données. C'est un format très très simple, mais qui répond bien à la notion.
ça faisait lgtps qu'on ne t'avait pas vu... la programmation se passe bien ? tu as commencé à coder un peu?
Alors pour ta question, en fait ce n'est pas le format à proprement dit que le programme lit, ce sont les données elles-mêmes contenues dans le fichier qui sont lues.
Après en effet, pour des raisons de "conformité" les données sont écrites dans le fichier suivant des règles bien précises qui est le format.
Mais tu peux lire et écrire dans un fichier texte sans aucune structure, mais c'est le bordel. Prends l'exemple d'un fichier ini sous windows. tu prends n'importe lequel et tu l'ouvres avec le bloc notes. Tu verras qu'il y a des "sections", qui sont entre crochets [section1], puis les clés avec leurs valeurs. ça c'est un format, pour s'y retourver plus facilement et pour accéder plus rapidement aux données. C'est un format très très simple, mais qui répond bien à la notion.
Salut
la j'ai fait un petit détour par les bases de données et en particulier merise et je me demandais ce qu'on voulait dire lorsqu'on parlait d'applicatif pour une base de données ?? Est-ce que c'est le logiciel de gestion (le sgbdr) ou autre chose genre word ou excell ... c'est à dire un logiciel quelconque mais qui va pouvoir utiliser la base de données ...
Mais c'est un détour , je vais revenir dans pas longtemps à la programmation dont j'ai commencé à voir du coté des algorithmes...
la j'ai fait un petit détour par les bases de données et en particulier merise et je me demandais ce qu'on voulait dire lorsqu'on parlait d'applicatif pour une base de données ?? Est-ce que c'est le logiciel de gestion (le sgbdr) ou autre chose genre word ou excell ... c'est à dire un logiciel quelconque mais qui va pouvoir utiliser la base de données ...
Mais c'est un détour , je vais revenir dans pas longtemps à la programmation dont j'ai commencé à voir du coté des algorithmes...
sam3000
Messages postés
1225
Date d'inscription
mercredi 22 décembre 2004
Statut
Membre
Dernière intervention
13 juin 2005
144
5 mai 2005 à 16:28
5 mai 2005 à 16:28
les fichiers INI et les fichiers BATCH sont des fichiers "généralement" pour le systeme d'exploitation.
INI:
ce sont des fichiers qui donnent des valeurs à des parametres
par exemple dans windosw, un parametre pourrais etre la couleur de l'arriere plan du bureau:
la on definit la couleur du bureau en bleu, windows lit ces fichiers au demarrage (exemple de fichiers qu'utilise windows: 'win.ini' et 'system.ini')
BATCH:
par contre les fichiers batch (extension .BAT ou .CMD) sont utiliser pour executer un programme (appelé aussi 'script') ecrit en texte pur.
le contenu de ces fichiers c'est des commandes de "l'interpereteur ligne de commande" du systeme d'exploitation (exemple sous MS-DOS "COMMAND.COM" et sous Windows 2000/XP "CMD.EXE".
le fichier "autoexec.bat" est un cas particuler de ces fichiers car il est executer automatiquement lors du demarrage des systemes DOS et Windows.
@+
INI:
ce sont des fichiers qui donnent des valeurs à des parametres
[section] parametre=valeur
par exemple dans windosw, un parametre pourrais etre la couleur de l'arriere plan du bureau:
[desktop] backcolor=blue
la on definit la couleur du bureau en bleu, windows lit ces fichiers au demarrage (exemple de fichiers qu'utilise windows: 'win.ini' et 'system.ini')
BATCH:
par contre les fichiers batch (extension .BAT ou .CMD) sont utiliser pour executer un programme (appelé aussi 'script') ecrit en texte pur.
le contenu de ces fichiers c'est des commandes de "l'interpereteur ligne de commande" du systeme d'exploitation (exemple sous MS-DOS "COMMAND.COM" et sous Windows 2000/XP "CMD.EXE".
le fichier "autoexec.bat" est un cas particuler de ces fichiers car il est executer automatiquement lors du demarrage des systemes DOS et Windows.
@+
Deux précision :
Les fichiers INI sont un standard (un format) Windows utilisé par le SE (Windows) mais aussi par d'autres programme (n'importe lequel).
Pendant mon stage, j'ai fait une classe pour lire des fichiers INI, qu'on a intégré dans une appli linux.
Ce n'est pas FORCEMENT spécifique Windows.
Pour les 'Batch', il s'agit de programme en "langage interprété" : ce sont des groupes de commandes systèmes (souvent des appels de programme déjà compilé).
L'interpréteur est un "shell"(aussi appellé "interpréteur de commande" comme le dit sam3000) c'est à dire un programme en mode texte qui permet à l'utilisateur de spécifier des commande pour copier/déplacer/effacer des fichiers, lancer des programmes en spécifiant des options...
Le "shell" windows est appellé "invite de commande" et correspond (encore une fois comme le disait sam) aux fichiers CMD.EXE / COMMAND.COM
Les fichiers INI sont un standard (un format) Windows utilisé par le SE (Windows) mais aussi par d'autres programme (n'importe lequel).
Pendant mon stage, j'ai fait une classe pour lire des fichiers INI, qu'on a intégré dans une appli linux.
Ce n'est pas FORCEMENT spécifique Windows.
Pour les 'Batch', il s'agit de programme en "langage interprété" : ce sont des groupes de commandes systèmes (souvent des appels de programme déjà compilé).
L'interpréteur est un "shell"(aussi appellé "interpréteur de commande" comme le dit sam3000) c'est à dire un programme en mode texte qui permet à l'utilisateur de spécifier des commande pour copier/déplacer/effacer des fichiers, lancer des programmes en spécifiant des options...
Le "shell" windows est appellé "invite de commande" et correspond (encore une fois comme le disait sam) aux fichiers CMD.EXE / COMMAND.COM
d'abord merci pour ta réponse claire.
l autoexe.bat est donc le fichier de démarrage du se ?
et donc les .bat classiques sont les fichiers de l'interpréteur du programme windows? ai-je bien compris ou pas du tout ?
le langage de création de windows est ce bien le C ?
l autoexe.bat est donc le fichier de démarrage du se ?
et donc les .bat classiques sont les fichiers de l'interpréteur du programme windows? ai-je bien compris ou pas du tout ?
le langage de création de windows est ce bien le C ?
l autoexe.bat est donc le fichier de démarrage du se ?
C'était vrai pour MS-DOS (AUTOEXEC.BAT et CONFIG.SYS).
Je ne sais pas pour Win, c'est peut-etre la base de registre.
Par contre, "L'interpréteur de commande" (le mode MS-DOS) doit toujours proposer ces fichiers "d'initialisation" (puisque l'interpréteur de commande n'est plus utilisé au démarage).
Il existe l'équivalent (des fichiers de démarage) sous linux et d'autres systèmes.
Il est souvent plus facile de bidouiller quand c'est du mode texte (logique).
donc les .bat classiques sont les fichiers de l'interpréteur du programme windows? ai-je bien compris ou pas du tout ?
Je pense que oui...
Il s'agit plutot, pour etre exact et precis, de l'interpréteur de commandes du SE Windows.
le langage de création de windows est ce bien le C ?
C'était vrai pour MS-DOS (AUTOEXEC.BAT et CONFIG.SYS).
Je ne sais pas pour Win, c'est peut-etre la base de registre.
Par contre, "L'interpréteur de commande" (le mode MS-DOS) doit toujours proposer ces fichiers "d'initialisation" (puisque l'interpréteur de commande n'est plus utilisé au démarage).
Il existe l'équivalent (des fichiers de démarage) sous linux et d'autres systèmes.
Il est souvent plus facile de bidouiller quand c'est du mode texte (logique).
donc les .bat classiques sont les fichiers de l'interpréteur du programme windows? ai-je bien compris ou pas du tout ?
Je pense que oui...
Il s'agit plutot, pour etre exact et precis, de l'interpréteur de commandes du SE Windows.
le langage de création de windows est ce bien le C ?
Luffy =)
Messages postés
365
Date d'inscription
mercredi 20 avril 2005
Statut
Membre
Dernière intervention
19 mai 2006
109
5 mai 2005 à 21:39
5 mai 2005 à 21:39
et donc les .bat classiques sont les fichiers de l'interpréteur du programme windows?
tu as bien compris ! les batch ne sont que de slignes de commande.
sinon, pour le windows écrit en C, je n'ai pas la réponse, mais ce serait davantage en C++ pour avoir la notion d'objet pour simplifier grandement le travail.
Par contre, Linux a été écrit entre 5 et 10% en assembleur, et le reste en C/C++.
tu as bien compris ! les batch ne sont que de slignes de commande.
sinon, pour le windows écrit en C, je n'ai pas la réponse, mais ce serait davantage en C++ pour avoir la notion d'objet pour simplifier grandement le travail.
Par contre, Linux a été écrit entre 5 et 10% en assembleur, et le reste en C/C++.
Yes, y'a toujours une petite partie en assembleur (pour Windows aussi), par contre 5 à 10 %, surtout pour Linux, me parait très éxagéré (as-tu fouiné un peu dans les sources ?)
De plus, Linux (le noyau pur, je ne parle pas du système complet appellé GNU/Linux) à été écrit 100% en C.
Certaines applis du système (KDE par exemple) sont écrites en C++, mais la Free Software Fondation / Le projet GNU à une forte préférence pour le C.
De plus, Linux (le noyau pur, je ne parle pas du système complet appellé GNU/Linux) à été écrit 100% en C.
Certaines applis du système (KDE par exemple) sont écrites en C++, mais la Free Software Fondation / Le projet GNU à une forte préférence pour le C.
Luffy =)
Messages postés
365
Date d'inscription
mercredi 20 avril 2005
Statut
Membre
Dernière intervention
19 mai 2006
109
6 mai 2005 à 20:45
6 mai 2005 à 20:45
yo =)
as-tu fouiné un peu dans les sources ?
ben même pas en fait. je n'utilise que très peu nunux (malheur à moi lol)
c'est vrai que j'avançais ça sans la moindre source sure... mais de toutes façons, pour qu'un système d'exploitation démarre, il est nécessaire d'avoir quelques lignes en assembleur pour charger les principaux modules en mémoire.
par contre ça me surprend que le noyau de Linux ait été écrit entièrement en C (je ne te contredis pas, au contraire !) mais bon on connait tous les avantages de la P2O pour sa "réutilisabilité".
c'est énorme on en apprend tous les jours avec toi ;-)
as-tu fouiné un peu dans les sources ?
ben même pas en fait. je n'utilise que très peu nunux (malheur à moi lol)
c'est vrai que j'avançais ça sans la moindre source sure... mais de toutes façons, pour qu'un système d'exploitation démarre, il est nécessaire d'avoir quelques lignes en assembleur pour charger les principaux modules en mémoire.
par contre ça me surprend que le noyau de Linux ait été écrit entièrement en C (je ne te contredis pas, au contraire !) mais bon on connait tous les avantages de la P2O pour sa "réutilisabilité".
c'est énorme on en apprend tous les jours avec toi ;-)
[NB : voir aussi post 16 à 20]
Shell = coquille. C'est l'interface AUTOURS du SE, qui permet à l'utilisateur d'interagir, via le SE, avec la machine, de gérer les fichier, de lancer des programmes...
stricto sensus c'est une couche, la couche la plus extérieure de l'architecture de base à 3 couches : le matériel, puis le SE, puis la couche "shell". Tout les programme utilisateurs, tel que paint, word, un jeu, IE, etc... se trouve dans cette couche.
Par abus de langage historique, désigne un programme en mode texte de type interpréteur de commande, comme les commandes MS-DOS, 'bash' sous UNIX/Linux, etc...
Shell = coquille. C'est l'interface AUTOURS du SE, qui permet à l'utilisateur d'interagir, via le SE, avec la machine, de gérer les fichier, de lancer des programmes...
stricto sensus c'est une couche, la couche la plus extérieure de l'architecture de base à 3 couches : le matériel, puis le SE, puis la couche "shell". Tout les programme utilisateurs, tel que paint, word, un jeu, IE, etc... se trouve dans cette couche.
Par abus de langage historique, désigne un programme en mode texte de type interpréteur de commande, comme les commandes MS-DOS, 'bash' sous UNIX/Linux, etc...
sam3000
Messages postés
1225
Date d'inscription
mercredi 22 décembre 2004
Statut
Membre
Dernière intervention
13 juin 2005
144
7 mai 2005 à 10:35
7 mai 2005 à 10:35
ne t'abscente pas trop, comme l'autre fois :)
salut,
Voilà je ne sais pas si c'est plus clair mais on avance...
Le C a été abordé, et j'ai fait un petit détour par Java juste pour voir les différences et il y en a, java semble à priori plus complexe mais également incontournable et intéréssant dans ma recherche de la compréhension de l'ordi et de ces différentes applications, je commence à saisir que la différence entre programme et processeur est de plus en plus ténue...
Mais bon, c'est du boulot tout ca faut pas croire...
j'vous tiens au courant...
Voilà je ne sais pas si c'est plus clair mais on avance...
Le C a été abordé, et j'ai fait un petit détour par Java juste pour voir les différences et il y en a, java semble à priori plus complexe mais également incontournable et intéréssant dans ma recherche de la compréhension de l'ordi et de ces différentes applications, je commence à saisir que la différence entre programme et processeur est de plus en plus ténue...
Mais bon, c'est du boulot tout ca faut pas croire...
j'vous tiens au courant...
Luffy =)
Messages postés
365
Date d'inscription
mercredi 20 avril 2005
Statut
Membre
Dernière intervention
19 mai 2006
109
19 mai 2005 à 23:24
19 mai 2005 à 23:24
java semble à priori plus complexe
arf ! même po vrai d'abord ! mdr =)
bon désolé, moi le gd défenseur (et pourtant grand ignorant encore) du C/C++, le java n'est pas plus complexe !
par rapport au C, je suis d'accord, car le java est un langage objet. c'est pour cela que le C++ vient en renfort ! pour moi, le java est une bonne solution car il est utilisable qq soit l'OS, car c'est de l'interpreté. mais le revers de la médaille, c'est que c'est plus lent. pour des appli n'ayant pas forcément besoin de rapidité, pas de problème, et même encore mieux ! mais dès que tu recherches la "performance", rien de mieux que le C++, ou encore plus poussé l'assembleur. mais l'assembleur est vraiment très dur à gérer dans les grosses applications (trop trop de lignes à coder !).
mais le principe et la syntaxe restent sensiblement la même entre java et C++. en fait la base de la programmation, c'est que l'on fait appel a des choses déjà existantes, ce qu'on appelle des API (application program interface) que les programmeurs de l'OS laisse à disposition des développeurs quelconques pour exécuter leur programme. Depuis le windows NT, il y a ce qu'on appelle les API Win32, qui sont des fonctions propres à Windows pour faire ce que l'on veut (accéder au registre, au matériel (quoiqu'ils ont laissé un accès plus restreints), créer des fenêtres, etc...).
bon je m'arrête là, je sors d'un repas qq peu arrosé, donc je ne voudrais pas dire de conneries, et surtout ne pas vexé les acharnés du java (hein kij ;-) ).
et que vive le C++ =)
arf ! même po vrai d'abord ! mdr =)
bon désolé, moi le gd défenseur (et pourtant grand ignorant encore) du C/C++, le java n'est pas plus complexe !
par rapport au C, je suis d'accord, car le java est un langage objet. c'est pour cela que le C++ vient en renfort ! pour moi, le java est une bonne solution car il est utilisable qq soit l'OS, car c'est de l'interpreté. mais le revers de la médaille, c'est que c'est plus lent. pour des appli n'ayant pas forcément besoin de rapidité, pas de problème, et même encore mieux ! mais dès que tu recherches la "performance", rien de mieux que le C++, ou encore plus poussé l'assembleur. mais l'assembleur est vraiment très dur à gérer dans les grosses applications (trop trop de lignes à coder !).
mais le principe et la syntaxe restent sensiblement la même entre java et C++. en fait la base de la programmation, c'est que l'on fait appel a des choses déjà existantes, ce qu'on appelle des API (application program interface) que les programmeurs de l'OS laisse à disposition des développeurs quelconques pour exécuter leur programme. Depuis le windows NT, il y a ce qu'on appelle les API Win32, qui sont des fonctions propres à Windows pour faire ce que l'on veut (accéder au registre, au matériel (quoiqu'ils ont laissé un accès plus restreints), créer des fenêtres, etc...).
bon je m'arrête là, je sors d'un repas qq peu arrosé, donc je ne voudrais pas dire de conneries, et surtout ne pas vexé les acharnés du java (hein kij ;-) ).
et que vive le C++ =)
eh oui c'est bien ce qui me semblait, les API seront la prochaine étape car faut dire qu'actuellement j'ignore complètement ou presque ce que c'est que ce terme qui revient sans cesse?? Ca a l'air super important et le dévellopement de l'acronyme me laisse pantois...mazette mais a quoi cela sert -il ??
genre une dll (je connais le terme, a peu prés les fonctions (et encore)mais j'ignore totalement comment ce truc peut fonctionner cad comment un programme peut-il récupérer quelque chose et d' autant plus, comment ce quelque chose (des données je suppose) peut-il servir au programme ??(je parlais des dll là)
l'api serait donc une sorte de dll qui permettrait au programme de s'implémenter (j'suis pas sur du terme mais il fait pro :-) ) dans le SE (aie j'ai l'impression de dire une connerie...) et permettre donc à ce programme de j'sais pas trop quoi d'ailleurs d'être lancer à partir de l'interface du se.
une hypothèse : les dll sont des fichiers de données et les api des fichiers d'instruction. mouais peut-être après tout mais comment avec tout les langages existants le SE pourrait-il conserver des instructions utiles pour chacun???
help me if you can ...
genre une dll (je connais le terme, a peu prés les fonctions (et encore)mais j'ignore totalement comment ce truc peut fonctionner cad comment un programme peut-il récupérer quelque chose et d' autant plus, comment ce quelque chose (des données je suppose) peut-il servir au programme ??(je parlais des dll là)
l'api serait donc une sorte de dll qui permettrait au programme de s'implémenter (j'suis pas sur du terme mais il fait pro :-) ) dans le SE (aie j'ai l'impression de dire une connerie...) et permettre donc à ce programme de j'sais pas trop quoi d'ailleurs d'être lancer à partir de l'interface du se.
une hypothèse : les dll sont des fichiers de données et les api des fichiers d'instruction. mouais peut-être après tout mais comment avec tout les langages existants le SE pourrait-il conserver des instructions utiles pour chacun???
help me if you can ...
Les APIs (Application Programming Interface) ne sont tout simplement que des bibliothèque de fonctions.
Elles permettent de disposer d'un ensemble de fonctionnilité +ou- standard, parfois spécifique à un OS voire à un matériel particulier (une API USB par exemple, je sais pas si ça existe _tel quel_ ou si c'est intégré à une API plus grosse), serait une collection de fonction qui permettent de gere, d'échanger des information avec un périférique USB quelconque... Si t'as pas d'USB, c'est bien évidemment inefficace !!
Pour prendre un exemple simple, "printf()" est une fonction qui fait partie de l'API C standard (aussi appellé bibliothèque standard ou "SL" (standard library))
Pour les DLL, tout faux, il ne s'agit JUSTEMENT pas de donnée.
C'est (en émorme majorité) des fonctions.
Comment ça marche ?
Il doit exister une DLL qui contient l'implémentation (le developpement) de la fonction printf().
Elle est unique sur le système, tout les programmes utilisent la même (sauf exception, on peut forcer un programme à intégrer en lui même toutes les fonctions utilisées : il devient autonome (plus besoin de la DLL).
Suffit de voir la DLL comme un bout du programme principal, partagé entre plusieurs programme.
Un autre avantage, c'est qu'on peut la changer (il faut que les fonctionnalités proposées restent identiques, néanmoins).
Exemple : une DLL permet de gérer une carte graphique partivulière.
Tu écrit un petit jeu, tu utilise des fonctions graphiques qui permettent, par exemple, d'afficher un point, tracer une ligne, etc...
Lors de l'éxécution, la DLL se charge de convertir ces appels "haut niveau" en instructions élémentaire de manipulation de la carte graphique, ce qui permet d'aboutir au résultat souhaité.
Si tu change de carte, les manipulations effectuée "bas niveau" par la DLL risque de ne pas aboutir au résultat souhaité.
Il suffit de remplacer la DLL par celle adaptée et tout remarche très bien (sans aucune modif du prog principal).
La partie invariante, le "contrat" qui lie le programme principal (appellé "application") et la DLL, ce qui définie les fonctions proposées et la manière de les utilisée, les conséquences, etc... c'est très exactement CA, l'API.
Question vocabulaire "implémenter" est un anglicisme (parfois traduit par "implanter") qui décrit une action HUMAINE. C'est une étape de la réalisation (méthodique) d'un programme.
En effet, pour effectuer tel ou tel traitement, tu défini qu'il te faut tant de fonctions, tu défini leurs noms, rôles, les arguments que tu va passer etc...
C'est la déclaration de la fonction (à la différence que la déclaration, le fait d'écrire le "prototype" (la ligne qu'en C, tu réécrit avant d'ouvrir l'accolade pour écrire le corps de la fonction).
Cette fonction complète, par opposition à la déclaration (qui fait office "d'interface"), s'appelle "l'implémentation" de la fonction.
Le fait de l'écrire s'appelle implémenter.
Pour revinir sur les API/DLL, on peut voir l'API comme la déclaration, et la DLL comme l'implémentation (c'est pas tt à fait exact, mais le concept est là).
A noter, les DLL sont (quasiment) indépendante du language (rapelle toi que tout est traduit en assembleur à la compilation).
Voili violon !!!
Elles permettent de disposer d'un ensemble de fonctionnilité +ou- standard, parfois spécifique à un OS voire à un matériel particulier (une API USB par exemple, je sais pas si ça existe _tel quel_ ou si c'est intégré à une API plus grosse), serait une collection de fonction qui permettent de gere, d'échanger des information avec un périférique USB quelconque... Si t'as pas d'USB, c'est bien évidemment inefficace !!
Pour prendre un exemple simple, "printf()" est une fonction qui fait partie de l'API C standard (aussi appellé bibliothèque standard ou "SL" (standard library))
Pour les DLL, tout faux, il ne s'agit JUSTEMENT pas de donnée.
C'est (en émorme majorité) des fonctions.
Comment ça marche ?
Il doit exister une DLL qui contient l'implémentation (le developpement) de la fonction printf().
Elle est unique sur le système, tout les programmes utilisent la même (sauf exception, on peut forcer un programme à intégrer en lui même toutes les fonctions utilisées : il devient autonome (plus besoin de la DLL).
Suffit de voir la DLL comme un bout du programme principal, partagé entre plusieurs programme.
Un autre avantage, c'est qu'on peut la changer (il faut que les fonctionnalités proposées restent identiques, néanmoins).
Exemple : une DLL permet de gérer une carte graphique partivulière.
Tu écrit un petit jeu, tu utilise des fonctions graphiques qui permettent, par exemple, d'afficher un point, tracer une ligne, etc...
Lors de l'éxécution, la DLL se charge de convertir ces appels "haut niveau" en instructions élémentaire de manipulation de la carte graphique, ce qui permet d'aboutir au résultat souhaité.
Si tu change de carte, les manipulations effectuée "bas niveau" par la DLL risque de ne pas aboutir au résultat souhaité.
Il suffit de remplacer la DLL par celle adaptée et tout remarche très bien (sans aucune modif du prog principal).
La partie invariante, le "contrat" qui lie le programme principal (appellé "application") et la DLL, ce qui définie les fonctions proposées et la manière de les utilisée, les conséquences, etc... c'est très exactement CA, l'API.
Question vocabulaire "implémenter" est un anglicisme (parfois traduit par "implanter") qui décrit une action HUMAINE. C'est une étape de la réalisation (méthodique) d'un programme.
En effet, pour effectuer tel ou tel traitement, tu défini qu'il te faut tant de fonctions, tu défini leurs noms, rôles, les arguments que tu va passer etc...
C'est la déclaration de la fonction (à la différence que la déclaration, le fait d'écrire le "prototype" (la ligne qu'en C, tu réécrit avant d'ouvrir l'accolade pour écrire le corps de la fonction).
Cette fonction complète, par opposition à la déclaration (qui fait office "d'interface"), s'appelle "l'implémentation" de la fonction.
Le fait de l'écrire s'appelle implémenter.
Pour revinir sur les API/DLL, on peut voir l'API comme la déclaration, et la DLL comme l'implémentation (c'est pas tt à fait exact, mais le concept est là).
A noter, les DLL sont (quasiment) indépendante du language (rapelle toi que tout est traduit en assembleur à la compilation).
Voili violon !!!
