Discussion :

[Hibou57]

Hello,

Chacun(e) de vous connais probablement la fameuse fonction RegisterClassEx (ou au moins RegisterClass). Il faut savoir que cette fonction se décline en deux versions concrètes dans l'API Windows(r) : une version Ansi (RegisterClassExA) et une version Unicode(tm) (RegisterClassExW). On ne le voit pas, parce que si on programme en C, alors ce sont des instructions du preprocesseur qui transforment automatiquement RegisterClassEx en la version concrête appropriée.

RegisterClassExA fonctionne trés bien chez moi (encore heureux .... ). Mais RegisterClassExW renvoie systèmatiquement 0, nul, nada, rien, zéro

Comme je suis sous Windows 98-SE, je me demandais s'il y avait des difficultées particulières sous ce système, avec cette fonction. Je suppose qu'elle est normalement implémantée, vu que la documentation de l'API Windows 95 (r) y fait référence... donc on peut penser que la fonction existe bien sous Windows 98...

Qu'en est-il ? Y at-il des gens qui ont eu des expériences à ce sujet ?

N.B-1 : MessageBoxW fonctionne tout à fait normalement...
N.B-2 : Je ne peux rien dire au sujet CreateWindowExW, vu que je ne peux même pas créer de classe, je n'ai pas put la tester encore...

[Mayti4]

RegisterWindowClassEx

RegisterClassEx tu veux dire ?

La version Unicode n'est pas implémentée sous 95/98/Me.

Tu dois utiliser la dll fournit dans MSLU (Microsoft Layer for Unicode).

Ici.

[Hibou57]

Une réponse si rapide, je ne m'y attendais pas!

Merci bien et beaucoup Mayti :p

Alors donc je doit lier mes programmes à cette DLL... et ce n'est donc pas une mise à jour des DLLs système de Windows ? Donc le programme que j'écrirai sous Windows 98 ne fonctionnera pas sous Windows 2000/XP sans cette DLL ?

Bon, quand j'aurai créé la librairie d'import et que j'aurai essayé de lier mon programme à cette DLL, je donnerai des nouvelles ici pour raconter comment ça se passe... this may be useful to some one else...

Et merci encore

P.S. C'est quand même étrange que MessageBoxW fonctionne pourtant bien... parce qu'aprés-tout, c'est pourtant bien une fenêtre Unicode finalement

[Mayti4]

Alors donc je doit lier mes programmes à cette DLL... et ce n'est donc pas une mise à jour des DLLs système de Windows ?

Non ce n'est pas une mise à jour.

Donc le programme que j'écrirai sous Windows 98 ne fonctionnera pas sous Windows 2000/XP sans cette DLL ?

Il fonctionnera, la dll sera chargé que sous 95/98/Me.

Bon, quand j'aurai créé la librairie d'import et que j'aurai essayé de lier mon programme à cette DLL

