Discussion :

[Hibou57]

Le sujet est toujours d'actualité.

Rappel : les applications Ada compilées avec Gnat, échouent à faire référence à l'interface Unicows, alors que dans le même temps, les applications compilées avec gcc et ayant les mêmes caractéristiques, fonctionnent parfaitement (c'est etonnant quand on sait que Gnat utilise des éléments de gcc).

Aprés un test approprié, j'ai put m'assurer que la dll unicows est bien chargée, et que les symboles qu'elle est censée exporter sont bien accessibles. Les testes ont été effectués avec GetProcAddress : un GetProcAddress sur MessageBoxW par exemple, renvois bien l'adresse de la procedure. Mais quand Gnat tente de charger ce même symbole, la librairie libunicows.a ouvre une boite de message d'erreur et ferme l'application.

J'ai un peu de mal à imaginer dans quel interstice peut bien se glisser un effet de bord quelqu'onque de Gnat (comment peut-il influer sur le mecanisme de liaison entre l'application et unicows.dll... d'autant surprenant que le liaison avec toutes autres dll se passe parfaitement bien...)

Je donnerai des nouvelles... et si vous envez d'ici là, ce sera un plaisir de les lire

[Hibou57]

J'ai repris aujourd'hui les tests concernant ce problème. J'ai trouvé d'où vient le problème, mais je ne le comprends pas.

Dans ma petite application d'essai, il y avait des expressions du genre « S := Integer'Image(X); ». Ce sont ces expression Integer'Image qui pose problème. Je les ai enlevé, et tous fonctionne parfaitement. Je ne comprends vraiment pas comment une expression Integer'Image peut avoir une influance sur le chargement d'une DLL... c'est complétement loufoque ... apparement il y a un sérieux bug de Gnat avec Integer'Image (ça fait beaucoup de bugs pour Gnat je trouve, parce qu'il n'y a pas que celui-ci).

Bon alors, quel est les problème avec Integer'Image sous Gnat ? Débordement de mémoire ? (ce serait la meilleur ça... Ada qui nous fais un truc pareil). Ou alors un phénomène paranormal ? (possible vu la bizarrerie).

[Hibou57]

Grosse deception maintenant que les problèmes de lib est DLL sont pourtant résolus : même avec unicows, MessageBoxW se comporte exactement comme si la chaîne Unicode était une chaîne Ansi : la chaîne est affichée en associant les glyphs et les codes soit comme dans la page de code du système ou soit comme dans la page de code unique supportée par le police selectionnée pour les boite de dialogue (si la police en cours ne supporte qu'une page de code, et même si elle est Unicode). Par exemple, avec une police unicode couvrant l'arabe et les langues de l'europe de l'ouest, et supportant les page de code europe de l'ouest et arabe (cp1256), la position H0627 produira un point d'exclamation. Avec une police unicode et supportant le page de code 1256, la résultat est le même. Mais dans ce dernier cas, il est interessant de noté que pour obtenir le alif, il faut donner la position H00C7 pour obtenir un alif et selectionner la dite police dans les apparences de boite de dialogue... c'est-à-dire que MessageBoxW se comporte exactement comme MesageBoxA !

On se demande à quoi ça sert alors...

Rien sur le net à ce sujet, si ce n'est que des gens se sont apparement déjà posé la même question aprés avoir constaté la même chose, malgré l'utilisatiobn d'Unicows (surtout avec des programmes VB), et qu'il n'y a jamais réponses.

C'est vraiment du n'importe quoi ...

[Aurelien.Regat-Barrel]

WinNT est unicode en natif, Win9x ANSI. Sous NT, les api en xxxA convertissent les paramètrent en unicode et appellent la fonction xxxW, et sous Win9x c'est l'inverse.
Je ne travaille plus depuis longtemps sous Win98, je ne sais pas très bien ce qu'il en est de l'Unicode là dessus, et n'ai jamais utilisé MSLU. Mais RegisterClassW devrait fonctionner, avec ou sans unicows, au moins dans le sens où il convertit la chaine reçue et appelle RegisterClassA.
Tu as oublié de commencer par là où il faut toujours commencer : quand une fonction échoue, que vaut GetLastError ?
Si tu lui donnes une chaine qui n'est pas unicode, c'est normal que ça déconne. Faudrait poster un bout de code qui illustre l'erreur, et préciser le code de l'erreur rencontrée, avant de chercher une solution.

[Hibou57]

GetLastError ne dirais rien de plus, puisqu'il n'y a pas d'erreur d'execution.

Pour RegisterClassExW : si, il faut bien Unicows, parce qu'elle ne fait pas de convertion vers Ansi (ça n'aurait pas de sens). Sans Unicows, l'appel se solde par une erreur « not implemented », et avec Unicows, ça fonctionne normalement (en tous cas pour le moment).

