Компилятор D7 учитывает платформу ?

← →
Jeer © (2007-11-06 10:33) [0]

Столкнулся с непонятной ситуацией:
Рабочая платформа - win2k server adv + D7
Никогда никаких претензий по поводу работоспособности приложений, созданных на этой платформе не было.
Недавно же, в связи с началом работы приложения, эксплуатируемого более чем 1000 пользователей, была обнаружена катастрофическая неработоспособность на некоторых компьютерах с XP класса SP2 rus.
Что интересно, на платформе XP SP2 PE + langpack RU таких проблем никогда не возникает.
Специально созданные тесты, в которых ставилась задача выявления причины сбоя, показали его неустойчивый характер, вплоть до триггерного эффекта.
Переустановка D7 и перекомпиляция всех библиотек ни к чему не привела.

И неожиданно, была достигнута нормальная работоспособность приложения, после переноса среды разработки на ОС XP.
Причем D7 на обоих платформах и все используемые модули синхронизированы до "байта".

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

Так, что ? Действительно ли компилятор D7 учитывает платформу разработки ?

← →
umbra © (2007-11-06 10:53) [1]

> Размер exe-шников получается идентичным, но контрольные
> суммы не совпадают.

Разница, скорее всего, в секции импорта.

← →
Amoeba © (2007-11-06 11:00) [2]

> Действительно ли компилятор D7 учитывает платформу разработки
> ?

Компилятор не имеет ни малейшего понятия о платформе разработки.

← →
clickmaker © (2007-11-06 11:09) [3]

> была достигнута нормальная работоспособность приложения,
> после переноса среды разработки на ОС XP

именно на той ХР, где есть среда разработки, или даже на тех, где нет?

← →
Jeer © (2007-11-06 11:28) [4]

> clickmaker © (06.11.07 11:09) [3]

После генерации новой тачки с XP SP rus + D7, и компиляции приложения, оно работает на всех платформах.
А приложение, скомпилированное на w2k srv adv, не работает на некоторых тачках c XP SP rus.

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

← →
clickmaker © (2007-11-06 11:29) [5]

> приложение ломается на этапе запуска

как именно?

← →
Eraser © (2007-11-06 11:37) [6]

может с runtime пакетами как-то все связано..? или они не используются?

← →
Jeer © (2007-11-06 11:42) [7]

runtime error 216 at..

Отдельные runtime не используются (снята галка "Buidl with runtime"), так же нет самописных DLL.

← →
Правильный_Вася (2007-11-06 11:44) [8]

DEP?

← →
Eraser © (2007-11-06 11:47) [9]

может тут что найдете http://www.delphikingdom.com/asp/listerrors.asp?ID=116

← →
Jeer © (2007-11-06 12:23) [10]

> Eraser © (06.11.07 11:47) [9]

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

> Amoeba © (06.11.07 11:00) [2]

> Компилятор не имеет ни малейшего понятия о платформе разработки.

Компилятор может иметь такое представление.
Кроме того, возможна генерация разных кусов кода для использования на конкретной целевой платформе, хотя это больше к железу привязывается.
Еси посмотрим пример FastCode, то увидим что они занимаются оптимизацией стандартных функций, привязывая их к hard-у.
Почему бы не предположить возможность учет целевой soft-платформы.

← →
clickmaker © (2007-11-06 12:27) [11]

> [10] Jeer © (06.11.07 12:23)

а если дизасемблировать 2 экзе, полученных на разных ОС, а потом загнать их в какой-нить построчный сравниватель - будут отличия?

← →
Johnmen © (2007-11-06 13:49) [12]

> Jeer © (06.11.07 11:42) [7]
> runtime error 216 at..

Это ошибка всё же у тебя.
Мы с ней когда-то сталкивались. Разобрались - сами кодеры накодили...:)

И компилятор действительно не в курсе, какая там ось. Т.е. знание оси никак не учитывается.

← →
Sapersky (2007-11-06 15:07) [13]

Вон Кладов пишет, что может учитываться:

http://delphimaster.net/view/11-1183648227/

Хотя сомнительно, что Дельфи "морфируется" под каждую ОС - скорее, это "затычка" сугубо для Win95 как экстремального случая.

