MinGW : c’est sensé être sérieux ?

Auteur	Message
Hibou Administrateur	En lisant la référence pour les fichiers WAVE multicanaux (qui vont au delà de la simple stéréo), ont peut voir ceci : Code : `DEFINE_GUIDSTRUCT("00000001-0000-0010-8000-00aa00389b71",` `KSDATAFORMAT_SUBTYPE_PCM);` Comme les fichiers WAVE sont évidemment lisibles partout, pas seulement sur Windows (le format DLS pour les synthétiseurs MIDI en est un exemple), il est pertinent de savoir à quoi cela correspond en terme de représentation de données et de données elles‑mêmes. En cherchant sur le web, on peut arriver à des fichiers d’entête de MinGW, dont un définit la macro en question. En voici une source directement accessible depuis un navigateur : include/codecapi.h (android.googlesource.com). Ce fichier comme tous les autres, est affirmé être sans aucune garantie et il y effectivement de quoi, comme ce sera vu juste après. La définition qui y est donnée est celle‑ci (pour le C) : Code : `define` `DEFINE_GUIDSTRUCT(g,` `n)` `DEFINE_GUIDEX(n)` Immédiatement, quelque chose interpelle : la macro a deux paramètres, mais un seul est utilisé dans sa résolution. Pourtant, ce paramètre g, est très important, c’est la représentation du GUID sous forme d’une chaîne de caractère, ce qui n’est qu’une représentation textuelle, pas celle utilisé dans les structure de données. Donc, un paramètre important est omis, et ça fait se demander comment cette macro peut faire ce qu’elle est sensée faire, à moins de faire de la magie. En cherchant cette fois à connaître la définition de cette macro, uniquement d’après les fichiers de Microsoft, on trouve quelque chose de plus cohérent. Une source accessible pour le fichier d’entêtes concerné, est : shared/ks.h (github.com) ou un autre exemple : shared/ks.h (github.com). Voici la définition qu’on y trouve : Code : `#define` `DEFINE_GUIDSTRUCT(g,` `n)` `struct` `__declspec(uuid(g))` `n` C’est déjà plus cohérent, même s’il reste à connaître comment se résoud uuid(g), au moins le paramètre g ne disparaît pas sans raison. Quelle confiance peut‑on faire aux fichiers d’entêtes de MinGW ? Eux qui se prétendent plus fiables, plus responsables et plus honnêtes que Microsoft. La page d’accueil de MingW présente des liens en rapport, dont celui pour ReactOS. Le lien n’est volontairement pas donné pour ne pas en faire la publicité. Sur cette page, on peut lire ceci : Citation : Imagine running your favorite Windows applications and drivers in an open-source environment you can trust. That's the mission of ReactOS! En dehors du mot open-source et de son baratin idéologique censé activer des réflexes conditionné, il est question de confiance. Pourtant ce produit repose sur WinGW, qui ne peut pas être fiable, comme prouvé plus haut. En bas de la page, on peut d’ailleurs lire : Citation : For the latest features and bugfixes, try our nightly builds. … de la part de gens qui moquent copieusement Windows parce qu’il a parfois des bugs (j’ai personnellement connu un bug de ReactOS que personne n’aurait excusé de la part de Windows et jamais vu une telle bourde sur Windows). Bref, les sources de MinGW sont à éviter, mieux vaut encore aller aux vraies sources, celles de Microsoft, qui sont sûrement plus fiables. Ceci dit, Microsoft n’est pas irréprochable non‑plus dans ce contexte, iels ne sont pas les derniers à faire du baratinage auto‑contradictoire. Quelqu’un un jour cherchait les entêtes des API de Windows, pour utiliser quelques interfaces dans un autre contexte. Iel trouvait que le téléchargement du SDK, qui fait plus d’un giga octets non‑installés, encore bien plus installé, est une quantité démesurée quand on cherche seulement si peu (tout à fait d’accord), et avec tout son bon sens, se demandait s’il est possible d’accéder à seulement les quelques fichiers pertinents : Windows SDK, Provide a direct way to download Header files (Ex: Windows.h) and allow the redistribution of the Header Files (learn.microsoft.com). La réponse qui lui est donnée est en gros que c’est impossible, à la fois pour des raisons techniques et des raisons légales. Les deux prétexte sont du baratin. La raison soit‑disant technique, est que même si on choisi une version de Windows approprié, il suffit que la version de Windows ciblée change d’une poussière dans son numéro de version, pour que plus rien ne soit utilisable. C’est évidemment un exemple de mauvaise fois, puisqu’on peut toujours faire marcher sur Windows, des applications ancienne de 20 ans ou environ (cela ne fait pas si longtemps qu’on ne peut plus y faire fonctionner les applications de Windows 3.1). La question légale est là on ne fait pas pourquoi, si c’est pour faire peur, l’intérêt n’est pas claire. En tous les cas, les interfaces ne sont pas brevetables, en tous cas pas dans l’UE ni ailleurs je crois (il y a une tentative de breveter l’interface Java, qui a échoué, pour des raisons de droits), et réutiliser des définitions de mise en ordre des octets ou des valeurs numérique pour rendre deux choses interopérables, n’a jamais été un délit. Ceci dit, il ne faut en effet pas redistribuer les entêtes de Windows sans autorisation, mais ça n’empêche pas d’utiliser les définition qu’on y trouve. Une preuve que la réponse qui lui a été donnée est de mauvaise fois, est que deux dépôts sur GitHub en les rendre lisibles en lignes (il y a probablement d’autres dépôts de ce genre et même ailleurs sur le web) et GitHub appartient à Microsoft depuis au moins cinq ans (achat annoncé en 2018, effectif en 2019, et considéré comme confirmé en 2025, sans savoir ce que cette confirmation signifie, comme ça l’était en 2019). Bref, le monde des baratineurs fatigue, autant le baratin de Microsoft que des anti‑Microsoft, quoique ces derniers me semblent les pires, et pour des raisons de fiabilités, quand une information technique pour une interface ou des définitions de données, etc, est nécessaire, mieux vaut se fier aux sources provenant de Microsoft qu’à celle des anti‑Microsoft. Honnêtement, la macro dont il était question, comment peut‑elle simplement fonctionner ? Et combien de cas comme celui‑ci ? S’il faut y aller en se disant qu’il faudra chercher les incohérences, mieux vaut éviter.

