maison
Top.Mail.Ru Yandeks.Metrika
Forum: "Autre";
Archive actuelle: 2017.01.15;
Télécharger: [xml.tar.bz2];

vers le bas

Packages d'exécution Trouver des branches similaires


Германн ©   (2016-03-03 23:58) [0]

Pourquoi sont-ils nécessaires?
Il est théoriquement clair pourquoi. Pratiquement ...?
Laissez les utilisateurs respectés du forum organiser un mini-sondage.
1. Est-ce que certains d'entre vous utilisent des packages d'exécution dans leurs programmes?
2. Quelqu'un a-t-il déjà vu des programmes tiers utiliser des packages d'exécution Delphic?



Rouse_ ©   (2016-03-04 00:03) [1]

1 no
2 oui
Nécessaire pour réduire la taille de l'application



Inovet ©   (2016-03-04 00:16) [2]

L'idée est d'économiser de la RAM lors de l'exécution de plusieurs applications différentes.



Kerk ©   (2016-03-04 00:23) [3]

Oui
Oui



Германн ©   (2016-03-04 00:24) [4]


> Rouse_ © (04.03.16 00: 03) [1]
> Xnumx oui

Et lesquels?
Réduire le volume de l'application est un problème très controversé. Et SW dans ce sujet, en tant que spécialiste compétent, a mis en garde à ce sujet. Avec le fichier exécutable, vous devez également faire glisser / distribuer des bibliothèques. De plus, dans ce cas, le volume total du package de distribution est supérieur à celui du programme qui n'utilise pas de packages d'exécution.



Германн ©   (2016-03-04 00:30) [5]


> Inovet © (04.03.16 00: 16) [2]


> Kerk © (04.03.16 00: 23) [3]

En théorie, ils économisent vraiment si j'écris (par exemple) et installe deux de mes programmes sur un ordinateur. Si ces deux programmes ont été écrits par des auteurs différents, il est très probable que ces auteurs, compte tenu des versions différentes de Delphi, n’ont aucune économie!



Германн ©   (2016-03-04 00:39) [6]

2 Kerk © (04.03.16 00: 23) [3]
Je n’ai pas remarqué immédiatement que vous avez répondu «oui» à la deuxième question. Ensuite, si ce n'est pas «pause», appelez ce programme tiers.



Eraser ©   (2016-03-04 01:41) [7]


> Hermann © (03.03.16 23: 58)


> Théoriquement, pourquoi. Pratiquement ...?

dans les premières versions de Delphi, les disquettes étaient toujours utilisées, aussi la réduction de la taille avait encore du sens.



Германн ©   (2016-03-04 01:48) [8]

Ce sont toutes des choses des jours passés. Maintenant, pourquoi s'en souvenir?



Eraser ©   (2016-03-04 02:19) [9]


> Hermann © (04.03.16 01: 48) [8]

compatibilité ascendante. il est fort probable que beaucoup de gens ne comprendront pas s’ils acceptent Delphi et annulent simplement le concept de packages d’exécution, d’autant plus que cela n’affecte pas l’assemblage traditionnel de l’application, mais plutôt un fitcha. Je suis sûr qu'il y a suffisamment de masochistes qui implémentent la même localisation à travers ces paquets, mais vous ne savez jamais ce qu'il y a.



Kerk ©   (2016-03-04 02:36) [10]

Oui, d'où vient la taille. DLL n'a pas été inventé pour réduire la taille. Et les BPL sont les mêmes DLL, mais plus pratiques.



Юрий Зотов ©   (2016-03-04 06:10) [11]

Ce n'est pas seulement (et pas tellement) en taille. L'architecture de plug-in est ce qui est implémenté simplement et naturellement via des packages d'exécution. Et ceci est une fonctionnalité multilingue, flexible, extensible, etc.



эндсоувот ©   (2016-03-04 08:45) [12]

plus un million d'autres raisons non directement liées aux économies de mémoire et à l'architecture en général.

par exemple, la division banale du code dans l'Antiquité alors que seuls les anciens geeks étaient au courant des subversons de la gita et d'autres tortues



Dimka Maslov ©   (2016-03-04 10:02) [13]