Elle existe déjà dans le SDK (en pièce jointe si tu ne l'as pas).

[Hibou57]

Merci pour la pièce jointe, je n'ai justement pas le sdk (pas possible sur mon poussif )... tu m'as fait gagné du temps

Il fonctionnera, la dll sera chargé que sous 95/98/Me.

Là, je ne comprends pas... parce que je dois lier mon programme à une librairie, et il ne peut pas y avoir deux définition pour RegisterClassExW. Le lieur prendra l'une ou l'autre, et le choix de la lib employé désignera automatiquement un dll pour cette liaison.

Je me demande si ce ne serait pas plus simple encore de bricoler User32.dll , pour qu'elle renvoie ses requêtes à RegisterClassW vers wincows.dll.. heuuu... unicows.dll ( ) je crois qu'on peut créer des dll d'interface qui ne font que dispatcher vers d'autres dll... il faudrait en fait une du genre.

Je dis peut-être une bétise... mais c'est ce qui me parrait le plus cohérent.

Mayti, tu es développeur(se) profesionel(le) ?

[Mayti4]

Là, je ne comprends pas... parce que je dois lier mon programme à une librairie, et il ne peut pas y avoir deux définition pour RegisterClassExW. Le lieur prendra l'une ou l'autre, et le choix de la lib employé désignera automatiquement un dll pour cette liaison.

unicows.lib contient un loader qui chargera unicows.dll que sous 95/98/Me.

Et c'est RegisterClassExW de MSLU que le linker prend logiquement.

Mayti, tu es développeur(se) profesionel(le) ?

Non.

[Hibou57]

Non.

Oui.



............
......................... merci, à+.... moi dodo maintenant... il est déjà si tard...
Bonne nuit à toi.

[Hibou57]

Mayti, la lib que tu donnais était refusé par le lieur (Gnat/gcc sous windows)... je la trouvais d'ailleurs enorme, 2MB, pour quelque chose qui est annoncé être léger sur le site de Microsoft.

J'en ai trouvé une autre version ici : http://libunicows.sourceforge.net/

Le problème maintenant, que le lieur veut bien la lier, c'est que plus rien ne marche... même MessageBoxW qui marchait parfaitement bien, ne fonctionne plus

[Hibou57]

Non-seulement ça ne marche pas, mais en plus il y a un problème de licence avec unicow.dll. Mais il existe une alternative, nomée Opencow : voir http://sourceforge.net/projects/opencow/ et http://opencow.sourceforge.net/

Reste à faire les testes et à prier pour que ça marche.

Quelqu'un(e) a déjà utilisé Unicow ou Opencow avec Gnat sous Windows ?

[Mayti4]

Mayti, la lib que tu donnais était refusé par le lieur (Gnat/gcc sous windows)... je la trouvais d'ailleurs enorme.

Les fichiers .lib sont utilisés par Visual C++.

Le problème maintenant, que le lieur veut bien la lier, c'est que plus rien ne marche...

Ne marche pas sous 98 ou sous XP ?

D'ailleurs si c'est juste pour une fonction, tu peux charger la dll toi même, sans devoir linker.

[Hibou57]

Ne marche pas sous 98 ou sous XP ?

Beh, sous 98... c'est parce que je suis sous 98 que j'ai besoin de unicows. Mais c'est important aussi que ça puisse fonctionner sous 2000/XP, si je décide de distribuer.

Ok, je dois charger la dll moi-même.... mais c'est bizzare quand même, je n'ai pas besoin de le faire avec les autres dll... et je ne suis pas certain que ce soit un problème de chargement, parce que sinon, ce serait comme si la dll n'était pas là, et tout fonctionnerait normalement.

Même MessageBoxA ne fonctionne plus ... et ce qui est étrange encore, c'est que quand je supprime la dll du rerpertoire de l'application, et que je la lance, je n'ai aucun message qui me dit qu'il manque une dll (comme cela se produit normalement en de telles circonstances).

Je donnerai des news, parce que ce topic est important quand même... le support d'unicode, c'est quand même pas rien... et sous 95/98/Me, c'est encore plus important.

à+

[Hibou57]

Bon, en résumé pour le moment, il existe deux versions de la DLL : celle de Microsoft, et celle du projet SourceForge, Opencow. Il existe deux versions de la lib : celle de du SDK Microsoft, et celle du projet SourceForge, LibUnicow.

Il y a quatre combinaisons possibles, et quelque soit cette combinaison, un programme de test en C, compilé avec GCC, abouti toujours à ...

A a causé une défaillance de page dans
le module KERNEL32.DLL à 018f:bff70003.
Registres :
EAX=bff70000 CS=018f EIP=bff70003 EFLGS=00010212
EBX=00530000 SS=0197 ESP=0073fd88 EBP=0073fd8f
ECX=00000000 DS=0197 ESI=815ed140 FS=3f27
EDX=004017ac ES=0197 EDI=00000000 GS=0000
Octets à CS : EIP :
00 03 00 00 00 04 00 00 00 ff ff 00 00 b8 00 00
État de la pile :
78004b0e 00000000 0073fda0 0040183f 815ed140 00530000 0073fe14 0040142b 0040202c 00000001 00000000 00402024 00000000 815ed140 0073fe14 0073fdd8

Seul varie en fonction de la combinaison, les valeurs des registres ESI et FS, ainsi que certains mots de l'état de la pile.

Les testes que j'avais fait avec Ada ne m'avaient rien montré... comme je n'y avait pas mis de gestionnaire d'exception, le programme se terminait sans plus d'informations.

Quelqu'un(e) at-il/elle déjà réussi à compilé avec GCC, un petit programme de test en C, utilisant Unicows, et qui fonctionne sans planter ? Si oui, alors ce serait sympa de donner le code, et les parètres donnés à la compilation.

Merci d'avance.

[Hibou57]

Avant de donner quelques infos : ça ne marche toujours pas, et j'ai toujours besoin de quelqu'un(e) qui aurait réussi à faire fonctionner une application quelqu'onque basé sur Unicows, et compilée/liée avec GCC.

Quelques notes

+ Il semble qu'il ne faille pas copier unicows.dll dans le repertoire système. J'ignore s'il y a une raison indéniable à cela... apparement ce serait pour éviter le fameux « dll hell » (le cauchemard des dll manquantes). Mais je n'y crois pas vraiment, parce que ce serait étonnant de s'attacher à éliminer une poussière dans l'immondice de ce problème effectivement bien réel (il y a surement bien plus à faire).

+ En passant de Windows 9X/Me à Windows 2000/XP, il semblerait que l'encodage Unicode passe de UCS-2 à UTF-16. Ca peut interesser du monde de le savoir.

+ Le problème d'Unicode se pose aussi pour l'accès à la base registre. (mais cela déborde du cadre de ce topic).

+ Question : y at-il des conflits/incompatibilités entre unicows et certaines solutions aternatives répondant à des besoins circonscrits/isolés ? Par exemple, une mise à jour de RichEdit supportant Unicode (version 2, 3, et 4, apportant chacune une prise en charge supplémentaire), interfère t-elle avec unicows ? (d'autres circonstances posant la même question, peuvent êtres imaginées).

[Médinoc]

+ En passant de Windows 9X/Me à Windows 2000/XP, il semblerait que l'encodage Unicode passe de UCS-2 à UTF-16. Ca peut interesser du monde de le savoir.

En effet, c'est bon à savoir (et c'est confirmé sur Wikipédia).

+ Le problème d'Unicode se pose aussi pour l'accès à la base registre. (mais cela déborde du cadre de ce topic).

Et t'as pas tout vu: J'ai déjà vu du texte unicode dans la base de registre... Avec une taille impaire...

[Hibou57]

J'ai fini par trouver un exemple de code d'essais. Il y en a un dans les sources d'OpenCow, tel qu'on peut les télécharger sur SourceForge.net

Effectivement, comme le disait Mayti, il faut explicitement chargé la dll (pour des raisons que j'ignore, et ce n'est même pas dit explicitement sur le site de Microsoft). Les librairies d'importation unicows.lib ou libunicows.a, ne contiennent pas le chargeur (contrairement à ce que les penser les documentations), mais un pointeur vers une fonction. Ce pointeur est une variable statique déclarée dans la librairie d'import. Ce pointeur doit être initialisé par l'application.

Voici un exemple en C... (pour les autres cas et autres compilateurs, voir ci-aprés)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
// La define de STDCALL, doit être adaptée à votre environnement
// de veloppement. Celle qui est donnée ici, correspond à GCC. Avec Borland
// vous pourrez essayer __stdcall (sauf erreur). Avec LCC, il me semble
// qu'il faut passer par une pragma (j'ai oublié, j'ai abandonné LCC pour
// des raisons de licence). Certains environnements définissent
// d'ailleur déjà cette macro.
//
// En compilant ce source, vous obtiendrez peut-être un message du genre
// « warning: `_PfnLoadUnicows' initialized and declared `extern' » de la part
// de votre compilateur. N'y pretez pas attention, c'est tout à fait normal,
// et il ne s'agit en aucun cas d'une erreur.

#define NULL ((void*)0)
#define STDCALL __attribute__((stdcall))
#define API extern STDCALL
typedef void* HMODULE;

API HMODULE LoadLibraryA(char* path);
API int MessageBoxA (void* owner, char* message, char* caption, int style);

static char* ErrorMessage =
	"Failed to load the Unicode API\n"
	"\n"
	"Check that either unicows.dll or opencaw.dll\n"
	"is present in the application directory.\n"
	"\n"
	"- You may get a copy of the original unicows.dll at\n"
	"http://www.microsoft.com/downloads/\n"
	"(type 'unicows.dll' in the search box)\n"
	"- You may get a copy of the opensource version opencow.dll at\n"
	"http://opencow.sourceforge.net/\n";
	
static char* ErrorTitle = "Unicode API Error";

HMODULE hUnicowsAPI = NULL;
HMODULE hOpencowAPI = NULL;

STDCALL HMODULE LoadUnicodeAPI (void)
{
    hUnicowsAPI = LoadLibraryA("unicows.dll");
	if (hUnicowsAPI != NULL) return hUnicowsAPI;
	else {
		hOpencowAPI = LoadLibraryA("opencow.dll");
		if (hOpencowAPI != NULL) return hOpencowAPI;
		else {
			MessageBoxA (NULL, ErrorMessage, ErrorTitle, 0);
			exit (-1);
		}
	}
}

extern HMODULE (STDCALL *_PfnLoadUnicows)(void) = &LoadUnicodeAPI;

Si vous utilisez un autre compilateur/lieur, il se peut que votre lieur ne prennent pas en charge l'initialisation de variables statiques exportées, ou que le langage que vous compilez ne permette pas de commander une telle initialisation (j'ignore par exemple si cela est possible en Ada).