J'étais déjà informé des différences natives de Win9X/Me et Win2000/XP... donc pour ça, c'est Ok. Mais même si Win9x/Me n'est pas Unicode en natif, il a malgré tout la capacité d'afficher l'Unicode normalement (comme en témoigne les capacités d'un RichEd mis à jour sous ces systèmes).

La chaine que je passe est bien Unicode, et j'ai codé directement les caractères un par un, avec leurs valeurs numériques. Donc c'est bien de l'Unicode (UCS2 pour Win9X et UTF-16 pour WinXP, mais le test porte sur des caractères du BMP, et dans ce cas là, UCS2 et UTF-8 sont interchangeables), et les caractères qui existent dans la page de code en cours s'affichent eux normalement.

RegisterClassExW fonctionne, et CreateWindowExW aussi. Mais là idem, dans les barre de titre des fenêtres, les caractères Unicode qui n'appartiennent pas à la page de code en cours sont remplacés par des « ? ».

J'avais parlé de ces deux fonctions, mais c'est bien sure toute (ou les plus importantes) fonctions ayant à faire avec le texte que je veux voir fonctionner normalement. C'est-à-dire au moins les contrôles standards, les boites de messages standards, les zones clientes des fenêtres, les barres de titres et les menus.

Bizarrement, j'ai remarqué que sous Win9x/Me, les applications qui affichent correctement les textes Unicode, ne parviennent pourtant pas à afficher les titres correctement dans barre de titres de fenêtres. Pourtant une zone d'affichage est une zone d'affichage, non ?

Ce qui me chiffone, c'est que j'ai appris aujourd'hui sur MSDN, que sous ces versions de Windows, même avec Unicode, il faut encore passer par les convertions de page de code. Je ne comprends pas, parce que Unicows est cencé permettre de faire de l'Unicode de manière uniforme sur les Win9x/Me et sur les Win2000/XP... et dans les documentations de MSLU, il n'est jamais question de traiter avec les pages de code (j'imagine assez mal une appli WinXP faire de l'Unicode avec des pages de codes... ce serait à mourrire de rire).

Je ne comprends vraiment pas.

Je ne peux pas vraiment donner d'exemple de code, puisque c'est une librairie Ada que je cré pour moi avec des critères précis, et que je ne veux être qu'Unicode (rien d'Ansi dans cette librairie)... alors il faudrait que je sorte vraiment trop de code.

Je ferai des essais avec les zones clientes de fenêtres. Et si ça marche là et pas ailleur, alors je ne verrai pas d'autre solutions que de surclasser les contrôles et dialogues standards pour afficher l'Unicode là ou MSLU ne semble pas pouvoir. Finalement MSLU ne semble pas faire beaucoup de choses...