1. Jamais.
2. Non



megavoid ©   (2016-03-04 10:07) [14]

Des millions de programmes de studio utilisent le runtime, Microsoft doit distribuer des bibliothèques. Oui, même l'interpréteur PHP sous Windows ne démarre pas sans cette redistribution, personne n'en souffre. Bien sûr, il existe différentes versions pour chaque version de studio, bien sûr, il existe des versions 32, 64, ainsi que des mises à jour sous la forme sp1 sp2 sp3. Puis-je argumenter - dllki libc n’est pas la même chose que bpl - oui, pas la même chose, mais l’essence est la même - quelqu'un est plus à l'aise, quelqu'un l'utilise.



megavoid ©   (2016-03-04 10:08) [15]

Xnumx jamais
2 oui



Pavia ©   (2016-03-04 10:13) [16]

Aucun
En vrai non. Par exemple, dans l'article Oui.



Rouse_ ©   (2016-03-04 21:04) [17]


> Hermann © (04.03.16 00: 24) [4]
> Et lesquels?

Eh bien, ici, c’est très simple: si vous développez un bon package de ce type, puis lors de l’utilisation du moteur d’exécution, vous économiserez une taille relativement solide du fait que le code répété sera restitué.
Bien entendu, il ne s’agit pas d’un exécutable 1-2 et de quelques bibliothèques, mais d’une dizaine d’entre elles (à peu près - d’un complexe).
Cela a-t-il un sens maintenant? Je ne le sais pas. Je ne l'ai jamais fait et je ne le ferai pas.
Mais vu de tels produits



Rouse_ ©   (2016-03-04 21:07) [18]


> Yuri Zotov © (04.03.16 06: 10) [11]
> Ce n’est pas seulement (et pas tellement) en taille. Architecture du plugin
> - c'est ce qui est mis en œuvre simplement et naturellement à l'exécution
> forfaits.

Laissez-moi discuter - BPL est le moyen le plus simple de tuer une bonne idée avec des plugins :)



Германн ©   (2016-03-05 00:55) [19]


> Kerk © (04.03.16 02: 36) [10]
>
> Oui, d'où vient la taille. DLL n'est pas pour la réduction de taille
> est venu avec. Et les BPL sont les mêmes DLL, mais plus pratiques.

Les BPL sont les mêmes DLL, mais avec un inconvénient majeur. Ils dépendent de la version de Delphi sur laquelle ils sont créés. Et par conséquent, ils ne peuvent être utilisés que dans des logiciels créés sur la même version de Delphi.
En fait, je ne connais qu'un seul environnement de développement dans lequel les bibliothèques RT étaient activement utilisées. C'est Visual Basic. Il y a environ onze ans, lorsque ma fille était encore petite et qu'il n'y avait qu'un seul ordinateur à la maison et qu'il y avait beaucoup de jouets écrits sur Visual Basic sur Internet, j'ai vu plusieurs bibliothèques de différentes versions de BASIC sur mon ordinateur.



Eraser ©   (2016-03-05 01:00) [20]


> megavoid © (04.03.16 10: 07) [14]


> personne n'est tourmenté.

déclaration controversée.


> Chaque version de studio a ses propres dlls, bien sûr il existe des versions
> 32, 64, il existe également des mises à jour sous la forme sp1 sp2 sp3.

c'est ce qu'on appelle le mot obscurité. presque tous les programmes et jouets moins sérieux entraînent ces bibliothèques RT, ce n'est pas normal.



Германн ©   (2016-03-05 01:07) [21]


> Rouse_ © (04.03.16 21: 04) [17]
>
>
>> Hermann © (04.03.16 00: 24) [4]
Cité1 >> et quoi?
>
> Eh bien, ici, c’est très simple: si vous en développez un bon
> dossier de candidature

J'ai développé un tel ensemble d'applications pour les installations de carburateur en Russie.
Mais d’une manière ou d’une autre, je n’ai pas remarqué d’économie spéciale. L'enregistrement dans la RAM se fera si, dans le même temps, je vais travailler avec beaucoup d'applications à partir de ce paquet. Ce que je n’ai pas eu. Bien sûr, il sera toujours utile d’économiser sur la HD, mais lorsque nous répondons aux questions des débutants sur la taille «trop grande» du programme Delphi, il est quelque peu anormal d’économiser plusieurs dizaines de mégaoctets.



