Python fonctionne très bien sous Windows-Core. Y compris Tk-inter. Cela
permet à Python d'être un des rares langages de script fonctionnant
pleinement dans cet environnement, avec un interface graphique.
L'installation se passe très bien, y compris pour les extensions pour
Windows. Mon serveur COM écrit en Python, fonctionne également.
Cela va ouvrir des horizons nouvelles à Python.
Mais, attention, tout ce qui fait appel à la partie graphique de
Windows, ou à dotNET, ne fonctionne pas.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry B.
--{ Méta-MCI (MVP) a plopé ceci: }--
pleinement dans cet environnement, avec un interface graphique.
et
Mais, attention, tout ce qui fait appel à la partie graphique de
Quelque chose m'échappe, là...
-- si je devais imprimer et te faire bouffer tout les postes ou on me soutiens que gimp vaut largement photoshop, tu en chierais du papier pendant un an.. --{ pipolin argumente dans fcol.debats }--
--{ Méta-MCI (MVP) a plopé ceci: }--
pleinement dans cet environnement, avec un interface graphique.
et
Mais, attention, tout ce qui fait appel à la partie graphique de
Quelque chose m'échappe, là...
--
si je devais imprimer et te faire bouffer tout les postes ou on me
soutiens que gimp vaut largement photoshop, tu en chierais du papier
pendant un an.. --{ pipolin argumente dans fcol.debats }--
pleinement dans cet environnement, avec un interface graphique.
et
Mais, attention, tout ce qui fait appel à la partie graphique de
Quelque chose m'échappe, là...
-- si je devais imprimer et te faire bouffer tout les postes ou on me soutiens que gimp vaut largement photoshop, tu en chierais du papier pendant un an.. --{ pipolin argumente dans fcol.debats }--
Méta-MCI \(MVP\)
Bonsoir !
La réponse est simple. Tk utilise son propre système graphique, sans tenir compte de celui de Windows. Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la couche graphique de Windows (entre autres éléments supprimés).
La corolaire, c'est que Python offre des possibilités dans un environnement où beaucoup d'autres langages sont impossibles à utiliser (à commencer par les langages comme C#, F#, VB.Net, ou même IronPython, car dotNET n'est pas inclus dans Core).
@-salutations -- Michel Claveau
Bonsoir !
La réponse est simple. Tk utilise son propre système graphique, sans
tenir compte de celui de Windows.
Du coup, ça fonctionne dans les installation "Core", malgré l'absence de
la couche graphique de Windows (entre autres éléments supprimés).
La corolaire, c'est que Python offre des possibilités dans un
environnement où beaucoup d'autres langages sont impossibles à utiliser
(à commencer par les langages comme C#, F#, VB.Net, ou même IronPython,
car dotNET n'est pas inclus dans Core).
La réponse est simple. Tk utilise son propre système graphique, sans tenir compte de celui de Windows. Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la couche graphique de Windows (entre autres éléments supprimés).
La corolaire, c'est que Python offre des possibilités dans un environnement où beaucoup d'autres langages sont impossibles à utiliser (à commencer par les langages comme C#, F#, VB.Net, ou même IronPython, car dotNET n'est pas inclus dans Core).
@-salutations -- Michel Claveau
Thierry B.
--{ Méta-MCI (MVP) a plopé ceci: }--
La réponse est simple. Tk utilise son propre système graphique, sans tenir compte de celui de Windows. Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la couche graphique de Windows (entre autres éléments supprimés).
Yep... Je comprend mieux, là :)
-- Si Lucky Luke est resté un cow boy solitaire et célibataire toute sa vie, c'est parce qu'y a des trucs qu'il aurait pas dû faire plus vite que son ombre... --{ http://www.bashfr.org/?6955 }--
--{ Méta-MCI (MVP) a plopé ceci: }--
La réponse est simple. Tk utilise son propre système graphique, sans
tenir compte de celui de Windows.
Du coup, ça fonctionne dans les installation "Core", malgré l'absence de
la couche graphique de Windows (entre autres éléments supprimés).
Yep... Je comprend mieux, là :)
--
Si Lucky Luke est resté un cow boy solitaire et célibataire
toute sa vie, c'est parce qu'y a des trucs qu'il aurait pas
dû faire plus vite que son ombre...
--{ http://www.bashfr.org/?6955 }--
La réponse est simple. Tk utilise son propre système graphique, sans tenir compte de celui de Windows. Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la couche graphique de Windows (entre autres éléments supprimés).
Yep... Je comprend mieux, là :)
-- Si Lucky Luke est resté un cow boy solitaire et célibataire toute sa vie, c'est parce qu'y a des trucs qu'il aurait pas dû faire plus vite que son ombre... --{ http://www.bashfr.org/?6955 }--
Amaury Forgeot d'Arc
Méta-MCI (MVP) a écrit :
Bonsoir !
La réponse est simple. Tk utilise son propre système graphique, sans tenir compte de celui de Windows. Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la couche graphique de Windows (entre autres éléments supprimés).
Je ne suis pas sûr de comprendre. De quel "système" s'agit-il ? Il me semble que Tk doit quand même utiliser l'API de Windows (CreateWindow, CreateLogFont, SendMessage...) pour afficher des fenêtres et des boutons.
Ou bien sait-il discuter directement avec l'écran ? (Comme au bon vieux temps du CGA à l'adresse 0xB800)
-- Amaury
Méta-MCI (MVP) a écrit :
Bonsoir !
La réponse est simple. Tk utilise son propre système graphique, sans
tenir compte de celui de Windows.
Du coup, ça fonctionne dans les installation "Core", malgré l'absence de
la couche graphique de Windows (entre autres éléments supprimés).
Je ne suis pas sûr de comprendre. De quel "système" s'agit-il ?
Il me semble que Tk doit quand même utiliser l'API de Windows
(CreateWindow, CreateLogFont, SendMessage...) pour afficher des fenêtres
et des boutons.
Ou bien sait-il discuter directement avec l'écran ? (Comme au bon vieux
temps du CGA à l'adresse 0xB800)
La réponse est simple. Tk utilise son propre système graphique, sans tenir compte de celui de Windows. Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la couche graphique de Windows (entre autres éléments supprimés).
Je ne suis pas sûr de comprendre. De quel "système" s'agit-il ? Il me semble que Tk doit quand même utiliser l'API de Windows (CreateWindow, CreateLogFont, SendMessage...) pour afficher des fenêtres et des boutons.
Ou bien sait-il discuter directement avec l'écran ? (Comme au bon vieux temps du CGA à l'adresse 0xB800)
-- Amaury
Pierre Maurette
Amaury Forgeot d'Arc, le 18/11/2008 a écrit :
Méta-MCI (MVP) a écrit :
Bonsoir !
La réponse est simple. Tk utilise son propre système graphique, sans tenir compte de celui de Windows. Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la couche graphique de Windows (entre autres éléments supprimés).
Je ne suis pas sûr de comprendre. De quel "système" s'agit-il ? Il me semble que Tk doit quand même utiliser l'API de Windows (CreateWindow, CreateLogFont, SendMessage...) pour afficher des fenêtres et des boutons.
Ou bien sait-il discuter directement avec l'écran ? (Comme au bon vieux temps du CGA à l'adresse 0xB800)
Non, quand même pas. Je n'ai jamais installé ni même manipulé Server 2008 Core. Mais si j'ai bien compris, c'est une installation particulière (une "distro" ?) de Server 2008. Et Server 2008, c'est une branche de Windows NT. Server 2008 Core reste donc un OS graphique fenêtré, mais minimaliste, dans le but peut-être de ne pas dégrader les performances, mais SURTOUT de diminuer la surface d'exposition aux vulnérabilités. Minimaliste, parce que des API comme dotNET ne sont pas installées, ni un grand nombre d'applicatifs. Dans cet environnement GRPAHIQUE, on travaillera dans des consoles, et parfois on lancera des clicodromes (notepad, regedit, ...).
-- Pierre Maurette
Amaury Forgeot d'Arc, le 18/11/2008 a écrit :
Méta-MCI (MVP) a écrit :
Bonsoir !
La réponse est simple. Tk utilise son propre système graphique, sans tenir
compte de celui de Windows.
Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la
couche graphique de Windows (entre autres éléments supprimés).
Je ne suis pas sûr de comprendre. De quel "système" s'agit-il ?
Il me semble que Tk doit quand même utiliser l'API de Windows
(CreateWindow, CreateLogFont, SendMessage...) pour afficher des fenêtres et
des boutons.
Ou bien sait-il discuter directement avec l'écran ? (Comme au bon vieux temps
du CGA à l'adresse 0xB800)
Non, quand même pas. Je n'ai jamais installé ni même manipulé Server
2008 Core. Mais si j'ai bien compris, c'est une installation
particulière (une "distro" ?) de Server 2008. Et Server 2008, c'est une
branche de Windows NT.
Server 2008 Core reste donc un OS graphique fenêtré, mais minimaliste,
dans le but peut-être de ne pas dégrader les performances, mais SURTOUT
de diminuer la surface d'exposition aux vulnérabilités. Minimaliste,
parce que des API comme dotNET ne sont pas installées, ni un grand
nombre d'applicatifs. Dans cet environnement GRPAHIQUE, on travaillera
dans des consoles, et parfois on lancera des clicodromes (notepad,
regedit, ...).
La réponse est simple. Tk utilise son propre système graphique, sans tenir compte de celui de Windows. Du coup, ça fonctionne dans les installation "Core", malgré l'absence de la couche graphique de Windows (entre autres éléments supprimés).
Je ne suis pas sûr de comprendre. De quel "système" s'agit-il ? Il me semble que Tk doit quand même utiliser l'API de Windows (CreateWindow, CreateLogFont, SendMessage...) pour afficher des fenêtres et des boutons.
Ou bien sait-il discuter directement avec l'écran ? (Comme au bon vieux temps du CGA à l'adresse 0xB800)
Non, quand même pas. Je n'ai jamais installé ni même manipulé Server 2008 Core. Mais si j'ai bien compris, c'est une installation particulière (une "distro" ?) de Server 2008. Et Server 2008, c'est une branche de Windows NT. Server 2008 Core reste donc un OS graphique fenêtré, mais minimaliste, dans le but peut-être de ne pas dégrader les performances, mais SURTOUT de diminuer la surface d'exposition aux vulnérabilités. Minimaliste, parce que des API comme dotNET ne sont pas installées, ni un grand nombre d'applicatifs. Dans cet environnement GRPAHIQUE, on travaillera dans des consoles, et parfois on lancera des clicodromes (notepad, regedit, ...).
-- Pierre Maurette
Méta-MCI \(MVP\)
Bonsoir !
C'est tout à fait ça !
Sauf que, selon moi, la "diminution de la surface d'attaque" n'est qu'un argument purement marketing.
Il y a un autre aspect intéressant : les ressources nécessaires sont réduites (256 Mo de RAM, 512 recommandé). Espace disque consommé assez faible. Besoins vidéo minimums. Et, avec des performances élevées ; je fais du transfert réseau (copie de fichiers de postes vers le serveur), dans un Core virtuel (Hyper-V), à plus de 11 Mo/s, et alors que la machine a deux autres serveurs (virtuels) en fonctionnement.
@-salutations -- Michel Claveau
Bonsoir !
C'est tout à fait ça !
Sauf que, selon moi, la "diminution de la surface d'attaque" n'est qu'un
argument purement marketing.
Il y a un autre aspect intéressant : les ressources nécessaires sont
réduites (256 Mo de RAM, 512 recommandé). Espace disque consommé assez
faible. Besoins vidéo minimums.
Et, avec des performances élevées ; je fais du transfert réseau (copie
de fichiers de postes vers le serveur), dans un Core virtuel (Hyper-V),
à plus de 11 Mo/s, et alors que la machine a deux autres serveurs
(virtuels) en fonctionnement.
Sauf que, selon moi, la "diminution de la surface d'attaque" n'est qu'un argument purement marketing.
Il y a un autre aspect intéressant : les ressources nécessaires sont réduites (256 Mo de RAM, 512 recommandé). Espace disque consommé assez faible. Besoins vidéo minimums. Et, avec des performances élevées ; je fais du transfert réseau (copie de fichiers de postes vers le serveur), dans un Core virtuel (Hyper-V), à plus de 11 Mo/s, et alors que la machine a deux autres serveurs (virtuels) en fonctionnement.
