Le magazine Obligement publie aujourd’hui une entrevue avec Trevor Dickinson, le patron d’A-EON Technology.
Trevor fait le bilan de l’aventure AmigaOne X1000 et détaille son nouveau projet, Cyrus.
Site Internet : http://obligement.free.fr/articles/itwdickinson2.php
59 Commentaires
Passer au formulaire de commentaire
Super article! Merci.
Tu l’as rencontré ou bien ça s’est passé par échanges de courriels ?
On apprend comme cala etait prevu que le cout du x2000 risque de faire mal au fion dommage si vraiment passioné seul une minorité dans la minorité en profitera
Auteur
LTAC : j’avais rendez-vous avec M. Dickinson dans un petit coin sombre de banlieue, tard le soir. Une fois attrapé, nous avons (moi et ma bande de voyous) emmené M. Dickinson dans un lieu sûr. Ses yeux étaient évidemment bandés.
Une fois sur place, l’interogatoire a pu commencer. Le matériel pour faire parler les durs à cuir était en place…
Sinon, euh non, j’ai juste envoyé un courriel 🙂
@daff
La photo tout en bas de l’interview, tu aurais pu mettre « Trevor avec ACube et Cloanto » 🙂
et elwood ! faut pas gacher !
lol
Très intéressante interview. J’aimerai bien savoir de quel matériel pour classic il veut parler …
Auteur
Elwood : c’est fait (j’avais un doute sur l’identitié de la demaoiseille)
Daff: qu’est ce donc une damaoiseille? Une sorte de plante? Une fleur d’été? Un psychotrope? 🙂
/me est d’humeur bien joyeuse aujourd’hui. Les psychotropes peut être? 😀
Il a l’air motivé, mais est-ce que tout ceci est viable ? Si j’ai bien compris, il a perdu beaucoup d’argent avec le X1000 ?
Il le dit lui même que le X1000 n’était « commercialement parlant » pas viable.
Je pense qu’il en est probablement de même pour le X2000 mais qu’il a assuré (financièrement) ses arrières pour y arriver …
Oui il a gagné au loto !!!!
@Daff
c’est la serveuse 🙂 Très souriante et en forme 🙂
Va savoir :p
Il est peut-être rentier
Ou alors … il y a eu « levée de fonds occultes » :p MDR
Auteur
Il travaille tout simplement. Et en plus dans un secteur (pétrole) qui n’a jamais autant générer de revenus…
Tu l’as eu où cette information Daff ?
je me souviens en effet qu’il se soit présenté tout au début comme étant un homme d’affaire. Un vrai businessman passionné de l’Amiga.
Moi, je l’admire pour son courage et son investissement dans notre communauté.
Je regrette que tous les acteurs importants de notre communauté n’aient pas la classe de cet homme.
Moi je regrette qu’ils soient tous drivés par la nostalgie… Et qu’il n’y en ait pas un qui arrive pour enlever toute cette poussière: « allez, hop! on dégage exec et compagnie. On repart de zéro, le X1000 on va l’exploiter correctement! »
Quitte à perdre de l’argent, autant faire un truc sympa et sans se limiter…
Auteur
Daff : on est des vieux potes 🙂
Leo ouais quitte a voir une machine correcte autant reecrire la base 8)
@craf: ça ça serait ambitieux…
Oui Leo, mais si on fait table rase de ce qui a fait que l’Amiga a été ce qu’il était, n’y aurait-il pas un risque que l’on se perde dans quelque chose de nouveau qui n’aurait plus rien à voir avec l’Amiga ?
Parce que l’aspect utilisateur c’est une chose, Changer, retirer exec et le reste ne changera pas l’expérience utilisateur mais, l’aspect programmeur ?
Si on changeait tout et qu’on se retrouvait avec un OS *exotique* … Quels sont ceux d’entre nous qui se seraient vraiment intéréssé par programmer sur cet OS qui ne serait plus complètement Amiga ? Et surtout, qui ne se programmerait plus comme un Amiga …
[Contenu supprime a la demande de son auteur]
Faut savoir se moderniser tous les Os le font il ny a que l Amiga qui traine ses tares depuis bientôt trop longtemps plus ça va moins ça m intéressé et je me dis que rien ne vaut un bon classic …
Trevor , le Jay Miner ou le David Haynie des NG ? 🙂
[quote]
Oui Leo, mais si on fait table rase de ce qui a fait que l’Amiga a été ce qu’il était
[/quote]
Pourquoi ? Et est-ce que c’est pas aussi l’occasion de définir de nouvelles choses qui feraient « Amiga » ? Pourquoi toujours regarder vers le passé ?
L’aspect programmeur ? Forcément certaines choses changeront: plus de message par référence, etc… Pour le reste, qu’est-ce qui empêche d’avoir un nouveau truc à la MUI ? etc… rien… rien du tout.
Mais de toutes façons: OpenGL, c’est Amiga ? Ca ne l’a jamais été, pourtant tous les softs 3D sont entièrement codés avec et ne font quasiment pas appel aux API Amiga… Je n’ai pas l’impression que ça ait dérangé les développeurs… SDL: c’est Amiga ? etc…
Moi je préférerai qu’on voit de l’avant, plutôt que de regarder le passé sans arrêt. Lancer des applications 68000 de manière transparente, je m’en fous…
Forcémenent, certains aspects seront perdus… Mais il ne vaut mieux pas regarder ce qu’on gagnerait plutôt que ce qu’on y perdrait ?
C’était très bien il y a 30 ans… Mais maintenant il y a trop de limites liés à son âge. Et c’est pareil pour le hardware.
Leo, je comprends ton raisonnement mais je n’en vois pas l’utilité réelle ni l’intêret (en application au développement de l’OS). Je trouve que l’AmigaOS4, MorphOS évoluent à leur façon. Certes ce n’est peut-être pas exactement ce que j’aurais *choisi personnellement* mais ces évolutions sont tout de même appréciables je trouve…
Après, parlons API. OpenGL tape dans Warp3D. Warp3D c’est une API Purement Amiga et qui tape dans le hardware (pour certaines choses uniquement, ça n’a jamais été, à mon point de vue, totalement fini).
Et, personnellement, je ne vois pas en quoi l’API est un frein à l’évolution de l’Amiga ? Elle n’est utile qu’aux programmeurs, l’utilisateur final n’en connaîtra probablement rien …
Parlons MUI … Il s’agit d’une interface graphique MUI .. Rien à voir avec l’API ou ce qui est interne à l’OS … Certes MUI c’est « une » API (Interface de programmation avancée) mais c’est une couche qui peux très bien s’ajouter sur l’OS sans en changer les fondements internes…
Pour OpenGL, il s’agit d’un standard disponible partout. Ce n’est pas « PC » ni « Linux » mais c’est dispo partout… Refaire entièrement la roue pour la 3D … ça aurait été une perte de temps considérable et, on n’aurait probablement à ce jour, toujours pas de 3D … Donc, en ce sens, c’est pratique. Ca permet du portage et c’est une interface robuste et complète et qui a fait ses preuves :p
Maintenant, effectivement, niveau hardware c’est limité mais le X1000 est techniquement un « pas en avant », même si c’est pas le « top » de ce qui se fait, on évolue … Il est pas utilisé à fond ? Pas grave, Hyperion continue de bosser dessus … tant qu’on a pas de « project cancelled », on peux espérer que ça évolue (même si ça nous plait pas c’est déjà mieux que rien) …
Après, on pourrait encore dire PowerPC, x86, etc … C’est un débat dans lequel je ne rentrerais pas si ce n’est un détail … les Power PC émettent beaucoup moins d’ondes électromagnétiques que les X86, etc … Résultat, je ne me plaindrait pas (avec ma pathologie) qu’on soit sur PowerPC plutôt que x86, etc..
Après, on pourrait en discuter 50 ans, ce sont nos points de vue qui sont différents… Mais je comprends que la vision d’une personne ne soit pas celle d’un autre, c’est « le jeu ma pauv’ lucette » comme dirait la pub :p
[quote]
Je trouve que l’AmigaOS4, MorphOS évoluent à leur façon. Certes ce n’est peut-être pas exactement ce que j’aurais *choisi personnellement* mais ces évolutions sont tout de même appréciables je trouve…
[/quote]
Oui. Simplement il y a des limites liées à l’architecture de l’OS qui perdurent. Et perdureront tout le temps. Je ne citerai pas la liste pour la 50ème fois. Donc sachant qu’elles seront de plus en plus pénalisantes (le multicore, il y a 10-15 ans n’était pas omniprésent comme maintenant, idem pour le 64bit,…). Partant de là, je ne comprends pas pourquoi on continue dans cette direction.
Après, personnellement je trouverai super intéressant de travailler sur un nouvel OS, sans limite, avec feuille blanche… Tout en ayant en tête ce qui faisait de l’Amiga… l’Amiga.
[ quote=leo]Oui. Simplement il y a des limites liées à l’architecture de l’OS qui perdurent.[/quote]
Ben … je vois pas là … Windows qui est à jour niveau technologie fonctionne en interne à partir de DLL ( Dynamic Link Library ).
DirectX est un système de DLL, Direct3D, DirectPLAY aussi …
Les pilotes graphiques fonctionnent par librairies .DLL
Amiga OS 4 (et les anciens) fonctionnent par des .library (fichier de fonctions). C’est sensiblement la même chose.
Après, peut-être que la gestion de mémoire (sans protection mémoire) c’est la loose … Mais changer cela ne nécessiterait pas forcément de revoir entièrement l’OS….
Après peut-être parles-tu à un autre niveau … mais là … je ne vois pas … je suis programmeur mais pas programmeur expert donc je ne vois pas tout … mais je dois avouer que là … je vois pas …
Si, tu as un lien où c’est déjà exposé, à la limite, pourrais-tu le partager, cela me permettra de retrouver les informations et de mieux comprendre ce qui bloque :p
Après, comme toi, je trouverais hyper intéressant de bosser sur un OS mais … cela prendrait des années à se réaliser …
@+
[quote]
Ben … je vois pas là … Windows qui est à jour niveau technologie fonctionne en interne à partir de DLL ( Dynamic Link Library ).
[/quote]
Je n’ai pas lu la suite: on parle de l’Amiga… Les autres systèmes ont certainement d’autres problèmes, mais changent, régulièrement: DOS -> Win9x – > NT, MacOS Classic -> OSX, etc…
[quote]
Après, peut-être que la gestion de mémoire (sans protection mémoire) c’est la loose … Mais changer cela ne nécessiterait pas forcément de revoir entièrement l’OS….
Après peut-être parles-tu à un autre niveau … mais là … je ne vois pas … je suis programmeur mais pas programmeur expert donc je ne vois pas tout … mais je dois avouer que là … je vois pas …
[/quote]
C’est marrant, certaines personnes (bien plus expertes que moi) prétendent que ce n’est pas possible, proprement (ie: sans bidouiller, et perte de performance). Moi, en tant que non expert mais ayant quelques idées, je me dis que si c’était faisable, ça ferait bien longtemps que AROS, OS4 et MorphOS auraient choisi cette voie.
Pour moi c’est pas possible tant qu’on ne m’aura pas trouvé le contraire…
Enfin, en tant que toujours non expert, je pense que si on était parti sur une nouvelle API (ie: QBox), à la place de prétendre l’impossible et de bidouiller depuis 10 ans sur le fait que ce soit possible mais sans jamais le faire, l’OS serait déjà utilisable…
Apple s’est bien ramassé à essayer de le faire sur OS9… Finalement ils sont partis sur de l’Unix. Je suppose que les gars étaient bien plus experts que toi et moi pourtant…
Rester dans le passé ne m’intéresse pas pour autre chose que de la nostalgie…
La protection de mémoire, imposera forcément des pertes de performances, même si tu pars de quelque chose de neuf, entre sans/avec protection de mémoire, les perfs seront pas les mêmes…
Maintenant, la protection mémoire c’est très très chiant à faire et beaucoup se sont cassés les dents desus. Cela n’est je pense pas lié à l’OS lui même mais lié aux compétences des développeurs… La preuve est que ces dits programmeurs s’appuient sur quelque chose d’existant plutôt que de créer quelque chose de novueau (comme Apple, ils se sont basés sur Unix au lieu de créer un nouvel OS avec un nouveau système de protection mémoire)
Mais effectivement, installer une vraie « protection mémoire », cela nécessiterait des changements mais plutôt côté application (avec des fonctions supplémentaires dans l’API système pour la mémoire) et en plus, je pense personnellement (et je pense ne pas être loin de la vérité) qu’une gestion parfaite de la « protection mémoire » nécessiterait que ce soit le « processeur » qui la gère et non pas l’OS. J’ai même une idée de comment le mettre en oeuvre … Mais même si c’était le processeur qui la gérerai, il y aurait forcément perte de performances (car il y a des checking à faire)
Du coup, je vois pas le rapport avec « rester dans le passé »
Sauf si tu veux dire, « pour aller de l’avant, il faut faire comme Apple et partir sur de l’Unix » … Mais personnellement c’est pas une solution qui m’enchanterai 🙁
Après, tout comme toi, je ne suis pas un expert … par contre, je suis un « créatif » et je peux facilement *conceptualiser* les choses et me faire une idée de comment les mettre en place ..
Après, forcément, on a 2 visions différentes des choses … On le vit différemment… Je ne prétend pas avoir la vérité ni savoir ce qui est mieux pour l’avenir de l’AmigaOS4 .. Je partage juste ma vision des choses (tout comme toi :p)
@+
[quote]
Ben … je vois pas là … Windows qui est à jour niveau technologie fonctionne en interne à partir de DLL ( Dynamic Link Library ).
DirectX est un système de DLL, Direct3D, DirectPLAY aussi …
Les pilotes graphiques fonctionnent par librairies .DLL
Amiga OS 4 (et les anciens) fonctionnent par des .library (fichier de fonctions). C’est sensiblement la même chose.
[/quote]
Et pourtant la façon dont cela fonctionne n’a pas grand chose à voir. Depuis le chargement de la bibliothèque jusqu’à la manière d’exécuter son code en passant par la façon de reloger celui-ci, tout est radicalement différent. Sans parler de la façon d’écrire le code… réentrant d’un côté, n’importe comment de l’autre…
Tout juste le mot « library » est-il commun aux deux.
Je veux bien croire que le chargement et la relocation mémoire soient différents entre les AmigaOS & Windows, cependant cela ne change pas le principe dont je parle, ce sont dans les 2 cas des fichiers de jeux de fonctions Henes. cependant concernant cette sentence :
[ quote=henes]n’importe comment de l’autre…[ /quote]
J’aimerais que tu apportes plus de précisions et de « preuves » de ton constant: Comment peux-tu le savoir ? Tu as eu accès au code source de l’AmigaOS4 ? Tu as fait du reverse engineering ?
@+
[quote]
La protection de mémoire, imposera forcément des pertes de performances, même si tu pars de quelque chose de neuf, entre sans/avec protection de mémoire, les perfs seront pas les mêmes…
[/quote]
Oui, la protection mémoire implique forcément des pertes de performance. Mais ce que je voulais dire c’est qu’entre un système écrit et conçu pour fonctionner avec, et un OS pensé sans, sur lequel on bidouillerait pour la faire fonctionner il y aurait encore plus de pénalité…
Sinon je ne parle pas de passer par Unix, mais de jeter Exec, Intuition,… et tous ces concepts dépassés et pas du tout prêts pour le hardware actuel, et repartir de quelque chose de moderne, pensé pour le hardware actuel (et futur: donc pas lié à une archi processeur, etc…)
Leo, peut-être. Mais ce n’est pas ce que je craindrait le plus.
D’ailleurs j’utiliserai plutôt le terme « mettre à jour » que « bidouiller » qui est forcément péjoratif alors que le travail peux être fait « proprement » malgré tout. Ce que je craindrais le plus, ce serait plutôt les applications qui n’ont pas été développées avec le principe de protection mémoire.
Sinon, je ne vois pas en quoi Exec, Intuition, graphics ne pourraient pas être améliorés pour prendre en charge le matériel correctement.
Il suffirait de créer une interface matérielle (par exemple un ou plusieurs fichiers .library pour un modèle de carte graphique, de carte son, etc. avec une « pré-structure » identique pour chaque pilote de façon à ce que les fonctions de base puissent être gérées de la même façon pour chaque matériel mais en tenant compte des spécificités du matériel.
Après, il suffirait qu’il y ait un système de *détection* du matériel installé pour que la graphics.library ne charge que le pilote (fichiers .library et autres) lié au périphérique installé.
Tout ceci pourrait se faire en interne sans que l’utilisateur ni le développeur n’ait à y changer quoi que ce soit …
Après, le lien à l’architecture processeur, c’est un sujet ou chacun s’y projette différemment. J’avais déjà pensé à un truc de ce genre à l’époque pour Amiga Classics pour un système de création de jeux qui auto-détectait la matériel installé et ouvrait uniquement les versions dédiées au matériel lors de l’initialisation (genre détecter le FPU du 68060, 68881 et/ou 68882 avec des library de fonctions mathématiques compilées pour chaque FPU… C’est faisable sans avoir à tout changer (j’ai d’ailleurs toujours les sources et je les rendrait peut-être publiques et/ou j’améliorerait le système (maintenant que j’ai une 68030/68882) pour le rendre similaire à l’AmiDARK Engine … Donc au final, je sais qu’il serait possible de faire de même pour l’AmigaOS4 …
Maintenant, y avoir pensé (comme pour le reste que l’on expose) dès le début aurait été un plus non négligeable… Cela aurait évité de développer des parties de code qui deviendront probablement obsolète…
Pour moi, enlever tout ce qui fait le système Amiga (les .library, les datatypes, etc.), c’est comme enlever une partie de l’essence Amiga. Tout comme les Datatypes par exemple, c’est un système très intéressant mais jamais terminé. Si on pouvait un développement réel des datatypes, ça serait cool et très performant je pense :p
l’Amiga pour moi, ce n’est pas simplement qu’une interface graphique, c’est aussi toute une architecture système … Si tu enlèves tout ça tu pourras dire ce que tu veux, tu n’auras plus rien d’Amiga.
@+
@AmiDark: tout simplement parce qu’ils ont été conçus il y a super longtemps. Par exemple: comment intégrer le dual-head avec le système d’écrans de l’Amiga ? Comment étendre le bureau du workbench sur deux écrans ? C’est pas une question de faire proprement ou non, c’est une question d’architecture et de design. Bon nombre de chose sur l’archi actuelle dépendent du hardware original et n’ont pas du tout été prévues pour évoluer, à commencer par le système de message par référence,…
Tu veux faire cohabiter des applications avec et sans protection mémoire ? Toutes les structures de l’OS sont partagées, et accessibles par toutes les applications: comment tu les protèges dans ce cas ? Une copie ? Bonjour la pénalité… De même, qu’est-ce qui se passe si une application qui n’a pas de mémoire protégée tape là où elle devrait pas ? T’as beau avoir protégé les « nouvelles » qui utilisent les nouvelles API, si les anciennes peuvent tout faire crasher, ça ne fonctionne pas, par design.
Et on pourrait continuer longtemps…
Au final tu n’as pas d’autre choix que de réécrire tout de zéro, puisque sinon tu te retrouves avec un truc bancal, entre des applications « récentes », et anciennes…
Pour ce qui est de l’archi processeur, tu oublies le problème liée à l’endianess, les problèmes de SMP,… apparemment le SMP n’est pas possible avec l’architecture actuelle.
Pour ce qui est de la mémoire, apparemment il serait possible, en rajoutant des API d’avoir 4Go par application, mais encore une fois c’est de la bidouille et tu es limité, puisque plus de 4Go n’est pas accessible par tout l’OS… à moins de paginer, mais ça fait tristement penser au DOS… Et dans tous les cas tu te limites à 4Go par application.
Qu’est-ce qui t’empêche de reprendre le système des datatypes sur le nouvel OS, et encore une fois de l’améliorer… Genre pour supporter le vrai streaming, des filtres,… Comme ce qui est fait sur MorphOS avec Raggae par exemple.
Qu’est-ce qui t’empêche d’avoir des .library ?
Au contraire, ce qui me gène le plus ce n’est pas la GUI (même s’il y a des trucs antiques aussi), mais les limites de l’architecture… Et pour ça, rien n’empêche de reprendre certains concepts intéressants et utilises, et de bâtir un OS autour…
Leo :
Dual Screen : Existe déjà sous AmigaOS4.
Ce n’est pas un « Extended display » comme sous Windows mais tu peux (dans les préférences) définir sur quel écran ton application va s’ouvrir ce qui permet d’avoir les 2 écrans utilisés en même temps. Après pour passer d’un écran à l’autre tu utilises les gadgets qui permettent de basculer d’un écran (fenêtre) à une autre…
Après, c’est sûr que si ce que tu recherches c’est « faire comme windows » … Dans ce cas là … autant quitter l’Amiga et passer sous Windows ça sera plus simple et moins « consommateur d’énergie » pour toi et pour d’autres…
« Toutes les structures de l’OS sont partagées » … Du moins, celles qui ont besoin d’être partagées … Je ne vois pas le mal… Surtout que une majeure partie de ces structures (voire toutes) ne sont pas prévues pour être « modifiées par l’utilisateur » mais uniquement pour « être lues »… Je ne vois donc pas où est le problème.
Après, faire cohabiter des applications avec/sans protection mémoire : C’est un peu ce que je te disais comme étant « le soucis » … un peu plus haut…
Cependant, je te signale que ce dont tu parles, même Windows n’en est pas totalement protégé. C’est pas un problème lié à l’OS c’est purement un problème lié à la façon dont les applications sont programmées. Pour les applications anciennes, on pourrait « virtualiser » le lancement d’application (un peu comme Windows fait pour le MS Dos). Ca permettrait d’éviter que ces applications « anciennes » fassent planter tout le système…
Même Microsoft qui a fait évoluer son OS depuis Windows 95 contient toujours la possibilité de compatibilité (plus ou moins complète) des anciennes versions de l’OS… C’est un atout commercial majeur.
« le problème lié à l’endianess »… C’est un problème ou plutôt une différence ? personnellement je ne vois pas cela comme un problème quand je programme. Je sais que pour les données je dois faire la convertion entre PC et Amiga, mais ça ne m’a jamais freiné ni causé soucis …
Le SMP (Symmetric MultiProcessing) Je ne sais pas, je ne connais pas assez la programmation processeur pour pouvoir étayer sur le sujet … Ce qui m’étonne c’est que Hyperion avait dit bosser dessus depuis un certain temps … Je ne doute pas que ce soit difficile … Après, il suffit d’ajouter un système de « communications » entre applications (comme le système de messages actuels) pour éviter que deux applications ne modifient la même zone mémoire en même temps. Ca peux être inclut dans le système de protection mémoire pour des zones crées « partagées » et non pas « exclusives » … Je ne vois pas le problème non plus … Mais il y a probablement des paramètres dont je n’ai pas conscience … N’étant pas (tout comme toi) … expert …
Pour la mémoire. A ce niveau là, je pense que ce sont leur optimisations qui doivent causer soucis… Effectivement, il faudrait qu’ils reprennent certaines parties de l’OS et je pense qu’ils auraient dû y penser depuis le début et que pour le coup, ben va falloir qu’ils s’y collent à modifier cela pour prendre en compte plus de mémoire…. ce n’est pas impossible à faire … un peu long (et donc perte de temps) … mais pas impossible…
En même temps, 4Go par application c’est déjà « monstre » comme mémoire. A part 3DSMax je vois pas quel genre d’applications peut nécessiter plus de 4GO (genre si j’ai pas 4Go je fonctionne pas…)…
Tout à fait. Mais améliorer les Datatypes n’impose pas de refaire tout l’OS aussi 😉
Honnêtement, sans vouloir te vexer leo, j’ai l’impression, en lisant tous les descriptifs des griefs que tu as envers AmigaOS4, que tu cherches à le « formater » pour que tout fonctionne « comme chez les autres », et plus précisément, comme Windows… Et là pour le coup … je ne sais pas trop quoi te dire à part que je pense « sincèrement » que cela n’arrivera jamais et, que pour le coup, tu resteras définitivement « frustré » à ce niveau là (de ne pas pouvoir influer pour que ça évolue dans « ton sens » … Evolution qui à mon avis, n’est pas forcément la meilleure pour AmigaOS4 …
@amidark
Ton post est incomplet : il manque des mots et est donc difficile à comprendre.
Je n’ai en tout cas aucune idée de comment tu as encore réussi à interpréter ce que je disais comme une attaque contre toi ou l’os de hyperion dont je ne parlais même pas…
Encore une fois je compare les bibliothèques partagées de l’Amiga qui demandent à être écrites d’une certaine manière (code réentrant, sémaphore ou forbid pour gérer l’accès aux resources partagées, certains appels interdits, table de saut comme unique point d’entrée) et les dll qui permettent à peu prèt n’importe quoi : aucune restriction de variables globales, appels à ne pas faire etc…
Aucun besoin de reverser je ne sais quoi. Il suffit de lire les docs : tout est transparent dès que l’on *cherche* à comprendre. Et, au pire, il suffit de regarder le « lib.c » des très nombreuses bibliothèques opensource de l’Amiga. Aucun besoin de faire tout ce qu’elle contient lorsqu’on écrit une dll.
Attention, je n’ai pas dit que c’était mieux ou moins bien (c’est un peu les deux) ! Je dis juste qu’il est archi-faux de dire que c’est la même chose. Et c’est d’ailleurs un gros problème pour les « programmeurs » habitués à Windows/Unix et donc habitués à ne rien faire pour écrire une bibliothèque partagée…
Tu dois même pouvoir avoir un main() dans un .so si ça te chante… c’est dire.
@AmiDark: non, je veux quelque chose d’utilisable. Déjà, arrête moi si je me trompe, mais tu parles de deux cartes graphiques, moi je parle de piloter deux écrans avec la même: il me semble que ce n’est pas possible sur Amiga. Ensuite, je ne veux rien formatter, je veux un truc utilisable et intuitif. Il se trouve que étendre le desktop ou le mode miroir, utilisé dans 99% des OS existants (et pas seulement Windows, mais Mac, Linux,…) fonctionne très bien. Maintenant, si sur Amiga tu trouves quelque chose de plus efficace, intuitif,… tant mieux 🙂 Je prends, mais si c’est complètement différent du reste. Mais le système d’écrans actuel de l’Amiga ne fonctionne plus avec deux écrans physiques… C’est pas pratique.
Le problème de partager, c’est qu’il n’y a plus de « protection »… C’est juste la base de l’adressage séparé…
Le problème, et au risque de te vexer, c’est que, même 25 ans après, tu as l’impression que parce que c’est la manière « Amiga », c’est mieux que le reste… Et parce que améliorer les choses veut souvent dire reprendre ce que font Windows ou Linux (parce que il n’y a pas 50 manières d’implémenter certaines choses), ben c’est mal, naze, et ça voudrait dire faire comme font les autres…
Il y a plein de bonnes choses à reprendre. Mais il y a aussi plein de trucs qui sont inutilies et/ou pas applicables en 2013…
Leo je pârle bien de piloter 2 écrans sur AmigaOS4 avec la même carte graphique.
C’est expliqué là : http://forum.hyperion-entertainment.biz/viewtopic.php?f=33&t=1387
(ca ne le supporte pas comme « windows » mais il y a bien possibilité d’utiliser 2 moniteurs en même temps avec 1 carte graphique.
Léo, le système (OS) en lui même prend déjà pas mal de mémoire, les informations systèmes (structures) sont prévues en « lecture seule » et donc, pas besoin de les protéger … Après si le programmeur est un con est qu’il respecte pas ça .. c’est pas la faute de l’OS.
pour le reste, rentrons dans les détails :
Sur AmigaOS4, les AllocVec et AllocMem permettent (entre autre) :
– MEMF_PRIVATE : L’OS devrait protéger cette mémoire d’un accès depuis une autre application que celle qui l’a demandée.
Donc il existe déjà une certaine forme de protection mémoire sur AmigaOS 4 … D’ailleurs, je pense que le fameux « DSI » (Data Storage Interrupt) en est la preuve … pour dire que l’application a accédé à une zone mémoire qui ne lui est pas prévue pour.
C’est peut-être pas au top … Mais bon, c’est déjà un début qui te préviens que ton OS risque d’être instable à cause de cette application « mal programmée »
Marrant Amiga c’est vieux et pas adapter que dire d’Un*x alors 🙂
Kamelito
A Kamelito:
On peux juste dire que contrairement a AOS, « les Unix » ont évolués ….et sont parfaitement adapter a leurs utilisations ….mon bon leur utilisations sont différentes c’est incomparable ……
[quote]
Marrant Amiga c’est vieux et pas adapter que dire d’Un*x alors
[/quote]
Unix est bien plus évolué sur certains points: protection mémoire, etc… D’ailleurs l’Amiga devait bien plus se rapprochait d’Unix sur ce point. Mais le peu de temps laissé au développement fait que pas mal de choses ont été baclées ou réutilisées (TripOS)…
Le problème c’est pas l’âge, mais l’architecture de base, limitée…
@AmiDARK: c’est bête, aucune application n’utilise ce flag…
Rapprocher*
J’ai un pote qui s’est acheté un PI ancien Amigaiste il a envoyé à une liste d’anciens ce mail après avoir testé des emulateurs et systèmes.
« Amiga = galère
J’ai joué avec aspireOS (une des multiples versions d’AROS) ce weekend mais vraiment je n’y comprend plus rien à l’amiga .
en fait l’interface graphique est vraiment trop minimaliste tu es obligé de lancer opus pour bosser sinon il te manque la moitié des applis et fichiers 🙁
Beaucoup d’application retournent simplement du texte 🙁 en mode graphique pas en ligne de commande.
Je trouve dommage qu’ils n’aient pas fait de modification sur les applications du système pour que cela soit un peu plus pratique et utilisable.
La j’ai l’impression d’être sur un amiga d’y a 20 ans et plus même. »
Il faut savoir qu’il programmer sur Amiga et aujourd’hui c’est un développeur Web.
Kamelito
Leo : Déjà, l’OS lui même utilise ce flag en interne (ce qui fait qu’on a parfois un DSI (Data Storage Interrput) sur AmigaOS4 lorsque une application accède à une zone mémoire protégée ( ça m’arrivait pendant le développement de l’AmiDARK Engine quand je me plantai dans les adressages mémoire :p )
Après, j’espère que les applications récentes utilisent ce flag :p
Kamelito : Je sais pas vous, mais perso, du peu de version d’AROS que j’ai pu tester … J’ai pas accroché
De toute façon c’est pas la peine de rêver , la « refonte » de l’OS est quasi-impossible vu les ressources, 3 ans pour un drivers sons sur X1000 et Sam460 ….alors pour le reste ….en plus je vois vraiment pas l’intérêt ….c’est juste un OS léger qu’il faut , la comparaison avec Unix c’est de la « branlette » sont utilité et sa stabilité sont tout autre car se ne sont pas les OS de la bécane de papy …..
@AmiDark: sauf pour les 3/4 des structures internes publiques dans lesquelles les programmes tapent directement…
Elgringo : Je dois avouer que je suis malheureusement un peu d’accord avec ton dernier commentaire…
Leo : Euh … Dit moi quels programmes étant développés pour AmigaOS4 tapent directement dans des structures internes *publiques* ?
Je parle pas des anciennes applications AmigaOS3.x ou antérieures … je parle de version AmigaOS4 uniquement.
( à moins que les développeurs AmigaOS4 actuels soient assez c*** pour ne pas avoir appris du passé … :p )
Facile, comme il faut tout prouver, je regarde le premier truc opensource qui me vient à l’esprit : YAM.
J’ouvre son premier (alphabétiquement) fichier source : http://yam.ch/browser/trunk/src/AppIcon.c
Je vois : if(WorkbenchBase != NULL && LIB_VERSION_IS_AT_LEAST(WorkbenchBase, 44, 0) == TRUE)
Je regarde la définition de cette macro LIB_VERSION_IS_AT_LEAST dans http://yam.ch/browser/trunk/src/YAM_utilities.h :
#define LIB_VERSION_IS_AT_LEAST(lib, minver, minrev) VERSION_IS_AT_LEAST(((struct Library *)(lib))->lib_Version, ((struct Library *)(lib))->lib_Revision, minver, minrev)
C’est bien entendu 100% légal et c’est même ainsi qu’il faut faire.
Au revoir.
Oui Hénès,
Mais là, encore une fois, c’est une variable/structure qu’il est *essentiel* de mettre en public et qui est prévue pour être utilisée en « lecture seule ».
Ce que j’essayais de pointer c’est surtout le fait qu’il puisse exister des variables/structures internes qui soient publiques alors qu’elles devraient être cachées et protégées. Comprends-tu le dilemne du coup ?
Et je suis entièrement d’accord avec toi pour ce cas : « C’est bien entendu 100% légal et c’est même ainsi qu’il faut faire. ».
C’est justement le cas des « LibraryBase » qui devraient être des pointeurs opaques avec des accesseurs (exec.library/GetAttr()) pour récupérer la version+revision.
Et bien sûr ces champs ne peuvent pas être protégés en écriture puisque situés quelques octets après un struct Node qui, par définition, doit être en lecture/écriture. Les MMU fonctionnent par « page » (block de plusieurs ko), pas à l’octet… On ne peut pas mettre l’octet N en lecture+écriture et l’octet N+ en lecture seule. Un CPU ne fonctionne pas de cette manière…
N+1, désolé.
Je comprends Hénès.
Cependant, peut-être que la lecture directe d’une valeur est plus rapide qu’un appel de fonction système. non ?
Et le développeur a conscience qu’il ne faut pas modifier les variables systèmes … Quel en serait l’intêret sinon être un « mauvais programmeur » ?
Personnellement, je ne trouve pas que ce soit une ‘mauvaise façon de programmer’. Simplement que l’on a des machines bien moins performantes que les PC et ce genre de choses sur plusieurs variables peut aider à gagner quelques cycles CPU … non ?
@henes: merci pour les précisions techniques.
@AmiDark: tu plaisantes ? on parle de machines fonctionnant au Ghz, avec des interfaces mémoire de malade. A mon avis une indirection de ce type est largement négligeable. Sans parler du fait qu’un appel de ce type est super rare…
Léo : La Sam 1er modèle est à 666Mhz …
Il y a des configurations Amiga à des fréquences inférieures… (A base de Blizzard PPC qui sont compatible AmigaOS4)
Peut-être ont-ils pensé globalement ?
Peut-être ont-ils simplement continué dans la même dynamique qu’avant parce que cela paraissait simple ?
[quote]
Léo : La Sam 1er modèle est à 666Mhz …
[/quote]
C’est pareil: le rapport est le même… BlizzardPPC ? Je te rappelle qu’ils se posent la question de continuer le support ou non… Et de toutes façons la plupart des applications OS4 doivent être inutilisables sur ces machines, avec ou sans redirection…