Pour remédiez à cela, je vous propose un fichier objet, que vous pourrez lier à votre projet, et qui s'occupe de charger l'API Unicows (alias MSUL). Ce fichier doit être intégré à votre projet, en prennent soins de le placer avant la librarie d'importation unicows/opencow.

Ce fichier objet est issu de la compilation du code précédement donné en exemple.

Deux choses à noter au sujet de ce code : il exporte deux variable, hUnicowsAPI et hOpencowAPI, que vous pouvez lire, en déclarant l'importation de ces deux variables (de la manière qui convient au langage de programmation que vous utilisez). Comme il y a deux possibilité pour le layer unicode (voir dans les topics précédent), il y a une variable pour unicows, et une variable pour opencow. Si l'une est affecté, l'autre reste vide. Vous pouvez ainsi, en plus d'avoir un accés à la DLL, savoir qu'elle version à été chargé. Le procédure tente d'abord de charger Unicows.dll, puis si Unicows.dll n'est pas trouvé ou est érronné, alors la procédure tente de charger Opencow.dll. Noter bien l'ordre dans lequel cela est fait.

Si c'est nécéssaire sous votre configuration, n'oubliez d'éventuellement renomer le fichier *.o en *.obj

Laisser vos messages ici, si vous avez la moindre difficulté ou si vous trouvez des erreurs.