Германн ©   (2016-03-05 01:13) [22]

La seule chose dont je ne suis pas sûr, c'est le débogage des paquets. Il peut y avoir une division d'un paquet en paquets RT et DT, ce qui facilite le débogage. Mais je ne me souviens pas que SW me conseille cette séparation il y a cent ans, lorsque j’ai eu des problèmes pour déboguer mes premiers paquets.



Юрий Зотов ©   (2016-03-05 11:46) [23]

> Rouse_ © (04.03.16 21: 07) [18]
> BPL est le moyen le plus simple de tuer une bonne idée avec des plugins


Une pensée intéressante. Les explications seront?

> Hermann © (05.03.16 01: 13) [22]
> la division d'un paquet en paquets RT et DT facilite le débogage


La séparation de paquets vous permet de:

1. Lors de la compilation sans packages, n'incluez pas dans le fichier EXE les ressources nécessaires uniquement dans DT (par exemple, les icônes de composant).

2. Lors de la compilation avec des packages, n'emportez pas les packages EXE nécessaires uniquement dans DT.



Rouse_ ©   (2016-03-05 12:56) [24]


> Yuri Zotov © (05.03.16 11: 46) [23]
>> Rouse_ © (04.03.16 21: 07) [18]
>> BPL est le moyen le plus simple de tuer une bonne idée avec des plugins
>
> Une pensée intéressante. Les explications seront?

Bien sûr.
Un plugin est quelque chose que tout programmeur tiers peut ajouter à notre application (généralement via le plugin SDK), mais puisque nous considérons BPL, alors:
1. Je note - tiers.
2. Je note - pas nécessairement écrire du code dans Delphi.

Maintenant, la situation - disons que nous avons une application et que les plugins 100 ont été écrits pour elle par des programmeurs tiers (nous les avons persuadés d'écrire uniquement sur notre version de Delphi).
Et maintenant nous passons à la nouvelle version et ... et tous ces plugins tombent instantanément.

Nos actions? Appelez tous les développeurs de plugins et demandez-leur d'acheter une nouvelle version du dauphin aussi?

Actions de l'utilisateur?



Rouse_ ©   (2016-03-05 14:04) [25]

PS: par exemple, une des options de chargement de données provenant de formats tiers pour nos plugins: http://ftp.grandsmeta.ru/grandsmeta/utils/gspluginsdk.rar

Simple et élégant, c'est fait et attention - pas de BPL :)



DVM ©   (2016-03-05 14:31) [26]


> Rouse_ © (05.03.16 14: 04) [25]
> PS: par exemple, une des options pour nos plugins, pour
> chargement de données à partir de formats tiers:

Et quelqu'un a écrit des plugins en C ++ ou C dans votre SDK.
Il me semble qu’il y aura des problèmes d’alignement.

Par exemple,
TPluginInfo est déclaré comme étant emballé dans un fichier PAS, tandis que dans le fichier H, rien n'est dit à propos de l'emballage ou de l'alignement.



Rouse_ ©   (2016-03-05 14:57) [27]

Essayez de l'aligner différemment :) Octets 4 + Octets 4 + Octets 4 :)



Rouse_ ©   (2016-03-05 15:00) [28]

PS: et oui, bien sûr, ils écrivaient et écrivaient - en règle générale, des responsables des services informatiques de structures publiques telles que RusHydro, NorNickel, etc.



ВладОшин ©   (2016-03-05 15:19) [29]

0
1

ps
Auparavant, ils utilisaient eux-mêmes la dll avec les paquetages, lorsqu'il y avait des modems sur 14400 dans les bureaux situés dans toute la Fédération de Russie - ils avaient au moins une chance de réussir la mise à jour.
Tout d'abord, un ordinateur entièrement configuré y a été envoyé. puis ils ont téléchargé les modifications. Ensuite, c’était comme ça, parce que c’était toujours comme ça, changer quelque chose devenait coûteux. Maintenant, il n’est plus utilisé, tout le monde est devenu un Internet dense, et pourtant ils l’ont fait une fois dans un seul fichier.



Юрий Зотов ©   (2016-03-05 15:57) [30]

> Un plugin est quelque chose que tout tiers peut ajouter
> programmeur pour notre application


Trop étroit. Un plugin est ce qui change la fonctionnalité d'une application sans la recompiler. Et ne vous inquiétez pas qui a écrit ce plugin.



Rouse_ ©   (2016-03-05 16:08) [31]

Je suis totalement d'accord, Yur, j'ai écrit à ce sujet :)



