Что за delphi такой XE?

← →
Eraser © (2011-08-21 00:08) [80]

> [73] asail © (20.08.11 23:21)

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

> Есть ситуации, когда переход на новую Дельфи практически
> невозможен. Например, у нас очень большой проект (несколько
> тысяч юнитов, среди которых множество с более чем 10000
> строк кода). Все это разбито на несколько сотен dll и десятки
> exe и служб. 90% используют БДЕ для доступа к БД, а также
> сторонние компоненты, причем, некоторые из них уже не поддерживаются
> разработчиками, хоть и были платными. Как этот зоопарк перевести
> на ХЕ, не переписывая почти все заного, я чета не очень
> себе представляю...

вообще плохо предстваляю, что это за продукт или система с десятками служб и доступом через BDE. Вроде бы службы стали активно применять после 2000 года, можно было задействовать и более современные подходы для доступу к БД.

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

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

← →
Inovet © (2011-08-21 00:09) [81]

> [78] DVM © (21.08.11 00:03)
> сделать эмулятор и прозрачно встроить его в ос не проблема, но делать не стали.

Да сделали как раз Virtual Windows XP на Virtual PC. Работает, даже почти прозрачно для юзера.

> [78] DVM © (21.08.11 00:03)
> 64 бит тоже не вчера появились.

Ещё не скоро 32 прикроют. Имхо.

← →
DVM © (2011-08-21 00:13) [82]

> Inovet © (21.08.11 00:09) [81]

> Да сделали как раз Virtual Windows XP на Virtual PC

там можно запустить Norton Commander 4.0 ?

← →
DVM © (2011-08-21 00:19) [83]

> Inovet © (21.08.11 00:09) [81]

> Ещё не скоро 32 прикроют. Имхо.

В Windows это может случиться уже в следующей версии.

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

← →
Игорь Шевченко © (2011-08-21 00:24) [84]

Inovet © (21.08.11 00:06) [79]

Что такое режим x64 и почему в нем аппаратно не поддерживаются 16-битные приложения ? Что такое аппаратная поддержка приложений ? Мне кажется, это нонсенс

← →
asail © (2011-08-21 00:26) [85]

> Eraser © (21.08.11 00:08) [80]

> Но все иначе, если софтовая компания сама и является заказчиком,
> т.е. выпускает, к примеру, коробочный продукт.

В нашем случае так и есть. Но продукт, которым занимается наш отдел - старый. Основная задача, поддерживать существующий и добавлять новый функционал по требованием клиентов, купивших или собирающихся это сделать. Есть другие отделы, в том числе, и разрабатывающие новые продукты "с нуля". R&D, то бишь. Они, кстати, с Дельфи уже не работают давно.

> вообще плохо предстваляю, что это за продукт или система
> с десятками служб и доступом через BDE.

Со службами, как раз все проще... Их почти все уже давно на IBX перевели. Но, службы - это малая часть от продукта в целом...

> начать с того, что перевести компоненты на новую версию.

Я ж говорю, нету новых версий. DevExepress пользуем сейчас. Все новые диалоги на нем и делаем. Но там еще и старых - море...

> наверняка это монстр с тысячами однообразных форм.

Вобщем, так и есть.

← →
Игорь Шевченко © (2011-08-21 00:28) [86]

Eraser © (21.08.11 00:08) [80]

> вообще плохо предстваляю, что это за продукт или система
> с десятками служб и доступом через BDE

Я уже советовал расширять кругозор.

DVM © (21.08.11 00:19) [83]

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

Расскажи это ораклу, вместе посмеемся над ответом.

← →
DVM © (2011-08-21 00:31) [87]

> Игорь Шевченко © (21.08.11 00:28) [86]

> Расскажи это ораклу, вместе посмеемся над ответом.

Зачем? Oracle же есть для 64 бит систем версия.

← →
Игорь Шевченко © (2011-08-21 00:34) [88]

Вот на что надо пыл направлять:
http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0_2038_%D0%B3%D0%BE%D0%B4%D0%B0

DVM © (21.08.11 00:31) [87]

> Зачем? Oracle же есть для 64 бит систем версия.

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

← →
Германн © (2011-08-21 00:35) [89]

> Eraser © (21.08.11 00:08) [80]
>
> > [73] asail © (20.08.11 23:21)
>
> работа на заказчика это одно, там возможно задача выкачать
> побольше $ с этого самого бедолаги. Но все иначе, если софтовая
> компания сама и является заказчиком, т.е. выпускает, к примеру,
> коробочный продукт.

Ну наконец-то ты привёл довод, которого я давно ожидал от тебя (или от кого-нибудь из компании Розыча).
Да только большинство тут на ДМ иное. Имхо.

← →
DVM © (2011-08-21 00:37) [90]

> Игорь Шевченко © (21.08.11 00:34) [88]

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

Я рад за Oracle. К сожалению это справедливо не для всех приложений. Расширяйте кругозор.

← →
Германн © (2011-08-21 00:37) [91]