Note : On écrit Unicows, avec un « s », mais on écrit Opencow, sans « s ». (j'ai personnelement le reflexe d'écrire opencows, de manière érronée donc)

Edit (16/07/2006 19h35) : correction d'une erreur lamentable (et dont j'ai honte)... des déclarations locales masquaient des déclarations globales...

[Hibou57]

Détail accessoire : en utilisant un chargeur dans un fichier objet, il peut y avoir un conflit de définition. Quand on déclare une variable externe en l'initialisant, il semble que le compilateur cré un instance de la variable, dans le fichier objet. Avec un programme C compilé/lié avec GCC, on peut donner l'ordre exact à la ligne de commande. Mais sous Gnat par exemple, le lieur (qui est pourtant celui de GCC), me dit qu'il y a un conflit entre les deux définitions de _PfnLoadUnicows

[Médinoc]

Mais le chargeur est-il nécessaire dès le début de l'application ?
Ou bien, par exemple, lors du premier appel d'une fonction unicode ?

Si l'appel du chargeur peut être retardé suffisamment pour permettre une initialisation manuelle, cela pourrait être la solution...

[Hibou57]

Bonne question Medinoc

Tout d'abord, je fais notez que le chargeur fonctionne, et l'API Unicows également, c'est seulement dans certains environnement de developpement qu'il peut se produire un problème à l'étape de la liaison (et ce problème posé à la liaison est générique... il n'est même pas spécifique au chargeur Unicows)