DVM ©   (2016-03-05 16:17) [32]


> Rouse_ © (05.03.16 14: 57) [27]
> Essayez de l'aligner différemment :) Octets 4 + Octets 4 +
> 4 octets :)

Dans ce cas, c’est juste de la chance. Je ne suis pas spécifiquement sur cette structure.
Vous déclarez des structures compactées dans un fichier PAS, mais vous n'écrivez pas #pragma pack en C. Cela entraînera des erreurs tôt ou tard, à mon avis.



DVM ©   (2016-03-05 16:24) [33]


> Rouse_ ©

De plus, dans la version c, int est utilisé comme l’équivalent d’un entier Pascal.
Si je peux garantir encore plus ou moins la version de Pascal, alors que int sera égal à 4 octets. int32_t serait nettement meilleur à ce titre.



Rouse_ ©   (2016-03-05 16:28) [34]

Application bit 32, il est difficile d’assembler et de charger la bibliothèque de bits 64 dans une application bit 32.
Tout fonctionne et pas la première année :)



DVM ©   (2016-03-05 16:38) [35]


> Rouse_ © (05.03.16 16: 28) [34]


> Application bit 32, il est difficile d’assembler et de charger un bit 64
> bibliothèque dans l'application 32 bit.

Oui, je crois :)
Mais le bitness n'a rien à voir avec cela. Le compilateur à faire avec. La norme C89 exige seulement que
sizeof (char) <= sizeof (court) <= sizeof (int) <= sizeof (long) <= sizeof (long long)
À propos de la taille de int (32 ou 64 n’est pas dit).



Kilkennycat ©   (2016-03-05 16:43) [36]


> int32_t serait nettement meilleur à ce titre.

Eh bien, quand la taille compte, écrivez. Bien que je sois fauché, il y a trop de hêtres.



DVM ©   (2016-03-05 16:48) [37]


> Kilkennycat © (05.03.16 16: 43) [36]


> bon alors quand la taille compte

Dans ce cas, c'est une API. Et dans l'API, tout compte.



Rouse_ ©   (2016-03-05 17:32) [38]

Dim, vous ne montrez pas, vous montrez avec votre doigt un exemple de code où la désynchronisation d’alignement ira avec nos en-têtes :)
Et je lis moi-même mucoalatur, et je suis conscient de ce dont vous parlez :)



Юрий Зотов ©   (2016-03-05 19:01) [39]

> Rouse_ © (05.03.16 16: 08) [31]

Sash, le problème n'est pas le BPL, mais l'incompatibilité des versions de Delphi au niveau du code compilé.



Rouse_ ©   (2016-03-05 19:32) [40]

Eh bien, c'est exactement ce que j'ai dit au départ :)

PS: en général, je pensais que tu volerais en termes: ils avaient une mouche :)



Юрий Зотов ©   (2016-03-05 19:38) [41]

> Rouse_ © (05.03.16 19: 32) [40]
> именно это я и сказал изначально

Изначально ты сказал не это, а вот что: "BPL это самый простой способ убить хорошую идею с плагинами".

На самом же деле BPL тут ни при чем. Проблема глубже.



asail ©   (2016-03-05 19:50) [42]

Всем привет! Давно не заходил...
Мы используем bpl, причем весьма активно. И дело не в экономии места на диске, хотя оно и весьма существенно... У нас комплекс, состоящий из примерно десятка ехе и под сотню dll. Если несколько мб общего кода вынести в bpl, то экономия составит сотни мб. Но, с сегодняшними дисками это ерунда...
Но, есть и другие плюсы. На мой взгляд, основной в следующем:
Представим, что есть некие базовые классы, наследники которых используются во всех эти exe и dll... Теперь мы что-то меняем в приватных методах одного из бальзовых классов. Если работаем без bpl, то придется перекомпилить всю эту ватагу из exe и dll. В противном случае - компилим только один bpl и отдаем его заказчику... Профит.