Mmmhhh.. une autre chose qui me chiffone avec ce que dit MSDN au sujet du fait que même avec Unicode sous Win9X, il faut traiter avec les pages de code : une fonction comme TextOut n'a pourtant pas de paramètre de page de code... et cela signifierai que l'on ne peut strictement afficher que les glyphs appartenant déjà à la page de code en cours (que l'on ne peut pas changer je crois, sauf pour DOS). Ce qui n'est pas le cas bien sure, comme en témoignent plusieurs applications qui font ce qu'elle peuvent pour faire de l'Unicode sous Win9X.

Je ferai plus tard ces autres tests, et j'en reparlerai ici.

Merci en tous cas pour ta réponse et ta bonne attention

Note interessante : Même sous Windows 95, l'interface OLE ne travail apparement qu'avec Unicode d'aprés ce que je crois en avoir compris : il est dit sur MSDN que les interfaces OLE 32bits sont 100% Unicode... ça sent l'incohérence un peu quand-même, parce que pourquoi pas tout le système. A l'époque de Windows 95, le BMP Unicode était déjà totalement défini.

P.S: Je ne peux pas comparer WinXP et Win98 sur ce point, parce que je n'ai pas WinXP. Mais c'est vrai que ça me taraude, et j'aimerais pouvoir faire des essais sur les deux.

[mat.M]

RegisterClassExW fonctionne, et CreateWindowExW aussi. Mais là idem, dans les barre de titre des fenêtres, les caractères Unicode qui n'appartiennent pas à la page de code en cours sont remplacés par des « ? ».

Il faut détecter le code de pagination ( code page ) et convertir avec MultiByteToWideChar et son inverse pour convertir un char 8 bits en WCHAR 16 bits.
Effectivement comme Mayti4 et tu l'auras remarqué Unicode n'est pas supporté par win98.
Dans le code il faut détecter la version de Windows au besoin avec des #ifdef _WIN98 etc...

Au cas ou :


Microsoft Layer for Unicode on Windows 95/98/Me Systems
The Microsoft® Layer for Unicode (MSLU) provides a complete set of Unicode APIs on Microsoft Windows® 95, Windows 98, and Windows Millennium Edition (Windows Me). With this, Unicode applications can run on Microsoft Windows NT®, Windows 2000, Windows XP, and Windows 95/98/Me.


You can download MSLU from the following location: http://www.microsoft.com/msdownload/...psdkredist.htm.

For more information, see the following topics:

Mmmhhh.. une autre chose qui me chiffone avec ce que dit MSDN au sujet du fait que même avec Unicode sous Win9X, il faut traiter avec les pages de code : une fonction comme TextOut n'a pourtant pas de paramètre de page de code...

Pardon j'avais pas lu ; utiliser MultiByteToWideChar pour TextOut

(j'imagine assez mal une appli WinXP faire de l'Unicode avec des pages de codes... ce serait à mourrire de rire).

? Avec une appli en japonais on est obligé de déterminer le code page

[mat.M]

Note interessante : Même sous Windows 95, l'interface OLE ne travail apparement qu'avec Unicode d'aprés ce que je crois en avoir compris : il est dit sur MSDN que les interfaces OLE 32bits sont 100% Unicode... ça sent l'incohérence un peu quand-même, parce que pourquoi pas tout le système. A l'époque de Windows 95, le BMP Unicode était déjà totalement défini.

Ouil les interfaces OLE sont 32bits 100% Unicode , connection avec programmes VB ou Delphi par ex oblige.

[Hibou57]

Au cas ou :

Microsoft Layer for Unicode on Windows 95/98/Me Systems [...]

C'était justement tout le sujet au début de ce thread, puis par la suite son intégration à une application codé en C sous gcc ou codé en Ada sous Gnat... pour arriver maintenant à des chose plus concrête : la mise en application et l'execution de procédures et de fonctions de l'API.

Pardon j'avais pas lu ; utiliser MultiByteToWideChar pour TextOut

MBCS (Multi Byte Character Set) était pour le chinois, le japonnais et d'autres langue asiatiques. Il y avait effectivement dans cet encodage des code à 8 bits parmis des paires qui pouvaient former des code à 16 bits. Mais je ne suis pas certain que cette fonction soit appropriée pour convertire du Ansi (et non pas du MBCS) en Unicode (i.e. UTF-16 ou UCS2). Il y a d'ailleurs une fonction en propre pour convertire le Ansi sous une page de code donnée vers l'Unicode.

MBCS était exactement comme Ansi dans son principe, si ce n'est qu'il ne tennait pas sur 8 bits, et qu'il a donc fallut inventer des astuces (qui ressemble aux surogate-paires de l'UTF-16). Mais dans le principe, c'est toujours un codage sur n bits avec une page de code (parce que sans page de code, impossible d'interpréter ces codes).

Les chaîne de l'application de test étant déjà en UTF-16/UCS2, il n'est même pas ici question de ces fonctions de convertions, puisque les chaînes sont déjà au format attendu par les ProcedureFooBarW.

Je vais quand même faire des essais avec ces fonctions. Mais à moins qu'elle ne produisent pas l'UTF-16/UCS2 que je suppose (auquel cas il y aurait une sorte de page de code Unicode ?... étrange ... ), je n'en voit pas l'intérêt.

Mais je vais quand même voir...

? Avec une appli en japonais on est obligé de déterminer le code page

Plus avec Unicode, ce n'est plus nécéssaire. Il ne s'agit pas de page de code, mais de surogates-pairs (et pas seulement pour le japonnais) : on utilise deux code UTF-16 pour codé un code-point Unicode... mais il n'y a pas de page de code, puisque l'on peut par exemple mélanger le japonais, le chinois et allez encore le coréen, tous les trois dans un même flux. Est-ce que tu peux faire cela dans ton esprit ? Si oui, alors tu n'utilise pas de page de code. Si non, alors tu utilise une page de code, et ce n'est pas de l'Unicode. Sous WinXP, on peut (et on devrait toujours), faire du japonnais ou du coréen sans page de code.

Attention : Code multi-byte ne signifie pas toujours Unicode. Attention à ne pas confondre les deux!

