Сабж: http://dn.codegear.com/article/38132

Детали: http://www.codegear.com/about/news/embt

Мда, вроде собираются дальше работать, но все равно как-то боязно…

Не радует

> Не радует

Не могу знать чего ждать, но перемены всегда к лучшему, я так думаю

pasha_golub ©   (07.05.08 17:19) [4]


> но перемены всегда к лучшему


Ты это древним китайцам скажи.

По сабжу - лучше бы их Оракл купил :)

Может хоть эти возродят CLX.

Одно радует: теперь будет только лучше.

> По сабжу - лучше бы их Оракл купил :)

и утопил?
нафига они ораклу

> Ты это древним китайцам скажи.


Почему именно китайцам??????

> Почему именно китайцам??????


"Чтоб тебе жить во время перемен" - это древние китайцы придумали. Недоброго желали

> Чтоб тебе жить во время перемен" - это древние китайцы придумали.
>  Недоброго желали

Нынешние тоже добра нам не желают

> "Чтоб тебе жить во время перемен"


А, в этом плане...

> "Чтоб тебе жить во время перемен" - это древние китайцы
> придумали. Недоброго желали
>

И ведь и в самом деле кончилось всё для древних китайцев плохо. Никто не уцелел. Все вымерли (((

остались неокитайцы... все как на подбор... избранные :)

JBuilder ещё жив?

> Interestingly, Embarcadero vice president - Nigel Brown
> - came to
> Embarcadero after more than 10 years at Borland where he
> headed up the
> Developer Tools business (Code Gear) in 2006. Prior to that,
>  he was
> Vice-President-EMEA, growing it to be Borland's largest
> and most successful
> region in 2000-2004.

Вот откуда ноги растут

Anatoly Podgoretsky ©   (07.05.08 21:36) [15]

Мафия :)

> Игорь Шевченко  (07.05.2008 21:56:16)  [16]

Кумовство, Борланд поставляет свои кадры Микрософту и другим компаниям. Я не знаю как сейчас оценивать текущий уровень разработчиков, но это по уровню ниже отцов разработчиков и их попсовые действия у меня вызывают огорчение. Я думаю, если бы старые не ушли, то мы бы имели Юникод или в Д3 или максимум в Д5
Зато сейчас МС имеет С#, другие другое, а Борланд в одном известном месте.
Еще не известно чем может закончиться эта покупка, я еще помню попытку продажи Корелу, тогда стоимость акции упала в несколько раз. Борланд еще легко отделался, в основном пострадал Корел.

Я знаю кому надо продавать, но они не покупают, тогда мы жили бы безбедно, без страха на будущее. Скажи что они испортили, уничтожили в отличии от ИБМ, Корела? Все их покупки давали вторую жизнь продуктам. А вспомним судьбу продуктов, которые продал Борланд, большинство прикратили свое существование.

> Зато сейчас МС имеет С#, другие другое, а Борланд в одном
> известном месте.


C# своеобразная ерундовина. Скрестили java с VCL. Причём С++  списали в утиль, под него новые вкусности не работают. А так в принципе, сам язык не плохой, читаемость повысили. Но вот "Рога" торчат. Борланда больше убило отсутсвие проектирования - в D2006 иногда в ступор становишься, при чтениии  VCL.

>platform-independent software provider of database and application >development tools.


Иде же оно ?  Хочу фрэймворк QT за 1000, а не за 3.500  Евро.

Хм... Мне Embarcadero вспоминаются исключительно, как производитель какой-то маловнятной глючной тулзовины для работы с БД... :(

А мне ничем оно не вспоминается. У меня есть ТР7.0, Д4, Д6. Все меня полностью устраивают. А мафия и кумовство пусть идут лесом.
:)

Если бы в Delphi сделали прямой вызов функций WinAPI (call без jmp), naked функции, {$CODEALIGN x} и поддержку COFF .obj, было бы здорово.

> Тыщ ©   (08.05.08 01:09) [22]
>
> Если бы в Delphi сделали прямой вызов функций WinAPI (call
> без jmp), naked функции, {$CODEALIGN x} и поддержку COFF
> .obj, было бы здорово.
>

Ты о своём, личном?

Германн ©   (08.05.08 1:47) [23]

> Ты о своём, личном?

Я думаю, оное не только мне полезно было бы.

> Если бы в Delphi сделали прямой вызов функций WinAPI (call
> без jmp),


Это как ?

> Тыщ ©   (08.05.08 01:09) [22]
> Если бы в Delphi сделали прямой вызов функций WinAPI (call
> без jmp)





а так не канает?

> koha ©   (08.05.08 10:14) [26]

А теперь посмотри в CPU что получилось

Вот так это делается =)