Юрий Зотов ©   (2016-03-05 21:11) [43]

> Rouse_ © (05.03.16 14: 04) [25]

Саш, я правильно понял, что в качестве плагинов вы используете DLL?



Rouse_ ©   (2016-03-05 21:15) [44]

Oui, bien sûr



Kilkennycat ©   (2016-03-05 21:21) [45]

в общем, всё зависит от частного случая, политики партии, требований заказчика и настроения.
как и всегда.



Юрий Зотов ©   (2016-03-05 21:27) [46]

> Rouse_ © (05.03.16 21: 15) [44]

И при этом компилируете EXE и эти DLL без RT-пакетов?



sniknik ©   (2016-03-05 21:56) [47]

> Если работаем без bpl, то придется перекомпилить всю эту ватагу из exe и dll. В противном случае - компилим только один bpl и отдаем его заказчику...
часто слышал такие объяснения, и ни разу не видел это реально работающим... не, может мне просто не везло, но обычно это выглядит так, с точки зрения заказчика -
- мы тут кое чего исправили, замените файл.
- заменили, вообще запускаться перестало с ошибкой ...
- хм. тут наверное еще вот этот модуль нужен.
- не получилось.
...
дальше длинная переписка, с высылкой все нового и нового. в итоге вообще ВСЕГО, как именно у разработчиков стоит. и только после этого начинает работать. ну более менее т.к. у тех у кого подобные мысли почему то не возникает других, ну типа сделать сетап, и чтобы он сам либо устанавливал либо апдейтил нужное... и не говорите что он у вас есть, в сетапе должно быть все, вместе с модулями, без необходимости "кусочно-апдейта". а раз там все то какая разница 1-ехе файл обновлять, 100 вместе с dll, или 200 с bpl??? (цифры "с потолка").

> [0]
1 не использую
2 видел, приходилось "обслуживать". (что за прога говорить смысла нет, ее давно переписали на "яве", т.к. "все проблемы из-за глючной дельфы, нужно"... хотя, после переписывания проблемы никуда не делись просто стали другими, что подсказывает что "дело было не в бобине" :))



эндсоувот ©   (2016-03-05 23:00) [48]

в общем резюме такое.
пакеты не работают так как задумано у тех кто их не использует, и работают как и задумано у тех кто их использует лет 15-16 как уже.
без длинных переписок с заменой "всего" в конце их.



Kerk ©   (2016-03-05 23:08) [49]


> - мы тут кое чего исправили, замените файл.
> - заменили, вообще запускаться перестало с ошибкой ...

Тестирование? Не, не слышал.



Германн ©   (2016-03-05 23:30) [50]


> Yuri Zotov © (05.03.16 19: 01) [39]
>
>> Rouse_ © (05.03.16 16: 08) [31]
>
> Саш, проблема не в BPL, а в несовместимости версий Delphi
> на уровне откомпилированного кода.

Об этом я и говорил конкретно в  [19], и в топике в целом. Из-за этого все упомянутые доводы в пользу RT-пакетов просто блекнут. А эти проблемы несовместимости не исчезнут никогда. Имхо это нереально. Дай боже чтобы проблем несовместимости исходников разных версий было как можно меньше! (И в целом папаша Борланд с этим справляется, несмотря на многократные смены "места жительства". :)



Германн ©   (2016-03-05 23:36) [51]


> Kerk © (05.03.16 23: 08) [49]
> > - мы тут кое чего исправили, замените файл.
> > - заменили, вообще запускаться перестало с ошибкой ...
> Тестирование? Не, не слышал.

Не всем так везёт с конторой, как тебе.
Тестирование по всем правилам нужно производить на "стенде, создающем условия полностью аналогичные реальному объекту". А это не всегда возможно.



sniknik ©   (2016-03-06 00:03) [52]

