gooogle

Pour ton boulot ? mais tu fais quoi ? ? !!! c'est souvent le plus long, le plus chiant et le truc qui est le moins gratifiant quand t'as fait un logiciel... De rien ! Mais si je peux me permettre, même si t'es sous borland builder, y aurait pas moyen de faire une appli linux native ? de pas passer par Wine, son emulateur pas terrible pour les ihms (y a quelques bugs d'affichage, genre toutes les sous-fenêtres crées sont forcément sous la fênetre principale, du coup, on sait pas pourquoi ca répond plus....etc...), et surtout de pouvoir gérer le système de chemins linux avec ses chemins du style /usr/home/ton_login/... ? Car effectivement, sous windows, c'est vraiment la seul appli que j'utilisais pour gérer mes isos, mais là, sous linux, il perd de son intérêt, qu'il retrouverait s'il s'intégrait via du gtk ou un truc du genre... M'enfin maintenant, c'est juste que tu veux des retours sur ton soft, moi je te donne que le mien, concernant linux..., ce qui correspond j'imagine qu'à très peu de ses utilisateurs... J'imagine ! un bug qui apparait dès le démarrage et qui bloque la fermeture de l'appli... c'est généralement assez vite corrigé !! De rien ! Merci bcp de tous tes renseignements. J'ai pas le temps d'appronfondir aujourd'hui en détails, et faire quelques tests sur ce que tu me proposes, mais là, je crois que tu m'as donné un apercu général de ce qu'il fallait faire, suffisamment détaillé pour que j'arrive à me débrouiller tout seul (enfin j'espère). J'ai commencé à me rencarder sur le format Iso, je comprend bien mieux ton message... Dans le cadre d'une compression d'umd, oui tu as raison, maintenant proposer cela dans un cadre général d'iso de cd et de dvd, je serais vraiment preneur !! Mais dans ce cas là, il faudrait non plus lire des 31 bits, mais 63 ! Tu as quel age pour dire que t'es d'une vieille génération sans google ! Oui, l'anglais, je maitrise à peu près, je code hélas pas dans la langue de molière au taf... Sinon, tu as raison, je pourrais aller dans les sources des libs de linux, mais c'est un truc dont j'ai pas trop le réflexe, à ma grande erreur je le concède... Je ne crois pas que cisoplus puisse m'aider pour ce que je faire ! A moins que tu proposes libciso et cisoplus comme application cliente de la lib de lecture d'une iso, ca oui, là je tu pourrais m'aider. Mon but est de pouvoir me faire un p'tit gestionnaire de mes dumps... je peux déjà le faire avec des isos, mais comme j'ai pratiquement tout compressé, ca va pas le faire. C'est pour cela que je veux pouvoir lire les cso, et là je pourrais me faire un p'tite interface sympa pour voir ce que j'ai... En fait, l'avantage des umd, c'est qu'il ont tous les mêmes fichiers de départ, formatté de la même façon... Ainsi, les vidéos pour les xmb sont toujours au même endroit, les images de fond pour le xmb et pour la sauvegarde sont égalemnet toujours au mêmes endroits, et la récupération du nom du jeux et également facile... Du coup, y a moyen de faire un truc sympa... Et puis, j'aimerai bien pouvoir voir certains fichiers qu'il y a dans les csos, afin de l'explorer. Je pourrai donc me rendre compte que je peux virer ripper certains fichiers en décompresssant l'iso et la recompressant... Associer le tout à une connexion internet (donc pas un soft pour toi !) et ainsi pouvoir récupérer des synopsis du jeux, son style, etc... Bref, de quoi s'amuser un peu... Donc, voilà pourquoi je cherche à accéder à l'iso. Maintenant si tu exportes la fonction d'extraction de fichier dans un cso, je pourrais alors reprendre ton exe voir un point so de cisoplus pour récupérer l'export de la fonction... !

Merci bien kapoue3 pour tes réponses. Alors, dans le désordre des réponses : concernant yacc, je voulais plutot dire que il est plus rapide d'ouvrir un term, faire un "cd outuveux", et d'avoir tous ses fichiers à dispo pour lancer cisoplus, plutot que d'avoir un outil clickodrome ! maintenant, c'est juste une question de goût et de préférences. De plus, je suis pratiquement tout le temps sous linux, et yacc marche (se lance, j'ai pas essayé sous linux la compression) avec wine, mais a tout de même quelques soucis (perso il m'est impossible de le fermer, car j'ai le message d'erreur "Indice de liste hors limites (-1)" lors d'une tentative de fermeture, et impossible de passer outre. De plus, il y a une petite coquille sur ton site (tu avais déjà fait la même, d'après ce que j'ai vu sur ce forum lors d'une précédente release ) : on est en 2008 !!! même si c'est dur pour toi de l'admettre et de l'accepter !!! la version 0.403 devrait être donc du 1er janvier 2008 et non pas 2007, sachant que ta précédente release était de Décembre 2007! Voilà, perso je m'en fous, mais c'est toujours mieux de corriger pour d'autres... Concernant tes réponses j'ai encore quelques interrogations (je t'assure, c'est pas à cause de tes très bonnes réponses, c'est seulement moi qui suis dur de l'oreille !!!) : si je comprend bien, chaque fichier de l'iso a son propre block ? Donc, si je comprend bien, dans le index[n], on a le bit de poid le plus fort à 0 si la donnée est compressée, à 1 si elle ne l'est pas. Je peux donc retrouver un secteur CSO complétement grâce à cela. Maintenant. tu as dit que un secteur (ou un block) CSO, c'est pas un fichier, c'est juste un block. Tu as dit tout à l'heure (plus haut) que : si je comprend bien, là, tu parles du fichier CSO. Donc, un index de secteur CSO, c'est l'index d'un bloc ISO (compressé ou non). Maintenant, je pense qu'il me manque la compréhension d'un format iso pour bien comprendre. Car notre p'tite psp ne décompresse que ce dont elle a besoin, ce qui m'amène donc à penser qu'elle fait de l'extraction facile des fichiers dont elle a besoin, d'où des subtilités pour avoir les noms des fichiers ! Donc, si je résume encore un peu, pour afficher la liste des fichiers du cso, je dois prendre chaque index de la table d'index pour récupérer un secteur du CSO, puis je décompresse (ou pas) le secteur de taille expliquée plus haut pour récupérer un block du fichier ISO, et là, je fait une lecture correcte de se bloc via une lib de lecture de bloc iso pour récupérer quelque part j'imagine le nom du fichier ??? j'y suis presque, ou je suis complétement à louest ? Dans la même optique, si j'avais un fichier CSO avec aucun bloc compressé, j'aurai donc taille CSO=tailleISO + nbBlockIso*2octets (l'index) + header du CSO ? enfin, dernière question (j'suis désolé, j'suis lourd) pourquoi 2k ? pour moi, une fois que je suis à file_pos_sector[n] = (index[n]&0x7fffffff), alors là, dans le cas d'une non-compression du block je lis directement file_size_sector[n] et j'ai directement mon block. non ? Enfin, je comprend mieux pourquoi le format CSO ne peux pas faire des fichiers de plus de 2Go... en effet, on a finalement pour une valeur de l'index seulement 2^31 valeur possible, soit 2 147 483 648. Or ca, ca fait en Go exactement 2Go. En fait, pour finir, aurais-tu des liens sur le format iso, ou une explication suffisamment facile pour que j'ai pas besoin de regarder une doc ? En tout cas, merci bcp de ton aide, elle m'est précieuse ! D'autant plus que dans la langue de molière, en plus ! merci encore,

Salut Kapoue, Merci pour ton p'tit soft qui m'a permet de gagner pleins de place. J'ai regardé le code dispo sur le net pour l'outil cso (cso.c et cso.h) et j'ai pas vraiment tout compris. En gros pour décompresser un fichier cso, on décompresse des blocks à la suite. Mais comment récupère-t-on la liste des fichiers de l'iso ? Comment fait-on pour connaitre l'indexation des fichiers? il y a bien ce p'tit bout de code en commentaires : /* note: file_pos_sector[n] = (index[n]&0x7fffffff) << CISO_H.align file_size_sector[n] = ( (index[n+1]&0x7fffffff) << CISO_H.align) - file_pos_sector[n] if(index[n]&0x80000000) // read 0x800 without compress else // read file_size_sector[n] bytes and decompress data */ mais je comprend pas exactement ce qu'il veut dire... Si tu peux m'éclairer.... ps : yacc est peut-être bien, mais rien ne vaut l'utilitaire en ligne de commande, qui finalement est bien plus rapide !!