Version imprimable
Bonjour,
J'espère que je poste dans le bon forum :oops:
J'ai des demandes afin qu'un programme soit transcrit (de Windows [Delphi]) vers Mac.
Mais je réponds toujours à cela que l'API de l'environnement Mac est très limitée comparé à Windows.
Ai-je raison ?
Merci d'avance de vos éclaircissements :D
Pas du tout. Par contre :
- Quelles fonctions veux tu traduire en API Mac OS (X) ?
- Quel langage aimerais-tu utiliser ? Sachant que les langages les plus utilisés sous Mac sont C, C++ et Objective C.
Melem, merci de ton éclairement,
Pour te répondre franchement :
- Quelles fonctions veux tu traduire en API Mac OS (X) ?
Aucune ! car j'ai déjà pas assez de temps pour bien des choses, alors je cherche surtout à éviter les OS non populaires.
Surtout que le programme en question est le fruit de plusieurs années.
- Quel langage aimerais-tu utiliser ? Sachant que les langages les plus utilisés sous Mac sont C, C++ et Objective C.
La réponse du dessus y répond indirectement, mais si toutefois c'était possible directement sous Delphi... :oops:
Oui mais alors tu affirmes que l'API MAC est > à Windows ?
Des preuves stp ! :D
En fait, je cherche surtout une argumentation afin de ne pas dire que cela ne m'intéresse pas de me plonger dans la pomme ; j'ai déjà assez de la fenêtre.
Quoique des fois l'occasion faisant le luron... Ne jurons de rien.
@+
Pourquoi ne pas faire estimer la faisabilité et le coût du portage de vos applications Windows/Delphi sous MacOS?Citation:
Envoyé par Droïde Système7
Vous devriez trouver des expertises qui devraient savoir faire cela en 2/3 semaines - si vous ne demandez pas une précision < 1% et un engagement contractuel à réaliser, vous devriez vous en sortir à pas cher.
De toutes façon, vous ne semblez avoir ni le temps ni l'expertise pour faire cette évaluation... et comme nous sommes dans une période ou les clients OSX "montent", il va peut être falloir que vous serviez une autre soupe...
Voilà qui pourrait être l'occasion de faire une version majeure indépendant de l'OS (Windows/Linux/Mac....) et en profiter pour nettoyer un peu les années de sueur qui y trainent...Citation:
Pour te répondre franchement :
- Quelles fonctions veux tu traduire en API Mac OS (X) ?
Aucune ! car j'ai déjà pas assez de temps pour bien des choses, alors je cherche surtout à éviter les OS non populaires.
Surtout que le programme en question est le fruit de plusieurs années
Bon enfin, j'essaie de vous donner quelques idées pour être un peu moins négatif sur la chose... Mais vous êtes le maître incontesté à bord.
- W
wiztricks écrivait :
Nettoyer = notion de portabilité dont je subodore l'idée poindre :mouarf:Citation:
Voilà qui pourrait être l'occasion de faire une version majeure indépendant de l'OS (Windows/Linux/Mac....) et en profiter pour nettoyer un peu les années de sueur qui y trainent...
Certes, tout cela est loin d'être faux.
Mais l'appli en question repose en grande partie sur l'API de la fenêtre colorée.
Tout ça ne me donne pas grain à moudre au niveau argumentation : API Windows > à celle de Mac ?
Argumentation et non réponse binaire ;)
Merci déjà pour l'avancée en rapport à ces éléments.
@+
Côté portage, il y a éventuellement un bout de piste via Lazarus : ils ont implémenté pas mal de choses de la VCL, ça n'a pas l'air trop mal même si je n'ai pas encore eu l'occasion (ni le temps !) de tester ça plus en détail.
Pour l'adaptation API Win32 -> Autre API, par contre, ça risque d'être un poil plus difficile sans réécriture : l'API Linux, par exemple, est plutôt éloignée de l'API Win32 d'un point de vue interface, et des éléments qui sont "natifs" sous Win32 requièrent des librairies spécifiques sous Linux pour être utilisés... Or, on ne peut jamais être certain qu'un package Linux sera installé sur chaque machine cible !
Certes, il y a les dépendances, mais si une appli commence à réclamer 2 Go de dépendances, à mon avis, ça ne va pas trop plaire à la plupart des utilisateurs.
Le plus simple serait sûrement de faire le portage sous Lazarus, et voir quelles sont les fonctions Win32 "manquantes" suite à ce portage. Après, il faudrait soit écrire un wrapper (conservation du code source à l'identique et écriture de wrappers Win32 -> Autre API), soit changer les fonctions pour des éléments plus portables (VCL ou librairies multiplateforme). Dans tous les cas, le problème récurrent sera la faible disponibilité d'éléments complètement portables en Delphi, et la contamination au niveau licence.
J'aurais donc tendance à fabriquer une DLL wrapper pour ma part, pouvant être écrite en C/C++ et implémentant les fonctions Win32 qui te sont nécessaires. Elle sera plus facile à maintenir en C/C++ qu'en Delphi/Pascal, et sera surtout plus facilement portable. Sous Win32, il est évident que tu t'en passeras pour utiliser les API natives.
Une autre solution possible de portage "brut de fonderie" serait d'utiliser Wine, du moins s'il en existe une version sous OSX et si cela permet d'utiliser correctement l'application malgré tout.
Mac LAK ;) super ton développement,
Arrivé à ce point, n'en jetez plus la cour est pleine :D
Puisque sur mettons 1000 téléchargements sous Windows, je n'en aurais même pas le dixième sous la pomme, et encore... Alors vu le temps de portage que cela représente, je préfère développer autre chose, que de me prendre le choux pour un résultat au final, risquant d'être dépouillé de toute substance représentant et représentante de l'originalité de l'API Windows.
Ne perdons pas de vue que le but de ce thread est surtout pour moi d'être renseigné si l'API fenêtre est supérieur ou non à l'API pomme.
Jusque là les arguments avancés sont assez menus.
@+ :chin:
Salut,
Et si tu commencais par definir ce que tu entends par "superieur" ;) ?Citation:
Envoyé par Droïde Système7
Salut,Citation:
Envoyé par tonton fred
Je partais du point de vue nombre = richesse.
@+
notre expérience du "portage" Windows -> Mac est que l'API Cocoa nécessite moins de lignes pour faire plus,
et que l'architecture des frameworks est beaucoup plus importante que le nombre de méthodes disponibles.
(et par moins de lignes il faut comprendre des réductions jusqu'à 40% dans certains cas…)
donc on pourrait dire par analogie gastronomique : ne pas confondre "richesse" et "mauvaise graisse"…
autre élément à tenir en compte : réécrire va plus vite qu'essayer de récupérer du code pour tout ce qui concerne l'interaction avec l'utilisateur… ne gardez que le code de pur "calcul" (au sens large…)
:bravo:Citation:
Envoyé par JeitEmgie
Hélas, c'est vrai.
Les problèmes de la lourdeur de Windows sont essentiellement dus à la compatibilité ascendante des différents "kludges" que Microsoft à du implémenter dans le temps.
De plus, OSX est beaucoup plus fermé que Windows: vous êtes tenu de le faire fonctionner sur des systèmes Apple qui ont été testés "pour".
Windows vole en OEM sur des matériels différents.
OSX à donc pour le développeur tous les avantages d'un système propriétaire sans les inconvénients des fenêtres à pouvoir poser sur n'importe quelle maison pourvu qu'elle ressemble à un PC.
=> A configuration équivalente le coût d'un Mac est bien plus cher: normal, taille du marché, coûts de qualification,... Mais la qualité, çà se paie.
Ceci n'est pas une critique de Windows, mais la mise en perspective de deux modèles industriels qui sont tout deux propriétaires et sans les mêmes avantages inconvénients.
- W
Merci. Ceci étant dit, à titre d'évolutivité, j'aurais quand même tendance à envisager un tel portage d'API, mais de façon sous-traitée. En effet, il te faut un système cible (Mac / Linux) pour le tester intensivement, et une bonne connaissance dudit système cible pour effectuer le portage.Citation:
Envoyé par Droïde Système7
Ceci étant dit, cela pourrait intéresser quelqu'un, et donc vous pourriez vous rendre mutuellement service.
Il faut aussi parfois une seule ligne Java pour faire l'équivalent de 50 lignes de C/C++... Cela ne veut pas dire pour autant que :Citation:
Envoyé par JeitEmgie
- Le programme Java ira plus vite,
- Qu'il prendra moins de place sur le disque dur,
- Qu'il consommera moins de ressources système.
Donc, mesurer ça au "nombre de lignes de code nécessaires" est assez utopiste...
Donc, on jette l'IHM, on jette le code API, on garde uniquement le calcul "pur" ?Citation:
Envoyé par JeitEmgie
Je ne suis pas certain que l'on aie la même définition de "portage"... :roll: Ce que tu fais ressemble plus à une adaptation par réécriture, et non pas à un portage.
… on ne voit pas très bien le rapport entre ce que vous dites et les avantages et inconvénients des APIs…Citation:
Envoyé par wiztricks
par définition, une API devant abstraire le hardware, si celui-ci transparait dans l'API de haut niveau de manière trop évidente c'est que l'API à échouer dans son rôle…
d'autre part, les faits contredisent votre argumentation : il y a plus de différences entre un Mac à architecture PowerPC et un MacIntel qu'entre 2 PCs quelconques supportant Windows… chipsets, la séquence de boot, la partition map des disques, les différences d'endianess, sans parler des optimisations vectorielles totalement différentes, ni du support du mode Classic sur les PowerPC… et sans parler du portage sur les plate-formes à architecture ARM… ni sur tout ce que teste Apple dans ses labs…
ce n'est pas parce que le monde Mac est plus simple que l'API Cocoa est mieux pensée… d'autant plus que c'est un héritage de NeXT… et qu'à cette époque une version pour Windows existait aussi…
Non. C'est l'impression que tu as, grâce notamment au standard AT et son BIOS qui verrouille un minimum le boot et l'accès basique aux périphériques, et grâce à Windows derrière (ou Linux, soyons honnêtes car il fait à peu près la même chose) qui implémente un HAL pour, justement, éviter d'avoir à trop devoir gérer le matériel spécifiquement.Citation:
Envoyé par JeitEmgie
Tu peux avoir des CPU différents, des chipsets différents, des mémoires différentes, des bus machine différents (ISA, VLB, PCI, AGP, PCI-E), des connexions aux HDD différentes (IDE, E-IDE, SCSI, SATA, SATA-2, USB, Firewire, mode RAID ou pas), des formatages différents, des périphériques absents, etc. Entre deux machines "PC", une fois sorti du BIOS, tu peux très bien ne pas avoir UN SEUL driver (donc, pas un seul composant !) en commun, tu en es conscient ? Pourquoi crois-tu que les Linuxiens réclament des drivers "constructeur" pour leur OS ?
Certes, on peut abstraire encore plus le matériel... Mais ça rajoute des couches, et/ou des limitations (perte de possibilités spécifiques), et donc ça a un coût.
Entre un Mac PPC et un Mac Intel, OK, il y a pas mal de différences... Mais est-ce que ce sont les mêmes binaires qui tournent sur les deux machines ? Non, ils ont été compilés / adaptés aux deux cibles, donc cela devient deux systèmes totalement différents. Aussi différents qu'un Linux PPC et qu'un Linux x86, en fait.
A-t-on autant de possibilités de différences entre deux Mac PPC (ou deux Mac Intel) qu'entre deux PC ? Non plus.
Ne compare pas une API qui a plus de 20 ans d'évolutions, qui a supporté une demi-douzaine d'évolutions majeures du matériel tout en assurant la rétrocompatibilité binaire avec une API qui n'a connu, réellement, qu'une seule "grosse" évolution (le passage aux CPU Intel).Citation:
Envoyé par JeitEmgie
Les configurations Mac restent très figées par rapport aux configurations PC : il n'y a guère que les consoles qui soient plus verrouillées que les Mac en terme de matériel. Cela n'empêche pas d'avoir plusieurs API sur Mac non plus, et qui sont plus ou moins interconnectées (Cocoa / Carbon notamment, sans parler de Classic bien sûr). Tout comme certaines opérations matérielles sous Windows peuvent se faire sans avoir besoin de réinstaller l'OS ou les applications : j'ai déjà changé ma CM sans réinstaller mon Windows, par exemple, et ça marche nickel. Tu as un exemple équivalent sous Mac à proposer ? ;)
Après, l'API (Mac ou Win) est ce qu'elle est, avec ses qualités et défauts, et ceci est valable pour les deux. Mais l'API Win32 est forcément et obligatoirement "bas niveau" (donc, exposant en partie le matériel sous-jacent) pour justement permettre son fonctionnement sur la multitude de matériels différents pouvant composer un PC. Chose que l'API Mac peut se permettre d'éviter, tout comme l'API Next qui fonctionnait AUSSI sur des machines relativement "fermées". Et chacun de ces choix possède son prix à payer, comme le précise également wiztricks.
Enfin, il ne faut pas oublier non plus que si Win32 est l'API "de base" de Windows, elle n'est pas non plus la seule, ni forcément la plus simple à utiliser. Grâce justement à sa granularité élevée, elle peut être facilement encapsulée avec un overhead très léger côté performances. C'est ce que font la plupart des frameworks "natifs" sous Windows, comme par exemple la VCL de Delphi qu'utilise Droïde.
Pour la petite histoire, non, je ne suis pas un "anti-Mac", pas plus qu'un "anti-Linux". J'ai des produits Apple, Microsoft et GNU/Linux chez moi. Simplement, je prends le produit le plus adapté à MES besoins, pour CHAQUE besoin. Rappelle-toi simplement que TES besoins, contraintes et domaines d'utilisation ne sont pas les mêmes que ceux des autres, et donc forcément TON OS favori n'est pas forcément supérieur à tous les autres... ;)
Une API fonctionnera d'autant mieux qu'on limite la variabilité de ce qui se cache derrière. Sinon, vous allez avoir des extensions qui devront permettre de profiter des "spécificités" de ce qu'il peut y avoir derrière....Citation:
Envoyé par JeitEmgie
Absolument, mais d'une architecture à l'autre, Apple ne s'engage pas à supporter les codes alors que pour Windows, c'est beaucoup plus transparent.Citation:
d'autre part, les faits contredisent votre argumentation : il y a plus de différences entre un Mac à architecture PowerPC et un MacIntel qu'entre 2 PCs quelconques supportant Windows…
A l'époque vous aviez un NeXT futuriste, résolument orienté objet et sans concessions: il fallait une belle machine Sun pour pouvoir le tourner.Citation:
ce n'est pas parce que le monde Mac est plus simple que l'API Cocoa est mieux pensée… d'autant plus que c'est un héritage de NeXT… et qu'à cette époque une version pour Windows existait aussi…
Pendant ce temps là, Windows réussissait à construire une IHM sympa sur de modestes 8086 à quelques Mhz: ils étaient dans une logique volume non dans la recherche futuriste.
20 ans plus tard, les capacités pour faire tourner des environnements tels que NeXT sont devenues plus abordables...
Et Windows, compatibilité ascendante relative oblige, a du faire des tas de vérues et de compromis pour arriver à en profiter.
Deux modèles complètement différents: patchwork mercantile comparée à une pureté presque suicidaire.
- W
Note: Vista est sortie des années après XP et il aura fallu attendre Windows7 pour que cela soit raisonnablement utilisable. Vu le nombre de développeurs que Microsoft peut se payer - et ce sont loin d'être des bras cassés - c'est qu'ils ont du résoudre nombre de difficultés techniques.
Nombre d'entre elles liées à la nécessité de préserver un tant soit peu le patrimoine applicatif existant.
tout çà n'est qu'un tissu de contradictions… et de non-sens par rapport à la question originale…Citation:
Envoyé par Mac LAK
je redis : clairement une bonne API pour le développement d'applications end-user a pour vocation à abstraire le hardware…
Cocoa est tout simplement mieux conçu dès le départ… et ses origines pourtant remontent aussi à 25 ans…
Ses avantages n'ont strictement rien à voir avec l'architecture hardware des Macs :
ce n'est pas parce qu'il n' y a moins de variations dans le hardware des Macs que Cocoa permet de faire plus en moins de lignes de code…
mais on parle bien de portage d'applications pas d'écriture de drivers…
s'il y a lieu de comparer Cocoa à quelque chose sur Windows, parlons de MFC et de ses successeurs (ou d'autres frameworks d'autres sources…) mais pas de Win32… çà n'a aucun sens…
sinon on est parti pour évoquer les couches Mach-O, BSD, et C°… et là il s'agit d'une comparaison plus générale Unix/Windows…
et de toute façon le portage de drivers d'un OS à l'autre est un tout autre problème…
Non : c'est parfaitement dans l'axe de la question de Droïde, et surtout dans l'axe de tes remarques qui voudraient faire croire que Mac est un système moins figé que PC ou Windows. Et encore, je n'ai pas cité WinCE (multi-CPU) si l'on reste sur le monde Windows, je n'ai parlé QUE du matos (l'archi PC, donc).Citation:
Envoyé par JeitEmgie
"API" et "end-user" dans la même phrase ??? Tu n'as pas l'impression de mélanger des chèvres et des parpaings, là ???Citation:
Envoyé par JeitEmgie
Le "end-user" ne développe PAS, donc se contrefiche des API, et je ne vois pas en quoi une application destinée au quidam moyen est différente d'une application destinée à un "pro"... Tu as les mêmes contraintes de fiabilité, d'ergonomie, de déploiement, sauf que le pro, lui, va te demander des choses radicalement différentes du particulier.
Quant au développeur, s'il veut sortir un peu des fonctionnalités basiques (comprendre "communes à tous les OS"), il faut bien qu'il touche au système, donc rende son code spécifique, et finisse par mettre les mains dans le cambouis. C'est bien sûr encore pire lorsque l'on développe des outils système et/ou destinés à contrôler, justement, le matériel...
Alors franchement, je ne vois pas en quoi une "bonne" API abstrait le matériel... C'est plutôt pour moi le signe d'une API défaillante !! Une bonne API système fournit les DEUX méthodes d'accès, le mode "roots", et le mode "je débute la programmation".
Or, s'il est toujours possible de rendre une API "bas niveau" plus abstraite via des surcouches, je vois mal comment "scinder" une API de trop haut niveau...
Et a été développé pour des machines qui ont été un échec commercial retentissant, t'as oublié de le préciser...Citation:
Envoyé par JeitEmgie
Non, en effet : c'est parce qu'il n'y a que très peu de variations de matériel que l'on peut avoir une API abstraite sans qu'elle coûte un bras en performances ou en maintenance, voire les deux le plus souvent.Citation:
Envoyé par JeitEmgie
Tout comme les API Java qui s'appuient sur des JVM qui sont, par nature, totalement figées elles aussi : c'est loin d'être un aspect négligeable de la maintenabilité de tels frameworks / API.
En effet. Les applications Windows sont soutenues par Win32, qui a ses raisons d'exister, ses qualités et ses défauts. Porter une application sur une machine conçue dans une optique diamétralement opposée a forcément un coût non négligeable.Citation:
Envoyé par JeitEmgie
MFC n'est qu'une encapsulation objet de Win32, ni plus, ni moins, et reste quelque chose d'assez bas niveau quoi qu'il en soit. Le framework .NET est "mieux conçu", au sens où tu l'entends, mais il est également bien plus récent et n'a donc pas de "passif" à supporter.Citation:
Envoyé par JeitEmgie
De plus, n'est-ce pas toi qui disait, justement, "notre expérience du "portage" Windows -> Mac est que l'API Cocoa nécessite moins de lignes pour faire plus" ? Donc, qui comparait Win32 à Cocoa ? Car je te rappelle que sans préciser plus avant, l'API Windows, c'est Win32, et non pas .NET ou MFC...
On parle d'API générales. Sous Windows, ces API ne sont PAS en option (elles sont installées systématiquement, le seul "critère" réel étant la version/SP de Windows installée), elles sont rétrocompatibles, tandis que sous Unix, ce SONT des options (elles peuvent ne pas exister), et la rétrocompatibilité binaire n'est pas garantie d'un kernel à l'autre.Citation:
Envoyé par JeitEmgie
On ne "porte" pas un driver : on le réécrit.Citation:
Envoyé par JeitEmgie
C'est bien pour ça que je te disais que l'on n'avait manifestement pas la même notion pour le mot "portage" : tu sembles confondre "réécriture" et "portage", ou pire, croire que c'est exactement la même chose... Ce qui est totalement faux, n'importe quelle personne (dont moi, d'ailleurs !) qui développe des applications portables te le confirmera.
La notion sous-jacente dans le mot "portage", c'est "modification minimale (idéalement nulle) du code". Dans le cas présenté par l'OP, cela implique ce que j'ai déjà expliqué : portage sous Lazarus (donc portage du code Delphi), et création d'un wrapper Win32<->Autre OS pour les fonctions Win32 qu'il utilise... Sachant que ce wrapper peut parfaitement être écrit grâce à des librairies d'abstractions d'OS comme ACE, POCO ou ICE.
Apparemment, j'ai été trop "subtil" dans mes messages précédents, donc je vais être plus clair. Non, ton API Cocoa n'est pas "meilleure" que les autres. Non, elle n'est pas "überoxxor" à enterrer toutes les autres. Elle est peut-être mieux pour TON besoin, mais pas pour TOUS les besoins.
Et en l'occurrence, elle n'est d'AUCUNE utilité pour le portage qu'envisage Droïde, car il cherche à PORTER son application, et non pas à la réécrire. Donc, se "verrouiller" sur une API propriétaire pour en lâcher une autre serait tout simplement débile, car il devrait TOUT refaire pour un portage sur un 3ème OS (Linux, au hasard...).
notre expérience avec les applications end-user(1) multi-plateformes est qu'une qualité de résultat supérieure est atteinte plus vite en moins de temps par nos équipes Mac que par nos équipes Windows, que toutes les discussions techniques avec les équipes montrent que la trilogie Objective-C+Cocoa+InterfaceBuilder n'y est pas étrangère, que la réécriture (quelque soit le sens du portage d'ailleurs) des parties UI est plus rapide et de meilleure qualité (aussi bien celle du code que la celle perçue par l'utilisateur final) que toute tentative d'imitation maladroite de l'un par l'autre, et que la maintenance d'une application Cocoa est plus facile et donc moins chère…
et je fais plus confiance à mon expérience et celles de mes équipes qu'à votre charabia qui passe sans arrêt du coq à l'âne…
d'autant plus qu'à mon niveau, c'est la bottom line en $$$ qui compte et pas vos élucubrations…
donc quoique vous en pensiez utilisez au mieux les APIs spécifiques de chaque plate-forme est plus efficace et rentable (chez nous…) que des solutions soi-disant passe-partout…
(1) par application end-user : il est entendu une application desktop native destinée à être directement utilisée par ± M. Toutlemonde et dans laquelle l'interaction joue un rôle prépondérant, pas un tool, daemon, application Java ou autre application où l'interaction se limiterait à choisir une action dans un menu ou appuyer sur l'un ou l'autre bouton… on parle de "vraies" applications interactives avec drag-drop, undo à l'envi, support mult-écran, détection de connection de périphériques audio et video, multi-threading poussé, optimisations vectorielles, connection Internet pour les mise à jour automatique, rapport de problèmes intégré, etc. … on ne parle pas de jouet à 99 cents…
et donc quand on parle de réduction de la taille du code source sur ce genre d'applications, il ne s'agit pas d'un phénomène anodin dû au hasard de la disponibilité heureuse d'une fonction magique résolvant un cas particulier… il s'agit bien d'un effet statistique global et donc significatif…
Bon... je tente de calmer le jeu, avant que tout le monde ne s'entretue :mouarf:
Mes idées sont désormais claires, j'avais d'ailleurs développé cela un peu plus haut.
Bref je tague en "Résolu".
A part du sujet en lui-même, en gros suivant toutes vos explications, je pourrais en déduire que le Mac pourrait être comparé à une berline de luxe et Windows à la berline de M. et Mme Tout-le-Monde.
Mais les possesseurs et utilisateurs de Mac, jureront que leur OS est bien supérieur à l'OS possédant une fenêtre colorée et vice versa.
L'année dernière je me souviens que chez un éditeur j'avais évoqué le sujet et... un peu plus j'étais éjecté directo vers la sortie :P :mrgreen:
Refermons la parenthèse si vous le voulez bien, le principal est que tout le monde y trouve son compte ; n'est-ce pas ?
Encore :merci: à tous :chin:
Bon, on va donc résumer : toi, tu bosses sur des applications de quelle taille ?Citation:
Envoyé par JeitEmgie
Moi, ce sont des centaines de milliers de lignes de code, sur des applications distribuées, portables, tournant sur 3 à 6 OS différents, multi-langages, ayant des composantes temps réel, réseau, stockage et calcul intensif, et avec une équipe qui oscille entre 20 et 40 personnes dessus. A temps plein. Puisque tu veux parler argent, un système complet vaut quelques MILLIONS d'euros, et c'est garanti 15 ans.
Alors les problèmes d'intéropérabilité, de portage, de deadline, de maintenance, de coût, de gestion des obsolescences et d'évolution, ça va, je maîtrise, j'en bouffe au quotidien depuis dix ans. Et vu le prix qu'y mettent mes clients, ça ne les rend pas spécialement tolérants aux bugs : ils paient pour assurer une fonction pendant 15 ans, quoi qu'il arrive, quoi qu'il se passe. Et réécrire en natif une appli, c'est la porte ouverte aux régressions, différences de comportement, et dérives de code. Bref, un joli trou sans fond où l'on pourra jeter plein de sous.
Relis un peu mieux ce que j'écris : non, je ne critique pas ta chère API, je tente (vainement apparemment) de t'expliquer qu'elle n'est PAS la panacée universelle que tu sembles croire, qu'elle a AUSSI des faiblesses, et qu'on ne réalise pas un portage d'application en réécrivant tout en natif (pas si l'on veut maintenir le logiciel dans l'avenir, en tout cas). Ni plus, ni moins.
Définitivement, nous n'avons pas la même notion de ce qu'est un portage, ou une application portable...
T'inquiètes, j'ai terminé... ;)Citation:
Envoyé par Droïde Système7
Par contre, si jamais tu as l'occasion d'essayer Lazarus de façon un peu intensive, je suis intéressé par un retour d'expérience.