> пакеты не работают так как задумано у тех кто их не использует, и работают как и задумано у тех кто их использует лет 15-16 как уже.
скорее в них нет смысла если использовать правильно, а так как используют получается хреново.
и еще проблемка... "задумывают" часто люди оторванные от реальности, в чисто "разработческих" конторах. а вот "парятся" с ними в поддержке.

> Тестирование? Не, не слышал.
само собой, откуда тестирование в логике "компилим только один bpl и отдаем его заказчику..."?
о совместимости версий тоже не слышал.



sniknik ©   (2016-03-06 00:09) [53]

Kerk © (05.03.16 23: 08) [49]
ты вообще когда нибудь поддерживал программу у более чем 1-го клиента? а например с полтысячи. и они у тебя все были "дрессированными" на единой версии, обновлялись манипулируя файлами, все с доступом в папку установки и т.д. ???
ну, присоеденюсь
> Не всем так везёт с конторой, как тебе.



Kilkennycat ©   (2016-03-06 00:38) [54]


> все были "дрессированными" на единой версии, обновлялись
> манипулируя файлами, все с доступом в папку установки и  т.д. ???

Подходя к вопросу диалектически, это только при коммунизме возможно.



Kerk ©   (2016-03-06 01:00) [55]


> sniknik © (06.03.16 00: 09) [53]
>
> Kerk © (05.03.16 23: 08) [49]
> ты вообще когда нибудь поддерживал программу у более чем
> 1-го клиента?

Я поддерживал программу с двумя миллионами клиентов.



Kerk ©   (2016-03-06 01:03) [56]

Но важно не это. Важен учет и версионирование. Тогда просто спросив у пользователя список версий линкующихся библиотек можно создать "условия полностью аналогичные реальному объекту". Я думаю многие заметили, что в окне About у многих программ или где-то рядом с ним часто можно такой список библиотек увидеть.

Вот например в Delphi в окне About есть кнопочка "Version Info". Но учет мелких деталей - это для трусов.



Германн ©   (2016-03-06 01:19) [57]


> Kerk © (06.03.16 01: 03) [56]
>
> Но важно не это.

В каждом конкретном случае важно что-то . Либо это, либо то, либо что-то ещё. Главное что во всех случаях от RT-библиотек пользы очень мало, а проблем может быть много.
И даже если эти проблемы возникают из-за малограмотности тех, кто их использует, это только минус для этих библиотек. :)



Плохиш ©   (2016-03-06 01:42) [58]


> Тогда просто спросив у пользователя список версий линкующихся
> библиотек

Действительно, повезло с конторой



sniknik ©   (2016-03-06 01:49) [59]

> Я поддерживал программу с двумя миллионами клиентов.
и что реально "отдавал" каждому по обновленному файлу, с учетом версии остального у каждого, желания обновляться и т.д.?
что то мне подсказывает, что у тебя в этом случае система была другая, например описанный "сетап" с "все включено". ну или ты врешь. учесть все, включая блаж клиентов невозможно.



asail ©   (2016-03-06 05:59) [60]


> sniknik © (05.03.16 21: 56) [47]
> > Если работаем без bpl, то придется перекомпилить всю эту
> ватагу из exe и dll. В противном случае - компилим только
> один bpl и отдаем его заказчику...
> часто слышал такие объяснения, и ни разу не видел это реально
> работающим... не, может мне просто не везло, но обычно это
> выглядит так, с точки зрения заказчика -
> - мы тут кое чего исправили, замените файл.
> - заменили, вообще запускаться перестало с ошибкой ...
> - хм. тут наверное еще вот этот модуль нужен.
> - не получилось.

Да не, работает... Есть нюансы, конечно, но работает. Клиентов много, но они все корпоративные... Ибо продукт рассчитан на них. Не для одиноких домохозяек, скажем так...

> в сетапе должно быть все, вместе с модулями, без необходимости
> "кусочно-апдейта".

А, ну да... Скажи это МС, чтоб они тебе на каждый виндовый хот-фикс полный дистрибутив винды высылали. С необходимостью полной установки... :)

> само собой, откуда тестирование в логике "компилим только
> один bpl и отдаем его заказчику..."?