> Тыщ ©   (08.05.08 01:09) [22]


У детей свои проблемы. Delphi для офисных преложений предназначено, а не для 3D маньяков.

> Если бы в Delphi сделали прямой вызов функций WinAPI (call
> без jmp)

Ты про jmp который из секции импорта делается? ;)


> naked функции

Пиши на асме, чем тебе пролог с эпилогом помешал?
Да и inline уже давно появились :)


> {$CODEALIGN x} и поддержку COFF .obj

Зачем?

Кистате о naked-функциях: Когда мне потребовалось сымитировать их поведение, был написан такой код:

function HSNtUserCreateWindowEx (p1,p2,p3,p4,p5,
 X, Y, Width, Height : Integer; hWndParent : HWND;
 p11, p12,p13,p14,p15 : Integer) : HWND; stdcall;
asm
 pop ebp
 mov eax,00001157h
 mov edx,7FFE0300h
 call edx
 ret 60
end;

> Delphi для офисных преложений предназначено, а не для 3D
> маньяков.

Это вы решили?

Rouse_ ©   (08.05.08 11:08) [29]

> Ты про jmp который из секции импорта делается?

Ага. Сейчас call -> jmp [API], а надо бы call [API].

> Пиши на асме, чем тебе пролог с эпилогом помешал?

Иногда хочется, чтоб ret не вставлялся. Можно было бы произвольные данные asm..end генерировать, ret зачастую все портит.
Конечно, можно и костылями обходиться, но из-за какой мелкой отсутствующей фичи...

>> {$CODEALIGN x} и поддержку COFF .obj
> Зачем?

Первое - для оптимизации, второе - для совместимости с большинством объектников, в OMF сейчас мало что может компилировать. А конвертеры глючные, для больших вещей не годятся.
Либо Delphi очень привередлив (то invalid format, то просто не видит символы).

> Ага. Сейчас call -> jmp [API], а надо бы call [API].

Предложи другую схему?

Адрес функции из библиотеки DLL неизвестен на этапе компиляции/линковки. Получается, чтобы реализовать твою схему, необходимо будет при загрузке EXE-файла иметь дополнительно специальную таблицу, в которой бы хранились все обращения к этой функции и их подправить. Это может быть как вызов этой функции, так и взятие адреса. Это приводит к тому, что страницы кода с памяти и на диске будут отличаться друг от друга. Возникнут проблемы с тем, чтобы организовать для нескольких приложений использование одних и тех же кодовых страниц. В общем никому не нужный геморрой. Если для какой-то функции тебе так важно не терять на промежуточный JMP, правь адрес руками :)

> Ага. Сейчас call -> jmp [API], а надо бы call [API].


Так это не только в Delphi, не переживай

Mystic ©   (08.05.08 13:41) [33]

Ты меня не понял. Я не хочу вызывать функции API настолько напрямую и тем самым терять всю совместимость (это годится разве что для демосценок).
Я хочу вызывать через импорт напрямую, как это делают многие другие компиляторы.

> Так это не только в Delphi, не переживай

Нет, тут все-же различается. Специально проверял сторонним отладчиком, чтоб не грешить на то как отображает внутренний дизасм у обоих сред.

У Delphi



У VC++

Тыщ ©   (08.05.08 14:04) [35]


> Я не хочу вызывать функции API настолько напрямую и тем
> самым терять всю совместимость (это годится разве что для
> демосценок).


пардон, какая совместимость и кого с кем имеется в виду.

Rouse_ ©   (08.05.08 14:06) [36]


> Специально проверял сторонним отладчиком


убедился что в каких-то конкретных версиях конретных компиляторов это так. И что с того ? Тут экстраполяция неуместна.

Игорь Шевченко ©   (08.05.08 14:17) [37]

> пардон, какая совместимость и кого с кем имеется в виду.

Я так понял, Mystic говорил о вызове функций из dll напрямую, без таблицы импорта вообще. Это уже экстрим.

Тыщ ©   (08.05.08 14:21) [38]