Je m'étais aussi posé cette question, et il faut reconnaître qu'il est préférable je pense que cette initialisation se fasse immédiatement (Unicows correspond quand même au final à l'API Windows, dont il corrige certaines non-implémentations... et toutes applications est suposées avoir au démarrage, accès à une API fonctionelle, ... c'est la moindre des choses). Imagine par exemple que tu utilise des modules sur lesquels tu n'a pas de controle (dll, autre fichier objets, etc), et que ces modules fassent appel à des fonctions et procédures basées sur Unicode (c'est possible si par exemple ces fichiers objets ou dll viennent d'un environnement ou Unicode est totalement implémenté). Alors dans ce cas, il faut bien que le chargement d'Unicows soit la première initialisation effectuée par l'application.

Effectivement, dans beaucoup de cas, on pourra diférer l'initialisation (et par exemple avoir dans la procédure principale de mon application Ada, un appel explicite à la routine de chargement de Unicows)... mais ce serait adopter une solution dont on sait pertinement qu'elle aboutit à un echec dans certains cas... et à mes yeux, ce serait du bricolage, parce que serait comme laisser un bug dont on connait la cause et l'existance, en ayant pour seule solution de conseiller de ne pas créer d'applications qui pourraient déclencher ce bug. pffff... ce serait pas génial

Et de plus, ce problème qui se pose à la liaison étant générique, le résoudre, serait apporter une solution à tous un tas d'autres problèmes similaires... mais la solution est au cas par cas, puisqu'elle dépend du compilateur et du lieur (surtout du lieur). Et justement par exemple, j'ai posé le problème de manière plus spécifique dans le forum Ada, au sujet de Gnat.

[Hibou57]

Petites informations : l'ensemble {chargeur, libunicows.a, unicows.dll} fonctionne trés bien avec une programme C compilé avec GCC. Etrangement, pour des raisons que j'ignore (peut-être la runtime de Gnat jout-elle un rôle dans ce phénomène), cela ne fonctionne pas du tout pour un programme Ada compilé avec Gnat (pourtant lui même basé sur ce même GCC). Avec Gnat, seul fonctionnent soit l'un des ensembles {chargeur, unicows.lib, unicows.dll} ou {unicows.lib, unicows.dll} (unicows.lib, intégrant un chargeur, il n'est plus nécéssaire d'employer celui que j'indiquais pour être utilisé avec libunicows.a).

Important : pour utiliser unicows.lib avec Gnat, qui est basé sur gcc, vous devrez la renommer en ... libunicows.a (attention alors à ne pas les confondre... mais on les distingue facilement par la taille : la lib de Microsoft fait environ 2M et l'autre seulement environ 240K)

Rappel : unicows.lib, tel que founie par Mayti est fournie avec le SDK de Microsoft (mais heureusement que Mayti l'a posté ici, parce que sans ça, je n'aurais pas put)... et libunicows.a est une autre librairie totalement différente. Je suppose que libunicows.a fonctionne aussi avec opencow.dll

C'est quand même étrange que l'on ne trouve toujours que les lib et les dll séparément, sans jamais êtres appariées

Edit (16/07/2006 19h54) : contrairement à que je disais, il ne faut pas renomer unicows.lib de Microsoft en libunicows.a. Il faut employer la véritable librairie libunicows.a (liens fourni dans un précédent post). Il y a peut-être un moyen d'utiliser quand même unicows.lib avec le lieur de gcc, mais j'ignore comment et si c'est vraiment possible.

[Hibou57]

Fausse joie... en fait s'il n'y a plus l'erreur du lieur en utilisant unicows.lib aprés l'avoir renomée en libunicows.a, c'est parce que le lieur l'ignore sans le signaler (il ne reconnait effectivement pas le format de la lib, qui est pourtant aussi une archive)... j'ai la certitude que la lib n'est pas lié : Et si j'utilise le libunicows.a original, la liaison se fait effectivement, mais j'ai une erreur d'execution.

pfffff... il est vraiment impossible d'intégrer Unicows à Gnat ?