Auteur

Message

En lisant la référence pour les fichiers WAVE multicanaux (qui vont au delà de la simple stéréo), ont peut voir ceci :

Code :

DEFINE_GUIDSTRUCT("00000001-0000-0010-8000-00aa00389b71",
KSDATAFORMAT_SUBTYPE_PCM);

Comme les fichiers WAVE sont évidemment lisibles partout, pas seulement sur Windows (le format DLS pour les synthétiseurs MIDI en est un exemple), il est pertinent de savoir à quoi cela correspond en terme de représentation de données et de données elles‑mêmes.

En cherchant sur le web, on peut arriver à des fichiers d’entête de MinGW, dont un définit la macro en question. En voici une source directement accessible depuis un navigateur : include/codecapi.h (android.googlesource.com). Ce fichier comme tous les autres, est affirmé être sans aucune garantie et il y effectivement de quoi, comme ce sera vu juste après.

La définition qui y est donnée est celle‑ci (pour le C) :

Code :

define DEFINE_GUIDSTRUCT(g, n) DEFINE_GUIDEX(n)

Immédiatement, quelque chose interpelle : la macro a deux paramètres, mais un seul est utilisé dans sa résolution. Pourtant, ce paramètre g, est très important, c’est la représentation du GUID sous forme d’une chaîne de caractère, ce qui n’est qu’une représentation textuelle, pas celle utilisé dans les structure de données. Donc, un paramètre important est omis, et ça fait se demander comment cette macro peut faire ce qu’elle est sensée faire, à moins de faire de la magie.

En cherchant cette fois à connaître la définition de cette macro, uniquement d’après les fichiers de Microsoft, on trouve quelque chose de plus cohérent. Une source accessible pour le fichier d’entêtes concerné, est : shared/ks.h (github.com) ou un autre exemple : shared/ks.h (github.com).

Voici la définition qu’on y trouve :

Code :

#define DEFINE_GUIDSTRUCT(g, n) struct __declspec(uuid(g)) n

C’est déjà plus cohérent, même s’il reste à connaître comment se résoud uuid(g), au moins le paramètre g ne disparaît pas sans raison.