> asail © (21.08.11 00:26) [85]
>
>
> > Eraser © (21.08.11 00:08) [80]
>
> > Но все иначе, если софтовая компания сама и является
> заказчиком,
> > т.е. выпускает, к примеру, коробочный продукт.
>
> В нашем случае так и есть. Но продукт, которым занимается
> наш отдел - старый. Основная задача, поддерживать существующий
> и добавлять новый функционал по требованием клиентов, купивших
> или собирающихся это сделать.

Это не совсем то, о чем говорил Eraser. Это тоже работа на заказчика.

← →
Inovet © (2011-08-21 00:41) [92]

> [82] DVM © (21.08.11 00:13)
> там можно запустить Norton Commander 4.0 ?

Да. Причём как в полноценном окне с ВинХП, так и в окне на столе Вин7 - остальное просто будет спрятано - и с ярлыка же на столе Вин7.

← →
Inovet © (2011-08-21 00:43) [93]

> [83] DVM © (21.08.11 00:19)
> В Windows это может случиться уже в следующей версии.

32 Версию ОС прикроют, а приложения Вин32 будут работать как и сейчас в х64.

← →
Inovet © (2011-08-21 00:46) [94]

> [84] Игорь Шевченко © (21.08.11 00:24)
> Что такое режим x64 и почему в нем аппаратно не поддерживаются
> 16-битные приложения ?

В «длинном» режиме упразднен ряд «рудиментов» архитектуры x86, таких, как режим виртуального 8086, сегментированная модель памяти
http://ru.wikipedia.org/wiki/X64

← →
DVM © (2011-08-21 00:46) [95]

> Игорь Шевченко © (21.08.11 00:34) [88]

Да, кстати, если включить логику, зачем Oracle выпускать отдельный 64 бит продукт, если его 32 бит версия не имеет никаких ограничений по сравнению с 64 бит в 64 бит системах? Не кажется, что тут неувязочка какая то?

← →
Eraser © (2011-08-21 00:47) [96]

> [86] Игорь Шевченко © (21.08.11 00:28)
> Eraser © (21.08.11 00:08) [80]
>
>
> > вообще плохо предстваляю, что это за продукт или система
>
> > с десятками служб и доступом через BDE
>
>
> Я уже советовал расширять кругозор.

то, что это возможно и много где использовалось я не спорю.

> [88] Игорь Шевченко © (21.08.11 00:34)

Вы же хорошо понимаете, что СУБД это не тот продукт, который работает в тесной интеграции с ОС (такая интеграция может быть, но это будут просто опциональные фенечки). Все таки там важно другое.

← →
Eraser © (2011-08-21 00:50) [97]

> [93] Inovet © (21.08.11 00:43)

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

← →
Игорь Шевченко © (2011-08-21 01:11) [98]

DVM © (21.08.11 00:46) [95]

У меня твою логику включить не получается. 64-х разрядные приложения пользуются, в первую очередь, бОльшим объемом памяти, для того их и выпускают.

Inovet © (21.08.11 00:46) [94]

Вот что пишет сам Intel:

"Compatibility mode (sub-mode of IA-32e mode) — Compatibility mode
permits most legacy 16-bit and 32-bit applications to run without re-compilation
under a 64-bit operating system. For brevity, the compatibility sub-mode is
referred to as compatibility mode in IA-32 architecture. The execution
environment of compatibility mode is the same as described in Section 3.2.
Compatibility mode also supports all of the privilege levels that are supported in
64-bit and protected modes. Legacy applications that run in Virtual 8086 mode or use hardware task management will not work in this mode."

Eraser © (21.08.11 00:47) [96]

Я так думаю, что проекты, которыми большинство здешних посетителей занимается, тоже несильно тесно интегрированы с ОС :)

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

Вот, кстати, еще мнение:
http://www.gunsmoker.ru/2010/11/64-windows.html

← →
DVM © (2011-08-21 01:16) [99]

> Игорь Шевченко © (21.08.11 01:11) [98]
> DVM © (21.08.11 00:46) [95]
>
> У меня твою логику включить не получается. 64-х разрядные
> приложения пользуются, в первую очередь, бОльшим объемом
> памяти, для того их и выпускают.

Значит ограничения для 32 бит приложений в виде ограничений по доступной памяти есть? Ну и зачем было спорить? Ради спора?

Конечно, ограничения по памяти можно и обойти, пытаясь запустить множество экземпляров процесса (как многие и делают, не знаю делает ли 32 бит Oracle), но от этого ограничения сами по себе не исчезают.

← →
Дмитрий С © (2011-08-21 06:42) [100]

А чего не так с integer и pointer? Я всегда считал, что в 64битном компиляторе integer тоже станет 64 битным и проблем с этим не будет. Какой смысл переводить pointer в nativeuint, который нигде не используется?

← →
Anatoly Podgoretsky © (2011-08-21 09:23) [101]

> Inovet (21.08.2011 00:43:33) [93]

Уже сейчас многие не работают.

