Une partie du code source de Windows Vista a été dévoilé :
http://www.tux-planet.fr/mini-blog/?189-une-partie-du-code-s(...)
J'adore les bouts de code mit en commentaires :
//printf("Welcome to Windows 2000")
//printf("Welcome to Windows XP")
http://www.tux-planet.fr/mini-blog/?189-une-partie-du-code-s(...)
J'adore les bouts de code mit en commentaires :
//printf("Welcome to Windows 2000")
//printf("Welcome to Windows XP")
> Lire le journal (43 commentaires, moyenne: 3,7).
Vous avez demandé le commentaire #920710.
Run by 
Cette page a été générée par Templeet en 0.0748s (dont 0.0064 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Hungarian Style ...
Pour être un minimum crédible, tu aurais dû nommé tes variables selon la notation hongroise.
[+] [^]Re: Hungarian Style ...
Je ne suis pas l'auteur de cette image, on la trouve partout sur le net en ce moment.
Tux-planet
[^]Re: Hungarian Style ...
Avec les hideux :
DWORD, TCHAR, LPCWSTR, OLECHAR, BSTR, HRESULT, etc
Quelle horreur.
[^]Re: Hungarian Style ...
Sans oublier les prototypes avec une douzaine d'arguments (dont la moitié sont ignorés héritage du 16 bits), les conventions d'appels tordues. Les fonctions obscures mais utiles cachées au fin fond du MSDN (ie: DisableProcessWindowsGhosting), les changements de comportement non documentés.
La programmation Win32: que du bonheur (pour les vendeurs de perruques).
[^]Re: Hungarian Style ...
J'aime bien les API avec des arguments "reserved".
Ou les fonctions dont un paramètre doit avoir une valeur spécifique (à quoi sert ce paramètre ?).
Ou les structures où il faut y renseigner la taille de la structure.
Ou l'utilisation, jusqu'à l'écoeurement de COM, alors que bien souvent ça ne sert à rien et même parfois n'est pas supporté... Ceci dit COM ce n'est pas la merde. Mais l'usage systèmatique qu'en fait MS est ultra lourdingue.
Bénissons MS d'avoir fait de l'API de Windows une merde, sinon le logiciel libre ne pourrait pas concurrencer MS.
Ceci dit, j'ai trouvé une bonne API dans Windows : Direct3D. API certes compliquée, mais Direct3D est compliqué. Notons qu'avec Direct3D MS ne se fait pas chier avec la sacro-sainte compatibilité ascendante. Direct3D utilise COM mais tout est fait pour qu'on ne soit pas emmerdé avec COM.
M'enfin, les derniers trucs de MS ne sont pas pourris. Donc méfiance.
[^]Re: Hungarian Style ...
M'enfin, les derniers trucs de MS ne sont pas pourris.
Vista ?
[^]Re: Hungarian Style ...
.Net est pas trop pourri.
[^]Re: Hungarian Style ...
Commentaire pas souvent trouvé dans nos communautés...
+1
Ce message aurait très bien pu être au second degré.
[^]Re: Hungarian Style ...
> Vista ?
Bien vu.
Pour MS-OOXML, je ne trouve pas que c'est un truc nouveau. C'est les pourris vieux formats binaires casés à la va vite dans du XML.
Mais MS a fait .Net/C# qui n'est pas pourri. MS bosse sur Silverlight. Peut-être pas aussi bien que Flash, mais ne sera sûrement pas pourri. Il y a aussi Media Foundation qui va remplacer l'abominable DirectShow. Un remplaçant de pdf est dans les cartons.
Je crois qu'on aurait tord de croire que MS fait que des merdes.
M'enfin, sauf sous la contrainte, je n'utilise pas du MS.
[^]Re: Hungarian Style ...
J'aime bien les API avec des arguments "reserved".
Ou les fonctions dont un paramètre doit avoir une valeur spécifique (à quoi sert ce paramètre ?).
Ou les structures où il faut y renseigner la taille de la structure.
Tu sais que ces choses la ont une utilite mine de rien.
Structure ou il faut renseigner la taille de la structure :
Dans V1 la structure fait 32 bytes
Pour V2 t'as ajoute qqe elements, tu fais quoi ? un nouvel API ?
Non, tu ajoutes les nouveaux champs a la fin de la structure, et le champ "taille" te permet de savoir quelle struct tu recois. Si tu recois 32, c'est la V1, si tu recois 56 c'est la V2, ...
Ca te permet de faire evoluer l'API sans casser la signature.
Tu me diras, pourquoi ne pas mettre un champ "Version" plutot que taille ?
C'est simple en fait, il te suffit de faire un sizeof(bob) plutot que t'emmerder a savoir quelle version il faut entrer. Le jour ou tu compiles avec la version suivante ca sera tout bon aussi.
Idem pour les arguments "reserved", on fait pas ca juste pour le fun. On est d'ailleurs pas les seuls a faire cela hein, KDE et d'autres projets libre entre autre font cela aussi.
[^]Re: Hungarian Style ...
> Tu me diras, pourquoi ne pas mettre un champ "Version" plutot que taille ?
> C'est simple en fait, il te suffit de faire un sizeof(bob) plutot que t'emmerder a savoir quelle version il faut entrer. Le jour ou tu compiles avec la version suivante ca sera tout bon aussi.
C'est bien joli, mais c'est pas portable.
Ou alors faut utiliser des types non-natifs à la machine comme des uint32 et autres joyeusetés qui te font joliment sourire le jour ou tu compiles le code pour une archi 16 bits.
[^]Re: Hungarian Style ...
Si tu jettes un oeil a l'API Windows tu verras tres tres rarement des int, tu verras bcp de LONG, WORD, SHORT et DWORD par contre qui eux garantissent une taille specifique.
Quand aux archis 16bit, disons que c'est un peu depasse de nos jours...
[^]Re: Hungarian Style ...
> Pour V2 t'as ajoute qqe elements, tu fais quoi ? un nouvel API ?
Oui, une nouvelle API. Et c'est exactement ce que fait Direct3D. Ça te dérange ?
Et dans ce cas on ne mets pas la taille de la structure dans la structure.
On ajoute un champs "version". Mieux, on fait un init_struct(struct*).
> C'est simple en fait, il te suffit de faire un sizeof(bob) plutot que t'emmerder a savoir quelle version il faut entrer.
N'importe quoi. Si tu changes de structures, tu dois changer le nom de la structure (le type).
Et tu peux avoir un changement de version sans changement de taille.
Par exemple passer de
struct {char * user_name, etc}àstruct {user_t * user, etc}. C'est exactement la même taille, mais ça n'a rien à voir.Donc utiliser la taille d'une structure pour identifier une version d'API est une belle connerie (qu'heureusement pratiquement seul MS fait).
> Le jour ou tu compiles avec la version suivante ca sera tout bon aussi.
Pipo.
> On est d'ailleurs pas les seuls a faire cela hein, KDE et d'autres projets libre entre autre font cela aussi.
Des "reserved" dans une structure, je comprend très bien. Mais dans des appels de fonction je ne comprend pas ça.
Je doute grave que le libre ait l'habitude de mettre des paramètres en réserved.
En passant, KDE utilise C++. En C++ il y a la surchage et les paramètres par défaut. Pour les éléments "reserved" de structure, le C++ a des class (donc ce qui est réservé est en private).
Bref, tu dois pipoper... encore...
[^]Re: Hungarian Style ...
Oui, une nouvelle API. Et c'est exactement ce que fait Direct3D. Ça te dérange ?
Et dans ce cas on ne mets pas la taille de la structure dans la structure.
On ajoute un champs "version". Mieux, on fait un init_struct(struct*).
C'est une super methode ca, comme ca apres 5-10 ans tu te retrouves avec 4000 APIs qui se marchent sur les pieds, super design...
Tu sais, ca te ferait pas de mal d'avoir un petit peu d'humilite et de te demander pourquoi les gros groupes de dev (libre ou pas) font des trucs de ce genre.
Il serait possible que ce soit une technique efficace et eprouvee...
Des "reserved" dans une structure, je comprend très bien. Mais dans des appels de fonction je ne comprend pas ça.
Je doute grave que le libre ait l'habitude de mettre des paramètres en réserved.
En passant, KDE utilise C++. En C++ il y a la surchage et les paramètres par défaut. Pour les éléments "reserved" de structure, le C++ a des class (donc ce qui est réservé est en private).
Bref, tu dois pipoper... encore...
T'es lassant tu sais...
http://api.kde.org/3.5-api/kdelibs-apidocs/kdecore/html/clas(...)
Definition at line 1937 of file kurl.cpp.
void KURL::setQuery ( const QString & _txt,
int encoding_hint = 0
)
Sets the encoded query of the URL.
The query should start with a '?'. If it doesn't '?' is prepended.
Parameters:
_txt this is considered to be encoded. This has a good reason: the query may contain the '0' character
encoding_hint MIB of the encoding. Reserved, should be 0 . See QTextCodec::mibEnum()
Voila, ca te permettra peut-etre de sortir la tete du sable et voir la realite en face (et apprendre qqe techniques utiles).
[^]Re: Hungarian Style ...
Petit cadeau supplementaire :
http://library.gnome.org/devel/glib/stable/glib-File-Utiliti(...)
GDir* g_dir_open (const gchar *path,
guint flags,
GError **error);
Opens a directory for reading. The names of the files in the directory can then be retrieved using g_dir_read_name().
path : the path to the directory you are interested in. On Unix in the on-disk encoding. On Windows in UTF-8
flags : Currently must be set to 0. Reserved for future use.
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/ssl(...)
SECStatus NSS_NoDB_Init(char *reserved);Parameter
This function has the following parameter:reserved
Should be NULL..
etc...
[^]Re: Hungarian Style ...
J'aime bien les API avec des arguments "reserved".
Bah, ça c'est quand même un truc très courant, surtout quand tu fait une bibliothèque généraliste et que tu ne veux pas recompiler/relinker un gazillion d'applications quand tu "enhance" une des fonctions.
Ou les fonctions dont un paramètre doit avoir une valeur spécifique (à quoi sert ce paramètre ?).
Il servira le jour où ce paramètre aura le droit de prendre une ou plusieurs autre valeur. Toujours pour simplifier les futures phases d'évolution sans trop casser l'existant.
Il n'y a pas que la programmation jetable des applis web/php dans la vie, mais ça, tu est encore trop jeune pour le savoir. Pas d'inquiétude, ça vient avec l'age.
( Zzzzzzzzz... )
[^]Re: Hungarian Style ...
Faut vivre avec son époque.
Tu pourrais aussi faire tout les fonctions en (...) (nombre de paramètre variable).
> Il n'y a pas que la programmation jetable des applis web/php dans la vie
Il y a aussi l'édition de lien (c'est une pratique ultra courante dans le libre).
Il y a les paramètres par défaut. Il y a la surchage (même le C le fournit).
En C++ t'as aussi les namespaces pour gerer les versions.
Bref, il n'y a pas de raison de faire des trucs à la MS qui avait peut-être une justification en 1980 mais n'en ont aucune aujourd'hui.