Quelle confiance peut‑on faire aux fichiers d’entêtes de MinGW ? Eux qui se prétendent plus fiables, plus responsables et plus honnêtes que Microsoft. La page d’accueil de MingW présente des liens en rapport, dont celui pour ReactOS. Le lien n’est volontairement pas donné pour ne pas en faire la publicité. Sur cette page, on peut lire ceci :

Citation :

Imagine running your favorite Windows applications and drivers in an open-source environment you can trust.
That's the mission of ReactOS!

En dehors du mot open-source et de son baratin idéologique censé activer des réflexes conditionné, il est question de confiance. Pourtant ce produit repose sur WinGW, qui ne peut pas être fiable, comme prouvé plus haut. En bas de la page, on peut d’ailleurs lire :

Citation :

For the latest features and bugfixes, try our nightly builds.

… de la part de gens qui moquent copieusement Windows parce qu’il a parfois des bugs (j’ai personnellement connu un bug de ReactOS que personne n’aurait excusé de la part de Windows et jamais vu une telle bourde sur Windows).

Bref, les sources de MinGW sont à éviter, mieux vaut encore aller aux vraies sources, celles de Microsoft, qui sont sûrement plus fiables.

Ceci dit, Microsoft n’est pas irréprochable non‑plus dans ce contexte, iels ne sont pas les derniers à faire du baratinage auto‑contradictoire. Quelqu’un un jour cherchait les entêtes des API de Windows, pour utiliser quelques interfaces dans un autre contexte. Iel trouvait que le téléchargement du SDK, qui fait plus d’un giga octets non‑installés, encore bien plus installé, est une quantité démesurée quand on cherche seulement si peu (tout à fait d’accord), et avec tout son bon sens, se demandait s’il est possible d’accéder à seulement les quelques fichiers pertinents : Windows SDK, Provide a direct way to download Header files (Ex: Windows.h) and allow the redistribution of the Header Files (learn.microsoft.com).

La réponse qui lui est donnée est en gros que c’est impossible, à la fois pour des raisons techniques et des raisons légales. Les deux prétexte sont du baratin. La raison soit‑disant technique, est que même si on choisi une version de Windows approprié, il suffit que la version de Windows ciblée change d’une poussière dans son numéro de version, pour que plus rien ne soit utilisable. C’est évidemment un exemple de mauvaise fois, puisqu’on peut toujours faire marcher sur Windows, des applications ancienne de 20 ans ou environ (cela ne fait pas si longtemps qu’on ne peut plus y faire fonctionner les applications de Windows 3.1). La question légale est là on ne fait pas pourquoi, si c’est pour faire peur, l’intérêt n’est pas claire. En tous les cas, les interfaces ne sont pas brevetables, en tous cas pas dans l’UE ni ailleurs je crois (il y a une tentative de breveter l’interface Java, qui a échoué, pour des raisons de droits), et réutiliser des définitions de mise en ordre des octets ou des valeurs numérique pour rendre deux choses interopérables, n’a jamais été un délit. Ceci dit, il ne faut en effet pas redistribuer les entêtes de Windows sans autorisation, mais ça n’empêche pas d’utiliser les définition qu’on y trouve. Une preuve que la réponse qui lui a été donnée est de mauvaise fois, est que deux dépôts sur GitHub en les rendre lisibles en lignes (il y a probablement d’autres dépôts de ce genre et même ailleurs sur le web) et GitHub appartient à Microsoft depuis au moins cinq ans (achat annoncé en 2018, effectif en 2019, et considéré comme confirmé en 2025, sans savoir ce que cette confirmation signifie, comme ça l’était en 2019).

Bref, le monde des baratineurs fatigue, autant le baratin de Microsoft que des anti‑Microsoft, quoique ces derniers me semblent les pires, et pour des raisons de fiabilités, quand une information technique pour une interface ou des définitions de données, etc, est nécessaire, mieux vaut se fier aux sources provenant de Microsoft qu’à celle des anti‑Microsoft. Honnêtement, la macro dont il était question, comment peut‑elle simplement fonctionner ? Et combien de cas comme celui‑ci ? S’il faut y aller en se disant qu’il faudra chercher les incohérences, mieux vaut éviter.