← →
iZEN © (2007-11-06 15:36) [14]

Разные микропроцессы — разные глюки.

← →
iZEN © (2007-11-06 15:36) [15]

Разные микропроцессоры — разные глюки.

← →
Johnmen © (2007-11-06 15:40) [16]

Про микропроцессы гламурней...:)

← →
clickmaker © (2007-11-06 15:42) [17]

микропроцессы - микроглюки. Макропроцессы - соотв. и макроглюки

← →
Anatoly Podgoretsky © (2007-11-06 20:00) [18]

> Jeer (06.11.2007 11:42:07) [7]

Это одназначно ошибка в программе, связана с системными библиотеками.
У Дельфи нет понятия target platform

← →
DrPass © (2007-11-06 21:09) [19]

> Anatoly Podgoretsky © (06.11.07 20:00) [18]
> > Jeer (06.11.2007 11:42:07) [7]
>
> Это одназначно ошибка в программе, связана с системными
> библиотеками.

Куда вероятнее более тривиальный вариант - разные исходники. Например, на Вин 2К стояла "первоначальная" Delphi, а на ХР поставили Delphi с сервис-паком. В котором как раз была решена проблема работы под ХР :)

> DrPass (06.11.2007 21:09:19) [19]

У него же не Дельфи падает, а программа.

Дык тогда и программа должна одинаково не/работать, вне завимости где откомпилировано, при условии одинаковости среды.

> Anatoly Podgoretsky © (06.11.07 21:36) [22]

> при условии одинаковости среды

Я ж про что и говорю. Если на Win2K стоит Delphi без сервис-пака, а на ХР с сервис-паком, среда будет неодинаковая. Хотя пользователь это черта с два заметит

было такое под D6 Win2000 компиляция, XP - запуск. На определенной XP, вполне определенного клиента. Решилось забиванием на этого клиента :)
2005 (4?) г.

В общем, что:

- w2k была вычищена от всех следов D7
- на w2k и xp установлена D7 из одного источника с одинаковой системой каталогов, вплоть до пользовательских модулей. Единственное отличие -
каталог ОС: WINNT и WINDOWS соответственно
- установлены одни и те же необходимые компоненты в исходниках
- удалены все dcu разработки
- произведена проверка синхронности (всех папок и файлов по data/size + CRC)
Среды идентичны полностью, за исключением слегка разных очередностей в путях поиска и исключенных packages.

Проверка синхронности в файлах проекта показала полную идентичность по исходникам, совпадение по размеру dcu и несовпадение по CRC, что, возможно, связано с включением времени компиляции в него.
Hex-сравнение dcu показывает полное совпадение, за исключением одного байта по адресу 8. Не могу это интерпретировать, т.к. не знаю формата dcu.

В общем, вот такая пестня и она еще продолжается.

> clickmaker © (07.11.07 11:29) [26]

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

Пример:

На XP
procedure TfmLogin.FormCreate(Sender : TObject);
begin
(*
0059AD30 55 push ebp
0059AD31 8BEC mov ebp, esp
0059AD33 33C9 xor ecx, ecx
0059AD35 51 push ecx
0059AD36 51 push ecx
0059AD37 51 push ecx
0059AD38 51 push ecx
0059AD39 51 push ecx
0059AD3A 53 push ebx
0059AD3B 56 push esi
0059AD3C 8BF2 mov esi, edx
0059AD3E 8BD8 mov ebx, eax
0059AD40 33C0 xor eax, eax
0059AD42 55 push ebp
...

На w2k
procedure TfmLogin.FormCreate(Sender : TObject);
begin
(*
0059AD34 55 push ebp
0059AD35 8BEC mov ebp, esp
0059AD37 33C9 xor ecx, ecx
0059AD39 51 push ecx
0059AD3A 51 push ecx
0059AD3B 51 push ecx
0059AD3C 51 push ecx
0059AD3D 51 push ecx
0059AD3E 53 push ebx
0059AD3F 56 push esi
0059AD40 8BF2 mov esi, edx
0059AD42 8BD8 mov ebx, eax
0059AD44 33C0 xor eax, eax
0059AD46 55 push ebp
...

Компилятор D7 учитывает платформу ? Найти похожие ветки