Это, как "само-собой" разумеющееся. Процесс "отдаем заказчику" не такой простой, как тебе кажется... Там, как минимум, два уровня тестирования - наш и заказчика. Бывает и третий - интегратора...



asail ©   (2016-03-06 06:06) [61]

Но, есть и недостатки...
Например, сейчас столкнулись с полной опой... Есть известный баг в Controls.pas, связанный с RegisterWindowMessage... Лечится правкой этого самого Controls.pas. Но, в случае работы с BPL, не лечится никак, ибо надо перекомпилить дельфишную vcl60.bpl (у нас Д6, если че :) ). А как? Сырцов то полных нету...



эндсоувот ©   (2016-03-06 13:34) [62]

Я поддерживал программу с двумя миллионами клиентов.


это случай когда пишешь что-то, выкладываешь и у тебя два миллиона скачиваний.
и написано что ты конечно там как бы осуществляешь поддержку, вообще ты не при делах.

но есть и другие примеры,
когда инсталляций в районе десятка-другого тысяч, все пользователи административно не зависят от твоего начальника,
но каждый имеет полное право выесть ему мозг с последующими для тебя оргвыводами.

и есть рантайм пакеты. и ничего не взрывается, и релиз-билдов за 17 лет третья сотня пошла.



Германн ©   (2016-03-07 00:30) [63]


> asail © (06.03.16 06: 06) [61]
>
> Но, есть и недостатки...
> Например, сейчас столкнулись с полной опой... Есть известный
> баг в Controls.pas, связанный с RegisterWindowMessage...
>  Лечится правкой этого самого Controls.pas. Но, в случае
> работы с BPL, не лечится никак, ибо надо перекомпилить дельфишную
> vcl60.bpl (у нас Д6, если че :) ). А как? Сырцов то полных
> нету...

Сырцы-то полные есть. Нет только исходников самих пакетов RTLxxx.dpk и VCLxxx.dpk. Но почему-то мне кажется что это не полная опа.



asail ©   (2016-03-07 10:23) [64]


> Hermann © (07.03.16 00: 30) [63]

> Сырцы-то полные есть. Нет только исходников самих пакетов
> RTLxxx.dpk и VCLxxx.dpk. Но почему-то мне кажется что это
> не полная опа.

А толку от оных сырцов без этих dpk? Подозреваю, что там помимо имеющихся юнитов, требуются еще всякие RES и OBJ... Да и где гарантия, что имеющиеся сырцы идентичны тем, которые использовались Борландом для компиляции своих BPL?
Есть идеи, насчет не полной опы? Был бы весьма признателен!



asail ©   (2016-03-07 10:24) [65]


> Hermann © (07.03.16 00: 30) [63]

> Сырцы-то полные есть. Нет только исходников самих пакетов
> RTLxxx.dpk и VCLxxx.dpk. Но почему-то мне кажется что это
> не полная опа.

А толку от оных сырцов без этих dpk? Подозреваю, что там помимо имеющихся юнитов, требуются еще всякие RES и OBJ... Да и где гарантия, что имеющиеся сырцы идентичны тем, которые использовались Борландом для компиляции своих BPL?
Есть идеи, насчет не полной опы? Был бы весьма признателен!



KSergey ©   (2016-03-07 16:23) [66]

> Rouse_ © (05.03.16 16: 28) [34]
> Приложение 32 бита, сложно собрать и подгрузить 64 битную библиотеку в 32 битное приложение.
> Все работает и не первый год :)

Я понимаю, что пои примеры вас не убедят, т.к. вы будете уверены, что "вас это не касается". Но взгляните на эти примеры шире. Тем более, что рано или поздно вы будете переезжать на x64 как минимум.
Я не про плагины в явном виде, я про разного рода API, ну и код, который работает на разных машинах и взаимодействует по сети.

Первый раз серьёзно пришлось попотеть, когда часть C++ кода потребовалось перенести на iOS. После повторился цирк с Андроид.
Считаю проблема в том, что из iOS не вынесли уроки как раз вот с типами и выравниванием. Т.е. вместо того, чтобы поправить общий код так, чтобы он однозначно компилировался на разных платформах (в частности, это касалось размеров данных и выравниваний), решили "и так пойдёт". Соответственно, с Андроид"ом занимались сексом по второму кругу в полном объёме ровно с тем же кодом.