← →
Anatoly Podgoretsky © (2011-08-21 09:27) [102]

> DVM (21.08.2011 00:46:35) [95]

Прямая адресация более 4 гб и повышение производительности, ведь СУБД в
первую очередь число дробилки. Для Оракл и MS SQL вообще желательна 128
битная среда, из-за поддержки Number(38).

← →
Anatoly Podgoretsky © (2011-08-21 09:30) [103]

> Дмитрий С (21.08.2011 06:42:40) [100]

Все ожидали, но разработчики обманули, сделали как им проще. Для этого
изобрели NativeXXX вместо Old32, хорошо, что хоть это смогли сделать.

> DVM (20.08.2011 23:26:14) [74]

Хотя век 16 бит еще не умер, в Москве есть фирмы, которые пишут на ФоксПро
2.0 и они захватывают крупные федеральные проекты.

> Дмитрий С © (21.08.11 06:42) [100]
> А чего не так с integer и pointer? Я всегда считал, что
> в 64битном компиляторе integer тоже станет 64 битным и проблем
> с этим не будет. Какой смысл переводить pointer в nativeuint,
> который нигде не используется?

Приводить уже неправильно потому, что Integer знаковый тип, а pointer беззнаковый, да и размеры у них разные могут быть. Зачем проблемы себе потенциальные создавать. Сказано же pointer = NativeUint .

pointer = NativeUint <> Integer <> Cadinal <> Longword <> Dword
THandle = NativeUint <> Integer <> Cadinal <> Longword <> Dword

Тут подробнее.

http://www.gunsmoker.ru/2010/11/64-windows.html

> [101] Anatoly Podgoretsky © (21.08.11 09:23)
> Уже сейчас многие не работают.

Например какие? Не из привязанных к железякам и внутренностям ОС.

> http://www.gunsmoker.ru/2010/11/64-windows.html

Очень подробно, спасибо.
Если поля типа Tag, а также различные LParam станут NativeInt - то я спокоен:)

Остается вопрос почему название такое выбрано NativeInt, некрасивое что ли.
Надеюсь, что в 128 битной системе NativeInt станет 128 битным.

> Дмитрий С © (21.08.11 13:27) [107]

> Если поля типа Tag, а также различные LParam станут NativeInt
> - то я спокоен:)
>

Уже стали (из беты XE2, хотя наверное давно уже так):

IntPtr = NativeInt; ... INT_PTR = System.IntPtr; // NativeInt; ... type WPARAM = INT_PTR; {$EXTERNALSYM WPARAM} LPARAM = INT_PTR; {$EXTERNALSYM LPARAM} LRESULT = INT_PTR; {$EXTERNALSYM LRESULT}

← →
_alex (2011-08-22 11:00) [109]

Все ожидали, но разработчики обманули, сделали как им проще. Для этого
изобрели NativeXXX вместо Old32, хорошо, что хоть это смогли сделать.

Интересно, как долго ещё люди будут возмущаться тем, что в ПДД лошадей задвинули с проезжей части в крайне правый ряд? Вот раньше-то было...

:)

Смиритесь. Веяния времени. Условия изменились.

← →
Компромисс (2011-08-22 12:04) [110]

Eraser © (20.08.11 17:07) [63]

> Мое мнение, что нужно адаптивровать проект (если конечно
> проект расчитан на развитие, что далеко не обязательно должно
> быть так) к каждой новой версии компилятора.

1) Зачем рисковать тем, что появятся новые баги?
2) Зачем тратить время на ненужный переход? Абстрактный пример: есть проект на D3. Заказчик просит перейти на Delphi2010. Зачем нужно переходить последовательно на D4/D5/D6 и т.д.? Не дешевле/быстрее ли перейти сразу на нужную версию?
3) Нет необходимости перехода с точки зрения клиента - нет денег на переход.

ЗЫ. В конкретном случае насчет tnt при принятии решения обязательно учитывается, что если все-таки придется добавить unicode полностью, то окажется, что переход на tnt уже не нужная работа. Значит, из-за срочности/отсуствия денег (пока) заказчика это устраивает.

← →
Компромисс (2011-08-22 12:17) [111]

Eraser © (21.08.11 00:08) [80]

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

То есть вы сами себе заказчик и решаете оплатить свой каприз по переходу на новую версию (считаем, что поставляется готовое приложение, а не библиотеки под конкретные компиляторы). То есть частный случай "стандартного" подхода.
Каприз - потому что пока никакого бенефита не получается, а деньги заплатить готовы.

Письмо пришло

RAD Studio XE2 World Tour в Москве

Приглашаем вас 13 сентября на семинар Embarcadero, посвященный выходу принципиально нового семейства средств разработки Embarcadero RAD Studio и входящих в его состав Delphi, C++Builder, Delphi Prism, RadPHP поколения XE2
...

> Компромисс (22.08.2011 12:04:50) [110]

> переход на tnt уже не нужная работа.

Именно так и к тому же усложняет переход на 2010 и наследников.

Что за delphi такой XE? Найти похожие ветки