Salut à tous, ma question va peut-être vous paraître idiote, mais je me lance :
 
J'utilise dev-c++ (version 4.9.9.0) sous windows, et j'essaie en vain de compiler une fonction, voici l'erreur de compilation qu'il me trouve :     [Linker error] undefined reference to `WinMain@16'  
 
J'ai essayé de changer des choses dans les paramètres mais ça n'y change rien.
 
Pour info, voici mon programme de façon très simplifiée :
#include <stdio.h>
#include "ex3a.h"
void tableaux ( int t1[], int t2[], int tRes[] )
{
/* programme */
}
 
et mon fichier ex3a.h contient :
void tableaux ( int t1[], int t2[], int tRes[] );
 
 
Mais sous xemacs sous linux j'avais réussi à le compiler, alors le problème doit être avec dev-c++.
 
Merci si vous pouvez m'aider...  

faut faire un projet, avec un main
 
ou alors tu compile en ligne de commande "gcc -c ..."

Parce que tu as créé un projet Win32 et pas un projet console. Crée un projet console sinon il recherche WinMain() à la place de main().

Merci beaucoup, j'ai créé un projet et c'est passé tout seul    
 
Ah, j'aime quand ça se résout simplement  

ca se serait passé tellement plus simplement sous Linux  

Les trolls c'est demain

C'est que le vendredi ? On a pas le droit le jeudi ?

 
C'est typiquement le genre de post des pro-linux qui me hérisse le poil.
Vous ne connaissez ni les tenants ni les aboutissants du travail de ce type et vous debarquer avec vor Nulix comme un elephant dans un magagsin de quilles de bowling

 
Tu préfererais que ce soit une pointure comme Daniel Veillard qui te donne le conseil http://mail.gnome.org/archives/xml [...] 00019.html
 

Ben lui c'est pareil, il peut se carer sa suffisance de Nulixien dans ses fesses

Tu seras privé de libxml2 pour la peine !

trop dur =]

Qui ça ?
 
De toutes façons si on veut un avis sur le développement sous Windows, faut être un peu con pour demander celui d'un extrêmiste Linuxien. Par définition le linuxien déteste Microsoft et ses produits, donc il ne les utilise pas, donc il ne les connait pas et donc il ne sait rien d'autre à leur sujet que les conneries que les autres linuxien qui n'y connaissent rien eux non plus colportent sur des sites/newsgroups spécialisés en masturbation collective entre manchots (si si c'est possible).
La caractéristique la plus forte du Linuxien est sa capacité à re-écrire l'histoire. Avant Linux c'était le cahos, il n'y a avait rien. Puis Linus Torvalds est arrivé et a tout inventé seul, juste avant que le vilain Microsoft paye 60000 développeurs pour tout copier. Rappelons pour la petite histoire que Linux est un clone d'UNIX, et ma définition du clone c'est "copie conforme". Donc pouet pouet camembert.
Voilà une bonne introduction pour commencer ce vendredi.

Merci pour ces lumières, justement j'en parlais avec Dédé, un pote à moi du 421 (au PMU de Suresnes) et figurez vous qu'il m'a -quasi mot pour mot- tenu le même discours !

Attention tu tues le troll là.

Mais les Linuxiens, ils ne sont rien, non ?  
 
- un quart du code est pompé de BSD.
- un quart vient du projet GNU
- un quart a été écrit spécialement pour Linux, et bugge lamentablement
- et un quart a été écrit par IBM/Sun/Caldera, etc.
 
Et surtout, tous les concepts sont pompés des autres OS majeurs (ou mineurs, comme NextStep, BeOS, etc.)  
 
La seule innoviation, ça a été l'idée brillante d'afficher les Bobomips au boot, j'avais jamais vu ça ailleurs en fait.

 
 
le linuxien ou le gnutien ? il me semblais que c'etais un peu la guerre entre torvald (qui minore leur travail en reffusant par exemple l'appelation GNU/Linux), et les autres du projets GNU, dont le seul vrai systeme d'exlpoitation est GNU/hurd  
 
et linux c'est libre, ca fais quand meme une difference ?
 

Je ne tue pas le troll, j'essaie simplement de faire comprendre qu'il faut ouvrir les yeux et qu'il y a des _alternatives_ au shemà C++/Java/VS/Windows.
Ce n'est pas parce que par passion on recherche la solution la meilleure qu'on est forcemment un péteux. Or la solution la meilleure date d'il y a 30 ans au cours desquels elle est  restée la plus portable, la plus stable, la plus performante et la plus KISS, j'ai nommé Unix et le C.
J'en veux pour preuve qu'aujourd'hui tout les langages de programmation qui comptent sont des tentatives (malheureuses la plupart du temps) de moderniser le C pour plaire à des dissaidors (C++, Java, C#), et qu'un langage véritablement innovant comme Eiffel n'est en fait qu'un générateur de code C. Le seul langage à tirer véritablement son épingle du jeu dans ce shèmà doit etre Python.
Pour preuve aussi qu'il y a une quantité incroyable du code des systèmes d'exploitation qui est d'origine BSD (Linux plus de 50%, Windows à par pour la partie réseau on en sait rien car le super OS neuneuproof de bureautique est totalement fermé... J'imagine que c'est la partie BSD qui le fait tenir plus de 2 heures sans se vautrer...)
 

Daniel Veillard est l'auteur d'une librairie (libxml) qui poutre toute ses alternatives. Cette librairie est codée (comme par hasard) en C. Il est aussi membre de Redhat et du W3C, bref c'est loin d'etre une tanche.
C'est bizarre que cette librairie semble inconnue sur ce forum, en meme temps quand on voit l'engouement que suscitent les bloatwares destinés à produire des bloatwares   ( C++/Java/VS/Windows ) on comprend mieux

Pas mal le Troll là. Manquerais plus qu'un peu de commentaires sur les licenses et EULA Windows, sur la fortune de Billou, et sur les pratiques monopolistiques, et on a tout.
 
Bon, moi je vais me commander un billet de train sur un site en Java avec mon browser codé en C++, et ensuite je vais jouer à HL2, un jeu codé sous Windows en DirectX avec Visual C++ (et Incredibuild ).

Oui malheureusement j'y suis aller un peu fort et personne ne marche dedans
Merci quand meme à tous et particulièrement à HelloWorld pour son coup de main

N'empeche que le problème n'est pas là
Quand ces bouseux de nulixien travailleront dans des vrais entreprises qui font du dev Windows sous windows pour gagner leur croute ils s'ecraseront

Mouais m'enfin on n'est pas obligé de prendre la façon vraiment très intéressante de travailler que nous impose la COGIP pour l'ultime référence non plus

Rien du tout. On parlait de devcpp qui est une alternative à VS. Ensuite "faire comprendre qu'il faut ouvrir les yeux", tu parles, ta réponse est du pur jus troll "Linux c'est mieux que Windows". Au passage devcpp c'est libre, GPL, c'est pas fait par MS, ça utilise MingW => g++, LE GNU g++, le même que sous Linux, donc savoir si ça se passerait mieux sous Linux c'est vite dit. Si on suit ta logique on serait même tenté de dire "passe à VS car les outils GNU ça pue".
Le mec il veut faire du C++ sous Windows, tu lui répond va faire du C sous Linux. Quand on voit la complexité du problème qu'il a fallu résoudre, tu parles d'une simplification.
 

Blablabla. Y'a pas de meilleure solution, c'est comme la meilleure voiture, ça existe pas. C'est au cas par cas : situation donnée et utilisateur donné. En l'occurence, la meilleure solution pour faire du C++ sous Windows, c'est certainement pas de faire du C sous UNIX. Vouloir utiliser son super truc à tout prix peut être une erreur, même si c'est vraiment un super truc.
Après dire que faire du C c'est plus stable et performant, c'est un autre troll. Pour ma part je pense que le C est le langage le plus rapide pour faire planter son logiciel. Mais faut en garder un peu pour vendredi prochain.
 

Tu parles d'une preuve. Moderniser, ah oui, c'est une façon de voir. Je vois pas trop l'héritage du C dans Java. Et après si Java ou Eiffel ou un autre pisse du code C derrière on s'en fout, c'est un détail d'implémentation. Au départ C++ pissait lui aussi du code C. Ca permet de réutiliser les compilos optimiseurs existants et de pas réinventer la roue. Si on va par là l'assembleur est la seule voie, j'en veux pour preuve que les compilateurs C ne sont que des générateurs de code assembleur.
 

Tu vois quand je te dit que les linuxiens n'y connaissent rien à Windows et se masturbent entre eux à coup de grosses conneries. D'abord Windows n'est pas totalement fermé. Certaines entreprises / gouvernements y ont eu un droit d'accès depuis un certains temps déjà, et maintenant le programme MVP Source Licensing Program permet aux MVP d'y avoir accès. Et puis comme dirait un pote "ouha t'as accès au code source de Linux. Super! T'en fais quoi ?" Le résultat c'est que Windows on sait où on en est. Linux, le dernier recencement que j'ai lu y'avait pas loin de 300 distributions différentes. Et je parle pas de LFS. Sans déconner, c'est le gros fouttoir, surtout quand tu veux utiliser 2 libs qui nécessitent chacune 2 versions différentes d'une autre lib incompatibles entre elles. Et les querelles de clochers avec 36 branches dans le développement d'un même soft (genre X11). Super l'Open Source où tout le monde modifie ce qu'il veut comme il veut ! Le délire de Linux c'est de faire croire que n'importe qui peut faire son OS. Ben non, un OS c'est un boulot de professionnels. MS sera sûrement appelé un jour à rendre le code source de Windows accessible, mais j'espère bien qu'ils n'autoriseront pas sa modification. MS tient les rennes, on sait où on va, où on en est.  
 
Ensuite l'histoire de la pile IP BSD c'est beaucoup de battage pour pas grand chose aussi. Son utilisation a été temporaire.
http://www.kuro5hin.org/?op=displa [...] 05641/7357
 
Pour info 80% des plantages de Xp sont dus à des drivers tiers, non écris par MS mais par ton vendeur de modem USB à prix cassé par exemple. Aux dernières nouvelles le noyau 2.6 n'était pas si merveilleux, avec je sais plus combien de centaines de patch appliqués en quelques mois.
Encore pour info MS a développé son propre UNIX (Xenix) et apparement ils ont même été les plus gros vendeurs d'UNIX à une période (j'ai pas trouvé de lien à ce sujet). Et puis ils se sont tournés vers "l'excellent" VMS, qui est mystérieusement devenu minable sous l'appelation de Microsoft NT. Pourtant les développeurs c'étaient les mêmes. J'ai assisté à une conférence de Russinovich sur noyau NT vs noyau Linux. J'avais déjà noté quelques "innovations majeures" sous Linux présentent sous NT depuis 10 ans, mais là, fait par un pro, c'était impressionant. Il a un peu expliqué aux développeurs du kernel comment améliorer Linux, en basant ses explications sur NT (kernel ré-entrant). Et aussi glissé l'utilisation d'une technologie breveté MS dans le noyau Linux et sur le fait que MS fermait sa gueule (IO competion port). Ca et plein d'autres choses. Personnelement j'ajouterais les ACL qui arrivent en grande pompe avec le kernel 2.6, huhu, il était temps.
 

Un mec qui écris une lib pour XML en C sous Linux, je vois pas en quoi c'est une référence du développement sous Windows. Maintenant si je te demande de me coder une lib XML capable de sérialiser en un flux XML n'importe quel objet / structure d'objet, tu vas peut être avoir du mal en C. En Java/C# c'est plus que possible, c'est facile et déjà fait grâce à l'introspection, mécanisme absent en langage C.
Après on peut critiquer les "bloatwares", n'empêche que pondre une IHM qui visualise le contenu d'une table d'une BD c'est fait en une minute avec VS. Si des millions de gens/entreprises payent ces outils si chers, c'est bien que malgré cette dépense ils rentrent vite dans leurs frais.
 
Ahhhhh. Ca fait du bien en fin de semaine de se détendre un peu.

Ben sous Linux, dans les librairies qui te sont proposées, le C standard est respecté du mieux possible (pour des questions de portabilité, de respect pour cet art qu'est le code toussa ), tu n'as pas la surprise de constater que le développeur de ton système a réadapté une norme à sa sauce merdique dès que tu veux faire un Hello world graphique. Et la couche graphique directement intégré au noyau, c'est vraiment à réserver à un OS de secrétaire.
 

http://java.developpez.com/livres/penserenjava/
 

Super! Un code de 42 millions de lignes! ils auront accès à  une doc équivalente à celle qui est mise à dispo sous *BSD et Linux aussi? avec les memes audits de code? l'acces au mailing lists de developpement pour le suivre en temps réel ainsi qu'à leurs archives?
Ah ben non!... zut ils pourront quand meme s'amusé à coups de grep pour constater qu'il y a plein de gruikeries bien dégueulasses à l'intérieur http://www.glue.umd.edu/~sturdiva/ [...] ments.html
 

C'est sans doute pour çà qu'il font autant affaire avec SCO (qui sans eux serait mort de connerie) en ce moment.
 

Ce qui est d'autant plus méritoire que Windows sort avec 20 à 30 ans de retard sur Unix à chaque fois (c'est cool de défragmenter ses partitions hein?)
 

Windev existe sous linux aussi
Le plus gros temps consacré au développement d'un logiciel étant sa maintenance je te souhaite beaucoup de plaisir.  
 

Oui moi aussi ce soir je vais regarder la starac sur TF1 en mangeant un menu BigMac de chez Macdo avec un bon coca. Il faut que je sois en forme car demain c'est samedi et je dois honorer ma compagne.

 
interessant, ya beaucoup de vrai

Si tu crées un projet graphique avec KDevelop faut pas pleurer que t'as du code C non standard. Là c'est pareil. Et je te rappelle que devcpp c'est GNU GCC derrière.
Pour la couche graphique intégrée au noyau, d'abord c'est pas intégré au noyau, ça a été basculé en kernel land, c'est pas la même chose.  
A l'origine c'était pas le cas (NT 3.5). Ca faisait plaisir aux philosophes des OS, mais c'était lamentablement lent (switchs user<->kernel mode), comme sous Linux. Ils ont changé et c'est une très bonne chose. J'ai jamais lu de raison valable de critiquer ce choix. Windows n'est pas destiné à être utilisé en mode console, donc:
- y'a rien de choquant  
- même si on le met en user mode, si l'interface plante, certe ça fait pas un BSOD, mais l'OS est quand même inutilisable et ça revient au même. Donc le passer en kernel land ça change pas grand chose. Avant on était emmerdé, après on l'est toujours.
Dans les faits, ça a prouvé son efficacité. Les plantages à ce niveau sont minimes.
Au passage un Linuxien qui traite Windows de sectaire ça me faire rire. Un Linuxien sectaire extrêmiste, c'est un pléonasme.
 

Ca m'éclaire pas plus, à moins qu'en C on ait les classes, interfaces, exceptions, multitherading, garbage collecting, RTTI, VM, AWT/SWING, RMI, ...
 

Coup classique de la sur-enchère. Je répond juste au fait que tu dis que c'est un code totalement fermé. C'est faux.  
Avant d'avoir fait le tour de la MSDN faut potasser déjà. Le kernel est pas mal documenté, tu peux poster sur les newsgroups MS où des développeurs MS répondent, et on trouve de très bon bouquins. Pour le développement biensûr que non, ils ont pas droit de toucher au code source.
 

Dans le concours du pire, jette un oeil aux sources de flex. C'est du C standard comme tu l'aimes, et comme je le déteste.
Tu peux lire des trucs intéressants sur le noyau NT écris par le même Russinovich qui casse Linux. Il avait mis au point des routines qui détectaient et généraient des BSOD. Y'a des rumeurs aussi comme quoi si MS n'ouvre pas son source c'est qu'il est trop merdique et qu'ils se prendraient des hack à gogo illico. Mais ça change. Suite à blaster etc... MS rectifie le tir. Ils ont fait un grosse grosse code review pour le SP2. Mais assurer la qualité de 40 millions de lignes de code c'est pas facile. MS c'est une entreprise comme les autres. Si on cherchait des poux de manière aussi intense à d'autres softs, y'aurait des désillusions. Parlons de la bouze MacOS 9 un peu. Parlons du code BSD intégralement pompé pour faire MacOS X. Ou encore Linspire / Lindows, ils sont bien plus vilains que MS.
Je rigole bien quand y'a une boite censée open source Linux etc... qui tout d'un coup prend un décision qui "fâche la communauté". Les mecs, équipés 100% Linux / GNU de tous les côtés, ils se font pirater la gueule en représaille dans la nuit qui suit. Huhu, une faille sur demande.
Faut arrêter les fantasmes. www.microsoft.com c'est le site qui recence le plus de tentatives d'attaques au monde, et faut croire qu'ils s'en tirent pas trop mal, y'a pas souvent un pinguin en première page. Si demain la cible change des mythes vont s'écrouler. Un logiciel est sans failles tant qu'on en cherche pas. C'est comme le PDG de Oracle qui a pris ses désirs pour des réalités en disant que c'était l'outil infaillible. Ca a pas mis longtemps.
Windows XP est très stable. Savoir qu'il plante au bout de 100 jours alors que Linux il parrait que c'est jamais, je m'en tape. Mon PC je l'éteind tous les jours. Je le met même en veille prolongée, comme ça il boot en 3 secondes montre en main, et je récupère tout dans l'état où je l'ai laissé.
 

Non. C'est en partie pour Interix / SFU, et pour un autre "projet confidentiel", dont je n'ai rien su. Wait & see...
 

Faut argumenter. La défragmentation tu vas peut être enfin apporter une réponse à cette histoire que Linux n'en n'a pas besoin, parce que c'est un bel OS magique qui n'est pas fragmenté. On en a déjà aprlé ici, pas eu de réponse, toujours un lien vers une ligne évasive sur le net "pas besion d'être défragmenté...". Au passage je défragmente pas mon disque. Faut distinguer NTFS de FAT, WinNT de Win9x. On est d'accord que je parle de NT depuis le début, et on est aussi d'accord que Win9x c'est pas un OS, c'est un joujou.
Par contre lors de mes premières années d'étude en info, sous NT, je faisais clic droit sur mon dossier de TP -> partager seulement à mon binome. Je viens de finir mes études, j'ai jamais pu faire ça sous UNIX/Linux. Partager à tout le groupe, donc à toute la classe. Résultat : certains étaient spécialisés dans le pompage de TP des autres. Vive la sécurité sous UNIX.
 

Windev en est à la version 9, faut croire que c'est utile à certains. Et Windev c'est pas le sujet.
Parlons en de la maintenance/debugging. Ce qui motive des mecs à ne pas utiliser le C, c'est justement à cause de ça.

eh les copains fallait pas se déchainer tant que ca juste pour mon post !
 
Sinon Lam's tu dis un 1/4 vient du projet GNU. Et alors ? Linux est un projet GNU je ne vois pas le hic.
 
Et puis je connais un peu les produits microsoft.  
Je faisais un tp sur flex/bison sur windows avec le compilo je sais plus quoi. Je peux te dire que je m'en rappele, j'en ai encore la nausée

non, linux c'est pas GNU, c'est l'os GNU/Linux qui l'est en partie (linux c'est le noyau)

et c'est quoi alors GNU/Linux ?

L'OS : le noyau Linux + les outils GNU.

ok
Mais bon je ne vois toujours pas le mal à ce que cela est été pompé à droite à gauche. Si ca marche ou est le problème ?

Je parlais du WinMain à la place du main...  

Ouais bon c'est pareil  

Ben en utilisation serveur pure, c'est une verrue, un truc qui n'a rien à voir avec l'usage du système peut emporter la bécane... Quant à la probabilité minable de plantage de l'interface graphique euh... tu es un peu de mauvaise fois quand même

Il y a des linuxiens qui sont objectifs il y en a aussi, bon ok il font pas partie des 80% de neuneus qui trainent sur DLFP et qui se prennent pour des w4rl0rds parce qu'il ont Linux en dual boot depuis 3 semaines. Mais entre nous je préfére le neuneu linuxien arrogant à son homologue windosien, le linuxien a au moins le mérite d’être motivé.
Et oui MS aime bien prendre un standard et le réadapter à sa sauce pour le cloisonner.

C'est quoi l'utilité du truc alors? En faire du pq, du papier peint?
 

ok

Euh faut arreter un peu avec "la communauté", "les linuxiens" gnagna. La "communauté" c'est une vaste supercherie. Il y a des types qui publie un projet sous une licence dite libre jamais entièrement par altruisme mais par vanité intellectuelle, soucis de reconnaissance, vision politique, obligation légale...
Il n'y a pas de blocs il n'y a qu'à voir l'entente cordiale entre Apache et JBoss, Debian et Mplayer, au sein du projet Debian... et combien de fois la roue est réinventée entre les libs de détection matériel, les outils de gestion de paquetage etc...
Bref les mecs qui font du libre ne sont pas une horde de communistes barbus et lobotomisés aux ordres de RMS.

Euh c'est un peu compliqué. Bon je tente :
un fichier logique doit etre ecrit dans des secteurs (secteurs qui composent le disque dur) pour faire correspondre un fichier logique à un fichier physique.
Le fichier physique est donc un ensemble de blocs physiques qui doivent etre alloués au fichier logique
Il y a différentes méthodes d'allocation, c'est là que çà va se jouer :
Les allocations contigues ou par zone (on va zapper la par zone) : en gros un fichier occupe un ensemble de blocs contigus. Un espace suffisant doit donc etre réservé selon 2 méthodes : on prend le premier trou qui convient ou on choisit le trou dont la taille est la plus proche du fichier. Si le fichier est étendu il faut le déplacer vers une zone libre plus importante ce qui est très couteux. Avantage de ces méthodes : simplicité Inconvénients : très mauvaise utilisation de l’espace libre qui implique que des blocs libres vont etre de plus en plus difficiles à trouver d’où nécessité de recompactage (défragmentation). C’est cette méthode d’allocation qui est en  gros utilisée par FAT NTFS.
L’allocation indexée : le fichier est vue comme une structure de données, en gros une table est créée sur un bloc avec ses entrées vide qui sont mises à jour au fur et à mesure de l’allocation et de l’évolution du fichier, les blocs physiques du fichiers peuvent etre dispersés n’importe où sur le disque, l’espace et donc beaucoup mieux géré et la fragmentation quasi nulle.  Les systèmes de fichiers sous linux vont meme plus loin pour optimiser (il utilise une liste de listes chainées qui elles contiennent les blocs physiques). Enfin sous linux, les systèmes sont plus ou optimisés pour des fichiers de petites tailles (reiserfs) grosse taille( xfs, jfs)… L’inconvénient est que c’est moins rapide que l’allocation contigue mais bon c’est plus fiable et plus adaptée au serveur.
 

Bof comme tu disais çà dépend pour quoi après tout le Java Desktop est codé en C… Tu connais la Glib ? Essaye, çà métamorphose l’approche qu’on a du C.

main() c'est standard C, ça te refile une console.
WinMain() c'est standard Windows, tu n'as pas de console (par défaut). Un programme windows n'est pas destiné à être utilisé en mode console, donc on fait la distinction. Y'a aussi un aspect historique avec des paramètres hérités de Win16, alors nécessaires car sous DOS.
 
 

Plantage dans win32.sys ils sont rares. Je retrouve pas le liens vers les dernières statistiques, mais c'était la plus petite cause de BSOD il me semble. Hormis les drivers tiers, c'est essentiellement dans le kernel que ça se passe.
Ca n'a pas d'impact sur la sécurité d'un serveur. C'est sollicité que pour la partie graphique. Pour la consommation de ressources, win32.sys fait 1.75 Mo sur mon XP. Si ton serveur est à 2Mo près, c'est pas ça qui va résoudre ton problème.
 

Aller le vilain MS qui vole les standards. Et qu'auraient-ils du faire ? Utiliser POSIX ? Cette API C à base de char * qui ne permet donc pas l'utilisation d'UNICODE ? Cette API qui n'avait pas encore normalisé les thread et les ACL alors que MS avait déjà sorti DirectX ?
Même Linux, LE clone d'UNIX, LE M. OS Standard, il apporte des extensions à tour de bras, c'est dire...
 

C'est pour les spécialistes du développement système Windows style drivers (MVP Windows). C'est normal de pas pouvoir le modifier. N'importe quel projet sérieux laisse pas n'importe qui modifier n'importe quoi. Sous Linux c'est pareil, le premier venu il se voit pas refiler un accès en écriture au code.
 

C'est ce qui discrédite cet OS selon moi. Soit c'est trop, soit c'est pas assez. Après on parle de standard.
 

J'ai pas dit ça. Je suis favorable au libre. D'ailleurs je file des coups de mains à quelques projets. C'est juste que c'est pas la panacée. A croire certains GPL c'est le label "bug free, super qualité, code propre". Ben non. Croire qu'un mec va débuger ton code moisi c'est du délire, et y'a plein de domaines où les applications commerciales sont meilleures. Et à commencer par tout ce qui n'est pas purement technique, et qui compte peut être plus. Car GPL c'est un truc d'informaticiens, bénévoles qui font ça dans leur temps libre, pour se détendre presque, qui aiment bien faire de nouvelles features, mais qui aiment pas passer du temps à tester le déploiement, à se prendre la tête sur la configuration, à aider les débutants, à écrire des tutorials & exemples, etc... Et là les produits commerciaux font la différence. Même si techniquement ils sont moins bons, t'as des mecs qui ont bossé à ce que tu utilises le truc simplement, que tu l'installes facilement, que la doc soit riche et à jour, etc... Y'a pleins de projets qui marchent bien en théorie, mais intégrés à d'autres projets libres ça conflicte, ça marche plus, etc... D'ailleurs la plupart des projets GPL sérieux y'a une société commerciale derrière qui fait son beurre là dessus, à commencer par Linux. Les projets GPL sans mec payés à faciliter l'utilisation du bidule, bien souvent ça te confirme que free ça se traduit par libre et pas gratuit. Car un développeur monopolisé à faire fonctionner un truc gratuit ça peut couter beaucoup plus cher qu'une appli commerciale.
 

A un détail près je suis d'accord : comment faire autrement ? => Lire la suite...
 

Tu vois c'est ça que j'arrive décidément pas à piger. Quand la FAT découpe son fichier en plusieurs tronçons sur le disque, c'est un système merdique. Quand c'est Linux qui "disperse n’importe où sur le disque", c'est pas de la fragmentation, c'est un truc génial.
Moi je pars d'un principe simple. J'ai une partition vide de 3Go. Je copie 3 fichiers de 1Go. Ok. Tous les FS/OS vont les copier les 3 à la queue leleu. Ok.
Je supprime le premier fichier, le troisième fichier. J'ai 1Go de libre - 1Go d'occupé - 1Go de libre. Ok.
Je copie un fichier de 2Go. Sous Windows ça fragmente. Ok. Par quel miracle sous Linux ça fragmente pas ?  
 

La FAT est un très bon système de fichier pour ce qu'il a été conçu : les disquettes. La FAT12 est minuscule en mémoire, même y'a 20 ans elle pouvait être intégralement chargée. C'est un système de fichier destiné à manipuler un petit nombre de fichiers. Son gros inconvénient est que les répertoires sont vus comme de simples fichiers, et il sont dispatchés partout sur le disque et ça devient n'importe quoi avec FAT32 ou là elle mérite bien le terme FAT (=> gros). Une recherche de fichiers sur un disque FAT ça prend des plombes. Il faut parcourir tout le disque pour avoir l'arborescence, la tête de lecture de cesse de faire des aller-retour. En plus la table FAT est de taille fixe, très faible avec FAT12, mais énorme avec FAT32, ce qui fait qu'elle peut se retrouver swappée, bref, c'est la mort.
NTFS c'est autre chose. NTFS utilise une MFT, une table contigue qui stocke l'arboresce et les infos sur les fichiers (nom, date/ heure création, droits, etc...). La MFT n'est pas fragmentée, ce qui rend une recherche de fichier bien plus rapide. De plus les fichiers de toute petite taille y sont directement stockés. Idem pour les répertoires de taille raisonnable, s'ils sont très gros ils sont structurés sous forme de b-tree dans un fichier en dehors de la MFT.
La MFT pointe le contenu des fichiers appelés extents dont la taille est variable.  Là aussi contrairement à FAT t'es pas obligé de parcourir toute la liste des clusters pour savoir où se trouve le dernier. Pour chaque extent on connait sa position virtuelle dans le fichier. Avec FAT, si ton fichier fait 4Go, vu que les clusters sont chaines, il faut parcourir toute la liste des clusters dans la FAT pour trouver où se situe la fin du fichier sur le disque. Avec NTFS, si ton fichier tient sur un seul extent, tu sais de suite où est sa fin. C'est très proche des inodes en somme.
Comme les derniers fs Linux, NTFS 5 est journalisé, gère les quotas, les liens physiques, les ACL, les points de montage, les sparse files, les noms POSIX, ...
Mais NTFS gère aussi en transparence la compression, le cryptage, les flux multiples dans un même fichier, les reparse points, les noms UNICODE...
 

Moaui. Je préfère rester en C++ avec la STL, au moins c'est standard...

Et pas standard du tout
 

Je me suis mal exprimer, je parler de html sauce MS, LDAP sauce MS etc.....
 

Les standards sont là (FHS, LSB, Unix, POSIX, SV...), en fin de compte il n'y a pas de très grandes différences entre les distributions Linux et dans l'absolu entre les Unix au niveau administration et programmation. Si tu connais un Unix tu n'auras pas trop de mal à te débrouiller avec Linux, un BSD, un SCO OSR5, un Solaris... à toi de te débrouiller pour regarder ce qui font leur spécificité, en général, c'est passionnant
 

Ton exemple est un peu biaisé car il ne tient pas compte de l'évolution des fichiers, or c'est çà (en plus des ajouts/suppressions) qui -dans l'allocation contigue- va désorganiser l'espace libre, provoquer des déplacements de blocs contigus, faire qu'au bout d'un moment on va se retrouver en rade d'espace libre et devoir défragmenter. Bref
En fait dans avec l'allocation indexée, les blocs vont etre alloué en fonction de la politique d'ordonnancement des accès disque (le déplacement minimum du bras en tenant compte de l'évolution du fichier). Par conséquent (dans l'absolu, sans tenir compte du bras) les blocs de chacun des 3 fichiers peuvent etre dispatchés de manière contigue comme de manière complétement aléatoire, on s'en fiche il n'y aura, de type façon, pas de déperdition de l'espace et pas de "recompactage" nécessaire
 

Entièrement d'accord

Windows devrait être standard LSB peut etre ? Tous ces standards au mieux c'est des standards pour systèmes UNIX. Partant de là, si ton OS n'est pas un UNIX je vois pas en quoi on peut te reprocher de ne pas les respecter.
 

La défragmentation a essentiellement pour but de réorganiser les fichiers de manière contigue et non aléatoire. D'après ce que tu me dit Linux en aurait bien besoin, et c'est peut etre pour ça que defrag a été développé.
Et ce que tu expliques est valable pour NTFS.
http://www.ntfs.com/ntfs-mft.htm
Bref, je vais encore rester sur ma faim.
 
Faut savoir que NT et Linux ont plus de points communs que NT et Win9x. Y'a pas 36 manières de faire un OS, et les concepts généraux et contraintes sont les mêmes. Si tu te penchais un peu sur l'architecture de NT tu serais surpris. Tu trouverais des similitudes avec UNIX et des différences intéressantes. Le papa de NT c'est pas un amateur.
Après je pense que c'est au nivo administration que ça change beaucoup, mais là c'est pas mon domaine, NT ou UNIX j'aime pas ça.

Oui en effet, c'est de çà qu'on parler non?  
ton post était :

Je ne fais que souligner que malgré la différence de code tous les unix -et à fortiori Linux et ses différentes distributions- sont cohérents entre grâce à des normes et des standards respectés.

oui

Non!  
Relis mes postes.
La fragmentation sous Linux (avec ext2/ext3/reiserfs et quelques autres hein!) est quasi nulle (elle ne dépend pas du système d'allocation en général mais de la taille des blocs par rapport à la taille des fichiers stockés que l'admin système a choisi.
En général il la choisi large car les appli ont à dealer avec de gros fichiers ce qui a pour conséquence une légère perte de place dans le cadre des fichiers trop petits (petits fichiers stockés dans des blocs trop gros pour eux) et si tu me parles de çà http://www.oo-software.com/en/products/oodlinux/ ou çà http://linux.maruhn.com/sec/defrag.html ,dit toi que çà ne sert pratiquement à rien et que ce n'est pas intégré du tout ou de base (dans le cas de debian et de ses 14000 paquetages) dans les distributions pour le second.

J'ai la flemme de lire mais le problème -si je puis me permettre- c'est que je te parle d'un concept dans un sens très large et que tu me répondes feature de NTFS.
Je peux te balancer un lien avec de la doc sur à peu près toutes les sortes de filesytems que linux gère (bon courage http://www.xenotime.net/linux/linux-fs.html )

Promis je le ferais
 

Si! c'est pas du tout la meme "école" je dirais et cf plus haut il y a une cohérence entre les Unix que tu ne retrouves pas sous Windows.

J'avais pas capté que tu parlais des standards vis à vis de Linux. Au tout début on parlait des standards et de Microsoft. Ok donc
 

Ben:

Je me doute bien, c'est pour l'image que j'ai filé le lien : c'est pas loin des images qui illustrent le principe des inodes. Ce concept dont tu me parles est utilisé par NTFS et l'était déjà par HPFS qui en est l'ancêtre et qui était déjà censé résister à la fragmentation.
D'ailleurs y'a pas de défragmenteur livré avec NT4, c'était le cas avec Win9x car là avec la FAT c'est justifié. Mais la FAT, tout le monde est d'accord que c'est pas fait pour ce que ça a été utilisé. Pour la petite histoire, la légende veut que ce soit Bill Gates qui l'ait inventée en quelques jours dans un hotel afin de rajouter le support des disquettes à son BASIC, il y a...28 ans.
http://www.microsoft.com/mscorp/ip/tech/fathist.asp
 
edit: tiens ça me fait penser que ça devrait pas tarder à tomber dans le domaine public. La limite d'un brevet c'est 30 ans non ?

Euh... je pense qu'en fait tu as compris un truc qui m'est complétement passé à coté ou alors je suis très mauvais pédagogue...
 
On a deux types de fragmentation :
- une au niveau de l'espace libre :  
Allocation contigue : on alloue des ensemble de blocs contigus -> des ensembles de blocs physiques libres contigus (ou d'un seul et unique bloc) se retrouvent entre deux blocs. Au bout d'un moment aucun de ces divers ensembles de blocs contigus libres ne pourra contenir les blocs contigus que nécessitent le fichier X -> recompactage nécessaire
 
Allocation par table indexée : un bloc peut etre situé n'importe où sur le disque et c'est la table indexée (l'inode qui est une structure de données qui contient diverses informations nom, droit, proprio, groupe, heure...  et une table des adresses des blocs de données) qui permet de lier les blocs de données d'un meme fichier.  
C'est atomique donc, dans l'absolu sur 3 blocs contigus le bloc 1 peut appartenir au fichier A, le bloc 2 etre libre et utilisable, le bloc 3 etre encore à A, si le fichier A grandit le bloc 2 pourra lui etre alloué, la liste chainée fera 1->3->2.  
A la création du fichier aucun bloc ne lui est alloué (contrairement à la méthode précédente où on alloue un "bloc de blocs" ) les blocs sont attribués au fur et à mesure de son extension et n'ont pas besoin d'etre contigus -> on évite le problème de blocs d'espace libres inutilisables. L'espace libre est d'ailleurs lui aussi géré comme une liste chainée.
 
- une au niveau du bloc
fragmentation à l'intérieur d'un bloc quand le fichier est vraiment minus à l'intérieur d'un grand bloc (le sysadmin en choisit la taille, généralement c'est entre 512 et 4096 octets)
 

çà m'apprendra à aborder une conversation sérieuse suite à un gros troll velu de ma part (j'ai l'air con )
Merci en tout cas pour toute ces infos sur NTFS.
 

Amusant quant à la question relative au brevet je ne sais pas mais http://linuxfr.org/2004/10/01/17325.html ...