Discussion :

[baccali]

Bonjour à tous,

Je débute en programmation windows et mon manque d'expérience me fait défaut. Je n'arrive pas à déterminer sous quels conditions on doit utiliser les fonctions ANSI de Windows.

J'hésite franchement entre créer une application avec les fonctions génériques de Windows et créer une application qui fait tous ses traitements en unicode directement! J'ai cru comprendre que depuis NT, Windows n'utilise que l'unicode en interne. Donc ma question est : à quoi servent les fonctions ANSI qui de toute façon appellent les fonctions Unicode en transparence? Quand est-ce qu'il faut intégrer le MultiByte-Character set dans un programme windows?

Merci

[ram-0000]

J'ai cru comprendre que depuis NT, Windows n'utilise que l'unicode en interne.

C'est exact, de plus, la très grande majorité des fonction existe maintenant Unicode (il reste encore quelques fonctions qui sont MBCS only).

Donc ma question est : à quoi servent les fonctions ANSI qui de toute façon appellent les fonctions Unicode en transparence?

Retro compatibilité ? pour rester compatible avec les anciens projets, ce n'est pas si simple que cela de passer un gros projet de MBCS à UNICODE, il y a pas mal d'effets de bord, il faut tout retester.

Quand est-ce qu'il faut intégrer le MultiByte-Character set dans un programme windows?

Maintenant, je dirais JAMAIS.

[baccali]

Bonjour ram-0000,

Ok C'est bien ce que je me disais mais quand même je suis pas mal surpris! Cela fait quand même plus de 10 ans qu'on est passé à NT et Microsoft préconise encore d'utiliser les fonctions génériques! C'est pour celà que j'avais un doute.

Peut-on supposer par exemple que si l'on destine son logiciel à l’internationalisation celui-ci risque de tomber sur un système MBCS? J'ai cru comprendre qu'en Chine et autres pays du genre ils l'utilisent encore ( Sources : http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx ). Peut-être s'agit-il simplement des fichier textes!

Si c'est le cas ou l'info est périmée tant mieux! Mais sinon si je décide de l'intégrer, sachant que Windows travaillent en UTF-16 en interne, quand est-ce qu'on doit utiliser les fonctions MBCS? Je soupçonne que des "inputs" en MBCS convertit directement en UNICODE pour le reste et reconverties en MBCS pour les sorties seront suffisantes mais comme mon projet risque d'être assez conséquent je ne voudrais pas avoir à réécrire 150 pages de codes au final.

[ram-0000]

Il me semble que Windows 98 est le dernier OS à travailler NATIVEMENT en MBCS. Depuis, tout le monde maintenant est NATIVEMENT en Unicode.

Si tu destines ton logiciel à l'internationalisation je ne puis que te conseiller d'utiliser UNICODE. J'ai travaillé sur un projet MBCS porté en Japonais et ce n'était pas simple, il faut une extrême rigueur dans les traitement des chaines de caractères et les (mauvaises) habitudes reviennent vite avec à la clé à chaque fois le même résultat, un bug pas simple à diagnostiquer dans une langue que tu ne maitrise pas :-).

En ce qui concerne l'API, je suppose que les fonctions Unicode sont les fonctions natives et que les fonctions MBCS transforment leurs entrées/sorties avant d'appeler la vraie fonction Unicode (en tout cas, c'est comme cela que je fais lorsque je dois fournir une API Unicode et MBCS).

[baccali]

Oui effectivement Windows transforme TOUTES les chaînes qui ne sont pas unicode avant de les traîter. TOUTES! Du moins sur un système NT et ce depuis Windows 95 d'après la doc que j'ai.

Merci pour tes réponses je suis rassuré! Malheureusement comme je bosse sur un logiciel qui doit pouvoir traiter les fichiers unicodes (utf-8, utf-16, utf-32 et malheureusement MBCS et SBCS) je vais devoir bidouiller légèrement mes chaines de charactère mais grâce à toi la portion de code est grandement réduite.

Cordialement

[Médinoc]

Le mieux, c'est de bosser avec des TCHAR partout sauf dans les interactions avec des fonctions n'existant qu'en "ANSI" (genre GetProcAddress()) ou en UTF-16/UCS-2 (genre les fonctions liées à COM).

Les classes de conversion de ATL (CA2T, CT2A, CW2T, CT2W) sont intéressantes pour ça.

Et bien sûr, régler le compilo pour que les TCHAR soit interprétés comme des caractères Unicode (macros UNICODE et _UNICODE définies; Visual >= 2005 propose une option du projet qui fait ça toute seule).

[ram-0000]

... avec des fonctions n'existant qu'en "ANSI" (genre GetProcAddress()) ...

C'est marrant car la doc MSDN indique que GetProcAddress est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
FARPROC WINAPI GetProcAddress(
  __in  HMODULE hModule,
  __in  LPCSTR lpProcName
);

donc a priori une fonction TCHAR

le fichier winbase.h est d'accord avec cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
WINBASEAPI
FARPROC
WINAPI
GetProcAddress (
    __in HMODULE hModule,
    __in LPCSTR lpProcName
    );

Mais il n'y a pas de fonction GetProcAddressA() et GetProcAddressW() dans les headers

Comment c'est géré lorsque tu es en mode Unicode ?

[Melem]

STR c'est du char *, CSTR du const char *, LP pour les strings est superfu. En gros, LPCSTR = const char *. const TCHAR *, ce sera plutôt LPCTSTR.

[ram-0000]

const TCHAR *, ce sera plutôt LPCTSTR.

Ah oui, merci, je n'avais pas vu l'absence du T

[baccali]

Un peu tard mais merci pour ces réponses j'avais un peu délaisser le topic j'ai pas eut beaucoup de temps libre récemment!

Le mieux, c'est de bosser avec des TCHAR partout sauf dans les interactions avec des fonctions n'existant qu'en "ANSI" (genre GetProcAddress()) ou en UTF-16/UCS-2 (genre les fonctions liées à COM).

Oui j'avais bien compris mais je voulais surtout savoir pourquoi c'est mieux vu que comme tu le fait remarquer lorsqu'on travaille avec des fonctions susceptibles de ne pas utiliser de l’Unicode on le gère explicitement!

[Médinoc]

C'est mieux parce que si jamais les standards changent encore, ce seront les TCHAR qui changeront et tu n'auras pratiquement pas de modifs à faire pour porter ton programme.

[baccali]

Ok je te remercie pour ta réponse Medinoc. Juste par simple curiosité quel fut le dernier changement de standard concernant les char (sous windows?) ?

Sinon Melem, pourquoi dis-tu que Long Pointer pour les strings c'est inutile? Apparemment sur des machines 32 bits et sur des systèmes post 3.1 (et sur des 64 bits aussi je suppose) le T est inutiles quelque soit le type de données. Sur d'autres systèmes ou machines les strings sont gérées différemment?

Merci

[Médinoc]

• Pour l'instant, le seul changement à ma connaissance fut le passage de "ANSI" (entre guilllemets parce que Windows-1252 n'est pas un standard ANSI, en fait) et UCS-2/UTF-16. Mais rien n'empêcherait que dans le futur, on passe à UCS-4/UTF-32, par exemple.
• Melem dit que la partie "pointeur" dans la description du type est superflue, car une chaîne de caractères est déjà un pointeur. Toutefois, il oublie que la distinction est faite pour les chaînes dans les structures: pointeur ou tableau.

[baccali]

Ok merci pour ta réponse concernant les standard.

Par contre ma question c'était plutôt pourquoi le LONG et non pas sur les pointeurs même, çà je sais comment ça marche. Aurais-tu une idée?