Ouil les interfaces OLE sont 32bits 100% Unicode , connection avec programmes VB ou Delphi par ex oblige

Waaw, tu me rassure Mat. Merci Au moins ça prouve que le noyau, même de Windows95 peut parfaitement supporter l'Unicode... c'est la GDI qui pêche. Je crois qu'ils ne se sont pas trop donné la peine de faire ce qu'il fallait... déjà que le 95 était sorti en retard, et le 98 pas mieux.. Parce qu'aprés tout, je le rappel, si Unicode semble bien fonctionner dans certains espaces d'affichage, il n'y a pas de raison qu'il ne fonctionne pas de la même manière dans tous les espaces d'affichage.

Ca sent le travail inachevé tout ça... du travail qui n'a été fait qu'à moitié chez MS.

Mat, tu as l'air d'être bien au vent et au fait du Multilingue : tu code des applis en japonnais ? Ca fait plaisir de voir quelqu'un qui est si bien dans le bain

Tu me dis aussi que Delphi est Unicode ? Je suis un peu surpris, parce que j'ai vu beaucoup d'applications Delphi qui ne l'était pas du tout.... mais bon, ne nous égarons pas, il s'agit ici de l'API Unicode de Windows et des manières de l'interfacer/pallier ses manquements.

Bon, alors à+ pour des nouvelles (je ne sais pas quand je le ferai, alors je ne promet pas de date... les personnes interessées peuvent toujours s'abonner à ce thread pour êtres tenues au courant).

[Hibou57]

Les tests promis ont été faits ce matin. Résultat : TextOutW ne fonctionne pas mieux.

Pire encore, je me suis renseigné, et ce que j'ai appris d'Unicows (MSLU) me laisse pantois : A la question à quoi sert MSLU, on trouve la réponse : Rien, Nada, Que Dal. Unicows est en fait inutile à 250%.

Unicows ne fait que convertire les chaîne Unicode en ... ANSI !!!

Ce n'est pas moi qui l'invente, je vous donne ce lien : Unicows.dll Removes Unicode

Je résume : Microsoft n'a jamais écrit que Unicows servait à faire de l'Unicode sur Win9x (même partiellement), et ceux/celles qui ont put le croire ne sont que des imbéciles. Comme ça, c'est simple ... et on peut dire que ce n'est pas se casser la tête.

La seule fonction d'Unicows et de permettre de faire une seule version d'une application, qui fonctionnera sous Win2000/XP et qui ne fonctionnera pas sous Win9x/Me. .... C'était vraiment pas le peine de la part de MS de faire tout ce cinéma pour ça.

Evidement je retire le tag résolu, et il faut tout reprendre de zéro. Unicows n'est pas une aide au support d'Unicode sous Win9x, il est simplement un moyen de distribuer plus facilement, sans avoir à les recompiler, des applications qui ne fonctionneront pas (on peut faire plus simple pour arriver au même résultat, mais il y en a qui n'ont que ça à faire).

Pfffff.....

Retour à la case départ

[Hibou57]

Suite...

J'ai vérifié que :

1. RegisterClassExA sans Unicows, fonctionne exactement comme RegisterClassExW avec Unicows.
   
2. CreateWindowExA sans Unicows, fonctionne exactement comme CreateWindowExW avec Unicows.
   
3. MessageBoxW sans Unicows, fonctionne exactement comme MessageBoxW avec Unicows.
   
4. TextOutW sans Unicows, fonctionne exactement comme TextOutW avec Unicows.

Pour les deux premiers, Unicows n'implémente finalement rien de plus, et pour les deux suivantes, Unicows n'amméliore absolument pas le comportement.

Ca se confirme : Unicows, c'est du vide et c'est du vent.

... et ils ont fait le release d'une DLL + une lib, et tout ça sous licence pour une blague pareille

S'cusez moi... mais je n'en reviens encore pas

Bon allez, y a du boulot à faire, parce que tout reste à faire... MS n'a rien foutu... ils nous refourguent tout le travail : on sera dédomagés pour avoir à combler leur feignasserie j'espère

.... à se demander à quoi ils servent

[Médinoc]

Ben, il faut dire que le nom est explicite:
Microsoft Layer for Unicode.
Une couche d'abstraction au-dessus des APIs non-unicode, quoi.

Mais je remarque que moi-même, je ne me suis pas posé la question et je compilais en ANSI sous 98...


À mon avis, tu n'as aucun moyen d'avoir de l'unicode dans les titres des fenêtres, sauf peut-être en les dessinant toi-même (limite caractère par caractère en choissant la codepage à chaque fois, mais ça risque d'être lent au possible...)