А потом "просто перекомпилировали" под новой какой-то версией iOS - и всё прошло совершенно гладко! счастью не было предела.
Разумеется, у клиентов всё тут же "совершенно неожиданно" навернулось, кто бы сомневался.
А всего-то платформа стала 64-разрядной вместо 32 оразрядной, ну и пара безалаберностей в коде про которые все уже давно забыли так вот печально выстрелили. (если напишу предметнее - каждый, уверен, скажет "ну я так-то так никогда не сделаю! это же азбука!" хо-хо, скажу я на это)

Я для себя вынес урок:

1) В API - только типы явно указанного размера! причем для Win-платформы лично я бы использовал только типы из WinAPI, по-моему, это правильнее, хотя это только моё мнение.

2) Обязательно явно указывать размер упаковки структур!
Не, можно, конечно, заморачиваться и при разработке интерфейсных структур очень включать голову, чтобы при любом выравнивании было одинаково, но зачем?? не понимаю. Да и потом это "тайное знание" непременно забудется, придут новые необстрелянные люди - какой смысл оставлять грабли.



KSergey ©   (2016-03-07 16:26) [67]

А еще я против переменных беззнаковых типов, если эти переменные участвуют в арифметических выражениях.
Добра ни разу из этого не случалось, а граблей - вагон.



Германн ©   (2016-03-08 00:51) [68]


> asail © (07.03.16 10: 23) [64]
>
>
>> Hermann © (07.03.16 00: 30) [63]
>
> > Сырцы-то полные есть. Нет только исходников самих пакетов
> > RTLxxx.dpk и VCLxxx.dpk. Но почему-то мне кажется что
> ça
> > не полная опа.
>
> А толку от оных сырцов без этих dpk? Подозреваю, что там
> помимо имеющихся юнитов, требуются еще всякие RES и OBJ.
> .. Да и где гарантия, что имеющиеся сырцы идентичны тем,
>  которые использовались Борландом для компиляции своих BPL?
>

Ну вообще-то Борланд такие гарантии даёт. Но предупреждает, что сырцы могут быть не совсем точными для данной сборки дистрибутива. Ну по крайней мере раньше предупреждал.
"Всякие RES и OBJ" в сырцах присутствуют.
Ну и лично сам пробовал менять исходник System.pas с целью проверить, что сырцы рабочие.



Pages: 1 2 branche entière

Forum: "Autre";
Archive actuelle: 2017.01.15;
Télécharger: [xml.tar.bz2];

à l'étage









Mémoire: 0.88 MB
Heure: 0.111 c
15-1453995709
Petit-fils
2016-01-28 18:41
2017.01.15
Méthodes de classe avec des propriétés non-classe


15-1448919001
jury
2015-12-01 00:30
2017.01.15
Bon anniversaire à toi! 1 décembre 2015 mardi


2-1421218510
Somnolent
2015-01-14 09:55
2017.01.15
Besoin d'un composant de type PaintBox.


15-1452597638
GanibalLector
2016-01-12 14:20
2017.01.15
PDF


2-1422788793
Axnxekceu
2015-02-01 14:06
2017.01.15
Vérification du code





afrikaans albanais Arabic arménien azerbaïdjanais basque Biélorusse Bulgare catalan Chinois simplifié) Chinois (traditionnel) croate Tchèque Danois Néerlandais English estonien Filipino Finlandais Français
galicien géorgien Allemand Grecque Créole haïtien hébreu Hindi Hongrois Islandais Indonesian irlandais Italien japonais Coréen letton lituanien macédonien Malay maltais Norvégien
persan Polonais Portugais roumain Russe serbe Slovaque Slovène Espagnol Swahili Suédois Thai turc ukrainien Urdu vietnamien gallois yiddish bengali bosniaque
Cebuano espéranto gujarati Hause hmong Igbo Javanais Kannada Khmer lao latin maori Marathi mongol népalais punjabi somali tamil telugu yoruba
zoulou
Английский Français Allemand Italien Португальский Русский Espagnol