Да, это экстрим.

Но все-таки я не совсем понимаю, чем тебе так jmp помешал :)

Игорь Шевченко ©   (08.05.08 14:24) [39]

Все модные компиляторы умеют обходиться без лишнего jmp, чем Delphi хуже? :)

> чем Delphi хуже?

Как однажды сказал ЮЗ: "все-же плюсы Delphi не в его названии" ;)

Тыщ ©   (08.05.08 14:27) [40]

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

Игорь Шевченко ©   (08.05.08 14:31) [42]

Согласен, но это в случае dll. В exe-шниках relocation ни к чему.

> Тыщ ©   (08.05.08 14:27) [40]
> Игорь Шевченко ©   (08.05.08 14:24) [39]
>
> Все модные компиляторы умеют обходиться без лишнего jmp,
>  чем Delphi хуже? :)


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

ЗЫ. Хотя действительно в Release версии можно убирать. По флагу например.

> В exe-шниках relocation ни к чему.

Экзешник тоже может экспортировать функции и может быть подгружен не по стандартному адресу ;)

Rouse_ ©   (08.05.08 14:36) [45]

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

oxffff ©   (08.05.08 14:36) [44]

Ну так можно и dword в таблице импорта поменять, тот же перехват.

> Тыщ ©   (08.05.08 14:38) [46]
> Rouse_ ©   (08.05.08 14:36) [45]
>
> Не будем вдаваться в подробности. Relocation не нужен для
> обычных, ничего не экспортирующих exe-шников, а таких большинство.
>


Если таблица импорта съедет, то будешь править все CALL [API].

oxffff ©   (08.05.08 14:39) [48]

> Если таблица импорта съедет

Как она может съехать?

> Тыщ ©   (08.05.08 14:39) [47]
> oxffff ©   (08.05.08 14:36) [44]
>
> Ну так можно и dword в таблице импорта поменять, тот же
> перехват.


Тогда будет перехватываться все.
А как быть в разными dcu?
Если нужно перехватывать только вызовы одного DCU.

oxffff ©   (08.05.08 14:43) [50]

Уж сильно специфический случай.

> Тыщ ©   (08.05.08 14:41) [49]
> oxffff ©   (08.05.08 14:39) [48]
>
> > Если таблица импорта съедет
>
> Как она может съехать?


А что есть гарантия, что она всегда на том же месте?
Секция съедет и таблица вместе с ней.

oxffff ©   (08.05.08 14:43) [50]

Ах да, выяснилось еще одно - хотелось бы, чтоб вызовы одинаковых API из разных DCU объединялись. А то доходит до того, что kernel32.dll в таблице упомянут по 5 раз...

oxffff ©   (08.05.08 14:45) [52]

> А что есть гарантия, что она всегда на том же месте?
> Секция съедет и таблица вместе с ней.

А если секция кода съедет? Пиши пропало.

> А если секция кода съедет? Пиши пропало.


Почему? Reloc поправит все.

oxffff ©   (08.05.08 14:50) [55]

Ах, вон ты о чем. Про это было сказано в [43].
А секции друг относительно друга всегда неподвижны.

> Как однажды сказал ЮЗ: "все-же плюсы Delphi не в его названии"
> ;)

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

http://www.embarcadero.com/company/executive_team.html
обратите внимание на трудовой путь третьего сверху товарища :)

> Экзешник тоже может экспортировать функции и может быть
> подгружен не по стандартному адресу ;)


Так вроде же виндовый загрузчик все равно игнорирует и таблицу импорта экзешника, и таблицу релокации.

> Ins ©   (08.05.08 15:43) [59]
> Так вроде же виндовый загрузчик все равно игнорирует и таблицу
> импорта экзешника, и таблицу релокации.

Неправда :)

> Неправда :)


Если верить MSDN - то выходит что так. EXE можно загрузить с помощью LoadLibrary только для дерганья ресурсов. Да и мои эксперименты когда-то это подтвердили. Приходилось таблицу релоков самому ручками обходить после загрузки )

Как то все это не очень радостно... но! может ценовую политику изменят?

обратите внимание на трудовой путь третьего сверху товарища :)

Тоже не особо радует. У него значиться Management Sciences в графе "образование"... и вот, как раз, из-за этого сайнсеса некоторых "продвинутых" товарищей в Borland'е, Delphi и страдал на протяжении последних лет.